Methods for protecting, accessing, and interfacing with enterprise resources

Abstract

In embodiments, the enterprise access layer includes an interface system, a data service system, an intelligence system, a scoring system, a data pool system, a workflow system, a transaction system (also referred to as a wallet system or a digital wallet system), a governance system, a permission management system, a reporting system, and / or a digital twin system.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Patent Application No. 63 / 381,546, filed October 28, 2022, U.S. Provisional Patent Application No. 63 / 461,802, filed April 25, 2023, and U.S. Provisional Patent Application No. 63 / 535,741, filed August 31, 2023, the contents of each of which are deemed to be fully set forth herein and are incorporated by reference.

[0002] (Field) The present disclosure relates to an enterprise access layer that provides access to a collection of computing resources and software services on behalf of an enterprise to various enterprise entities, including enterprise network resources and network management services, data storage resources and data management services, access rights management services, security services, and artificial intelligence services. [Background technology]

[0003] (background) In network computing, the access layer generally refers to one or more layers that provide access to an information technology infrastructure. The overall purpose of the access layer is to grant users access to various infrastructure resources (e.g., network resources, storage resources, processing resources) through systems and devices. For example, in a wide area network (WAN) environment, the network access layer provides access to an enterprise network through wide area communications technologies such as Frame Relay, Multiprotocol Label Switching (MPLS), Integrated Services Digital Networks, leased lines, and Digital Subscriber Line (DSL) over traditional telephone lines or coaxial cable. Because the access layer allows both local and remote access to the network, it may serve as a centralized point where remote users (e.g., clients or partners) meet local users and infrastructure.

[0004] Protocols in the access layer provide the means by which one or more systems, connected by a communications network or other means, transfer data to and from other devices or systems. For example, these protocols may provide the means to transfer data from a private network to a public network. In this sense, the access layer can be considered both a public-facing and a private-facing interface. The access layer's private-facing functions refer to its ability to receive, transform, and communicate data corresponding to private resources (e.g., private digital assets) on the private network, while its public-facing or client-facing functions refer to its ability to communicate with and provide access to users (e.g., public marketplace participants, or so-called market participants) outside the private network.

[0005] To act as a network intermediary, the network access layer may implement protocols and systems that understand detailed information about the endpoints it mediates. The access layer may contain various sublayers, services, modules, and components, each operating according to different protocols to enable access between a wide variety of participating entities. Summary of the Invention

[0006] (overview) The method uses an intelligence system executed by multiple processors to maintain multiple training datasets aggregated from multiple different data sources. The method includes: the intelligence system training a predictive model based on one of the multiple training datasets. The predictive model is one of multiple different predictive models maintained by the intelligence system, and is trained to minimize an error rate for parameters related to predicted outcomes. The method includes the intelligence system applying the predictive model to service prediction requests from one or more intelligence service clients of the intelligence system. The method includes the intelligence system aggregating results data collected from selected data sources of the multiple different data sources as data relevant to predictions made by the predictive model. The results data is included in the training dataset. The method includes the intelligence system enhancing the predictive model based on the training dataset including the results data. The method includes the intelligence system monitoring the results data and determining whether the predictive model is biased based on the results data and one or more governance parameters. In this method, if a bias in a predictive model is identified with respect to one or more monitored features, the intelligence system takes preventative measures to prevent the predictive model from being used to process subsequent prediction requests.

[0007] In another embodiment, the method includes updating the training dataset with corrective training data. The method includes retraining the predictive model based on the updated training dataset including the synthetic data. The method includes redeploying the retrained predictive model to a service that responds to subsequent prediction requests. In another embodiment, the predictive model is retrained using a second machine learning algorithm that is different from the first machine learning algorithm used to train the machine learning algorithm. In another embodiment, the corrective training data is synthetic training data. In another embodiment, updating the training dataset includes generating a synthetic training dataset based on a subsegment of the results data. In another embodiment, generating a synthetic training dataset based on the subsegment of the results data includes generating the synthetic training data based on the training data using a synthetic minority oversampling technique. In another embodiment, the method includes training a new predictive model based on the training dataset including the results data. In the method, the new predictive model is trained using a second machine learning algorithm that is different from the first machine learning algorithm used to train and enhance the predictive model. In another embodiment, the method includes sending a notification to a human user via a user device. In another embodiment, monitoring the outcome data to determine whether the model is biased includes calculating a drift value corresponding to the predictive model based on a corresponding outcome vector for each prediction made by the predictive model. In another embodiment, the predictive model is determined to be biased as a function of the drift value indicating that the model violates a threshold defined in the governance criteria.

[0008] The system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions from the memory hardware. The instructions include maintaining, by an intelligence system executed by a plurality of processors, a plurality of training datasets aggregated from a plurality of different data sources. The instructions include training, by the intelligence system, a predictive model based on one of the plurality of training datasets. The predictive model is one of a plurality of different predictive models maintained by the intelligence system, and is trained to minimize an error rate with respect to an outcome parameter. The instructions include deploying, by the intelligence system, the predictive model as a service responsive to prediction requests from one or more intelligence service clients of the intelligence system. The instructions include aggregating, by the intelligence system, outcome data collected from selected data sources of the plurality of different data sources. The outcome data is related to predictions made by the predictive model. The outcome data is included in the training dataset. The instructions include enhancing, by the intelligence system, the predictive model based on the training dataset including the outcome data. The instructions include monitoring, by the intelligence system, for biased predictive models based on the resulting data and one or more governance parameters, wherein if the predictive models are determined to be biased with respect to one or more monitored characteristics, the instructions prevent the intelligence system from using the predictive models to fulfill subsequent prediction requests from one or more intelligence service clients.

[0009] In other embodiments, the instructions include updating the training dataset with the corrective training data; retraining the predictive model based on the updated training dataset (including the synthetic data); and redeploying the retrained predictive model to support subsequent prediction requests. In other embodiments, retraining the predictive model uses a second machine learning algorithm that is different from the first machine learning algorithm. In other embodiments, the corrective training data is synthetic training data. In other embodiments, updating the training dataset with the corrective training data includes generating a synthetic training dataset based on a sub-segment of the results data. In other embodiments, generating a synthetic training dataset based on a sub-segment of the results data includes generating the synthetic training data from the training data using a synthetic minority over-sampling technique. In other embodiments, the instructions include training a new predictive model based on the training dataset including the results data. The new predictive model is trained using a second machine learning algorithm that is different from the first machine learning algorithm used to train and enhance the predictive model. In other embodiments, the instructions include sending a notification to a human user via a user device.

[0010] A non-transitory computer-readable medium has stored thereon instructions, the instructions including an intelligence system executed by a plurality of processors, maintaining a plurality of training datasets aggregated from a plurality of different data sources. The instructions include the intelligence system training a predictive model based on a training dataset among the plurality of training datasets. The predictive model is one of a plurality of different predictive models maintained by the intelligence system, and is trained to minimize an error rate for an outcome parameter. The instructions include the intelligence system deploying the predictive model to respond to prediction requests from one or more intelligence service clients of the intelligence system. The instructions include the intelligence system aggregating result data collected from selected data sources from the plurality of different data sources. The result data is related to predictions made by the predictive model. The result data is included in the training dataset. The instructions include the intelligence system enhancing the predictive model based on the training dataset including the result data. The instructions include the intelligence system monitoring the result data and determining whether bias exists in the predictive model based on the result data and one or more governance parameters. The instructions include preventing the predictive model from being used to fulfill subsequent prediction requests from one or more intelligence service clients if bias is determined to exist in the predictive model with respect to one or more monitored features.

[0011] In other embodiments, the non-transitory computer-readable medium includes instructions for updating the training dataset with the corrective training data, retraining the predictive model based on the updated training dataset that includes synthetic data, and redeploying the retrained predictive model to support subsequent prediction requests.

[0012] The method includes using one or more processors on a platform to train a large-scale language model (LLM) on a training dataset including a plurality of workflows. Each workflow is assigned a workflow label indicating a purpose of the respective workflow. Each workflow of the plurality of workflows defines a set of tasks to be performed when the workflow is executed and a set of workflow conditions that trigger execution of each task. The method further includes receiving, from a user device associated with a user belonging to an enterprise, a request by the one or more processors to generate a new workflow on behalf of the user. The request indicates an intended purpose of the new workflow. The method includes the one or more processors inputting the request into the LLM. The method includes the one or more processors obtaining a proposed workflow from the LLM. The proposed workflow includes a set of proposed tasks and a set of proposed workflow conditions. The method includes the one or more processors outputting the proposed workflow to the user device. The method includes the one or more processors receiving, from the user device, one or more improvements to the proposed workflow. The method includes the one or more processors inputting the improvements into the LLM. The method includes one or more processors obtaining an updated proposed workflow from the LLM in response to the requested improvements. The method includes one or more processors outputting the updated proposed workflow to a user device. The method includes, in response to the user approving the updated proposed workflow, one or more processors saving the updated proposed workflow to a workflow library associated with the enterprise and deploying the updated proposed workflow on behalf of the enterprise.

[0013] In another feature, the set of workflows used to train the LLM includes a default workflow. In another feature, the set of workflows used to train the LLM further includes custom workflows defined by or on behalf of the company. In another feature, the set of workflows used to train the LLM includes custom workflows defined by or on behalf of other companies. In another feature, the one or more improvements include one or more additional tasks to be added to the proposed workflow. In another feature, the one or more improvements include one or more proposed tasks to be removed from the proposed workflow. In another feature, the one or more improvements include one or more adjustments to be made to one or more of the set of proposed tasks or the set of proposed conditions. In another feature, the one or more improvements include one or more adjustments to be made to one or more of the set of proposed workflow conditions. In another feature, the one or more improvements include specifying one or more data sources to monitor during execution of the proposed workflow. In another feature, the training dataset further includes task labels for tasks defined in the plurality of workflows.

[0014] The system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions from the memory hardware. The instructions include one or more processors on the platform training a large-scale language model (LLM) using a training dataset including a plurality of workflows, and including, for each workflow, a workflow label indicating a purpose of the workflow. Each workflow of the plurality of workflows has a set of tasks to be performed when the workflow is executed and a set of workflow conditions that trigger execution of each task. The instructions include the one or more processors receiving, from a user device associated with a user belonging to the enterprise, a request to generate a new workflow on behalf of the enterprise. The request indicates an intended purpose of the new workflow. The instructions include the one or more processors inputting the request into the LLM. The instructions include the one or more processors obtaining a proposed workflow from the LLM. The proposed workflow includes a set of proposed tasks and a set of proposed workflow conditions. The instructions include the one or more processors outputting the proposed workflow to the user device. The instructions include the one or more processors receiving, from the user device, one or more refinements to the proposed workflow. The instructions include one or more processors inputting the improvements into the LLM. The instructions include one or more processors retrieving an updated proposed workflow from the LLM in response to the requested improvements. The instructions include one or more processors outputting the updated proposed workflow to a user device. The instructions include one or more processors, in response to the user approving the updated proposed workflow, storing the updated proposed workflow in a workflow library associated with the enterprise and deploying the updated proposed workflow on behalf of the enterprise.

[0015] In other features, the set of workflows used to train the LLM includes a default workflow. In other features, the set of workflows used to train the LLM further includes custom workflows defined by or on behalf of the company. In other features, the set of workflows used to train the LLM includes custom workflows for other companies defined by or on behalf of other companies. In other features, the one or more improvements include one or more additional tasks to be added to the proposed workflow. In other features, the one or more improvements include one or more proposed tasks to be removed from the proposed workflow. In other features, the one or more improvements include one or more adjustments to be made to any one or more of the set of proposed tasks or the set of proposed conditions. In other features, the one or more improvements include one or more adjustments to be made to any one or more of the set of proposed workflow conditions.

[0016] The non-transitory computer-readable medium includes instructions including training, by one or more processors of a platform, a large-scale language model (LLM) on a training dataset including a plurality of workflows, and training, for each of the plurality of workflows, a workflow label indicating a respective purpose of the workflow. Each of the plurality of workflows includes a respective set of tasks to be performed in execution of the workflow and a respective set of workflow conditions that trigger execution of each task from the respective set of tasks. The instructions include receiving, by the one or more processors, a request to generate a new workflow on behalf of the enterprise from a user device associated with a user associated with the enterprise. The request indicates an intended purpose of the new workflow. The instructions include inputting, by the one or more processors, the request to the LLM. The instructions include obtaining, by the one or more processors, a proposed workflow from the LLM. The proposed workflow includes proposed tasks and proposed workflow conditions. The instructions include outputting, by the one or more processors, the proposed workflow to the user device. The instructions include receiving, by the one or more processors, one or more refinements to the proposed workflow from the user device of the user. The instructions include inputting, by the one or more processors, the refinements to the LLM. The instructions include one or more processors obtaining updated workflow proposals from the LLM in response to the requested refinements. The instructions include outputting, by the one or more processors, the updated workflow proposals to a user device. The instructions include, in response to a user approving the updated workflow proposals, storing, by the one or more processors, the updated workflow proposals in a workflow library associated with the enterprise, and deploying, by the one or more processors, the updated workflow proposals on behalf of the enterprise. In other features, the set of workflows used to train the LLM includes a default workflow.

[0017] A method includes accessing, by one or more processors, network connectivity information related to the network connectivity of an authorizing entity. The authorizing entity approves a set of transaction requests to facilitate execution of the set of transactions. The method includes identifying, by the one or more processors, a problem related to network connectivity. In response to identifying the problem, the one or more processors determine whether the problem prevents the authorizing entity from approving the set of transaction requests. In response to the problem preventing the authorizing entity from approving the set of transaction requests, the one or more processors automatically generate a workflow to remedy the problem. The workflow includes a set of rules that determine which transactions of the transaction set can be executed in the absence of network connectivity and approval from an approval authority, and the one or more processors automatically execute a subset of the transactions of the transaction set based on the workflow without approval from the approval authority.

[0018] In other features, the problem is associated with at least one of a signal failure, a hardware or software failure, a denial of service (DoS) attack, a lack of necessary planning, and network restrictions imposed by a jurisdiction. In other features, generating a workflow to correct the problem includes accessing, by one or more processors, an alternative network route that traverses a different network node. In other features, the workflow enables a set of steps to be bypassed such that information related to a subset of the transactions is shared with a set of trusted systems. In other features, the workflow enables a set of steps to be bypassed such that a subset of the transactions can be completed. In other features, the approving entity is associated with a banking institution. In other features, the workflow enables transactions of the transaction set to be completed below a predetermined threshold without approval or pre-approval from the approving entity. In other features, the predetermined threshold is associated with a monetary threshold. In other features, the method includes determining, by the one or more processors, a trust level of the user associated with the selling entity based on a threshold number of transactions completed by the user with the selling entity within a period of time, and in response to the user exceeding the threshold number of transactions with the selling entity, by the one or more processors, enabling a subsequent transaction by the user with the selling entity in response to an occurrence of a network connectivity problem. In other features, the workflow performs offline approval of at least one transaction request in the series of transaction requests.

[0019] The system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions from the memory hardware. The instructions include accessing, by one or more processors, network connectivity information related to network connectivity of an authorizing entity. The authorizing entity authorizes a set of transaction requests to facilitate execution of the set of transactions. The instructions include identifying, by the one or more processors, a problem related to network connectivity. In response to identifying the problem, the one or more processors determine whether the problem prevents the authorizing entity from authorizing the set of transaction requests. In response to the problem preventing the authorizing entity from authorizing the set of transaction requests, the one or more processors automatically generate a workflow for correcting the problem. The workflow includes a set of rules that determine which transactions of the transaction set can be executed in the absence of network connectivity and approval from the authorizing entity. The one or more processors automatically execute a subset of the transactions of the transaction set based on the workflow without approval from the authorizing entity.

[0020] In other features, the problem is associated with at least one of a signal failure, a hardware or software failure, a denial of service (DoS) attack, a lack of necessary planning, and a network restriction imposed by a jurisdiction. In other features, generating a workflow to correct the problem includes accessing, by one or more processors, an alternative network route that traverses a different network node. In other features, the workflow allows a set of steps to be bypassed such that information related to a subset of the transactions is shared with a set of trusted systems. In other features, the workflow allows a series of steps to be bypassed such that a subset of the transactions can be completed. In other features, the authorizing entity is associated with a banking institution. In other features, the workflow allows transactions of the transaction set below a predetermined threshold to be completed without approval or pre-approval from the authorizing entity. In other features, the predetermined threshold is associated with a monetary threshold. In other features, the system includes determining, by one or more processors, a trust level of the user associated with the merchant entity based on a threshold number of transactions the user completes with the merchant entity within a period of time, and, in response to the user exceeding the threshold number with the merchant entity, enabling, by the one or more processors, a subsequent transaction by the user with the merchant entity in response to the occurrence of the network connectivity problem. In other features, the workflow performs offline approval of at least one transaction request in the series of transaction requests.

[0021] The method includes receiving, by one or more processors, a set of asset trade requests related to a set of asset trades. Each asset trade request in the set of asset trade requests is initiated by an entity in the set of entities. The method includes determining, by the one or more processors, a status of each asset trade request in the set of asset trade requests. The method includes determining, by the set of processors, whether each asset trade request in the set of asset trade requests is approved for the asset specified by the respective asset trade request. In response to determining that the asset trade request is unauthorized, the method includes rejecting, by the one or more processors, the asset trade request, and recommending, by the one or more processors, at least one of a similar substitutable asset and a set of similar substitutable assets as a substitute for the asset. In response to determining that the asset trade request is approved, the method includes automatically triggering, by the one or more processors, execution of the asset trade. The method includes determining, by the one or more processors, a level of data accessibility associated with the set of asset trades for each entity in the set of entities by determining a role of each entity in the set of entities. The method includes automatically adjusting, by one or more processors, a level of data accessibility for each entity in the set of entities based on the entity's role.

[0022] In other features, the status includes either a pending status or a requested status. In other features, rejecting the asset transaction request includes preventing, by the one or more processors, disclosure of details related to the conflict to each entity. In other features, recommending at least one of a similar alternative asset and a set of similar alternative assets includes, by the one or more processors, automatically identifying at least one of a similar alternative asset and a set of similar alternative assets based on determining a similarity with the asset, the similarity being determined based on at least one of an asset type and an asset value. In other features, the method includes, in response to determining that the asset transaction request is fraudulent with respect to the asset, automatically recommending or indicating, by the one or more processors, a set of assets to be offered as alternative collateral for the loan transaction. In other features, in response to an entity of the set of entities being associated with a human, the role corresponds to a job title. In other features, a job title with more privileges corresponds to an increased level of data access. In other features, an increased level of data access corresponds to obtaining more detailed data. In other features, the low level of data access is associated with an entity of the set of entities that (i) is permitted to obtain at least one of statistical data and group data and (ii) is restricted from obtaining individual data. In other features, the higher level of data access is associated with an entity of the set of entities being permitted to obtain aggregate data. In other features, the method includes dynamically adjusting, by the one or more processors, the number of roles to accommodate fine-grained access permissions.

[0023] The system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions from the memory hardware. The instructions include receiving, by one or more processors, a set of asset trade requests associated with a set of asset trades. Each asset trade request in the set of asset trade requests is initiated by an entity in the set of entities. The instructions include determining, by the one or more processors, a status of each asset trade request in the set of asset trade requests. The instructions include determining, by the one or more processors, whether each asset trade request in the set of asset trade requests is approved for an asset specified by the respective asset trade request. The instructions include, in response to determining that the asset trade request is not authorized, rejecting, by the one or more processors, the asset trade request, and recommending, by the one or more processors, at least one of a similar substitute asset and a set of similar substitute assets as a substitute for the asset. The instructions include automatically triggering, by the one or more processors, execution of the asset trade in response to determining that the asset trade request is approved. The instructions include determining, by the one or more processors, a level of data accessibility associated with asset transactions for each entity in the set of entities by determining a role for each entity in the set of entities. The instructions include automatically adjusting, by the one or more processors, a level of data accessibility for each entity in the set of entities based on the entity's role.

[0024] In other features, the status includes either a pending status or a requested status. In other features, rejecting the asset trade request includes preventing, by the one or more processors, details related to the conflict from being disclosed to the respective entity. In other features, recommending at least one of a similar alternative asset and a set of similar alternative assets includes, by the one or more processors, automatically identifying at least one of a similar alternative asset and a set of similar alternative assets based on determining a similarity with the asset, the similarity being determined based on at least one of an asset type and an asset value. In other features, the system includes, in response to determining that the asset trade request is fraudulent with respect to the asset, automatically recommending or indicating, by the one or more processors, a set of assets to be offered as alternative collateral for the loan transaction. In other features, in response to an entity of the set of entities being associated with a human, the role corresponds to a job title. In other features, a job title with more privileges corresponds to an increased level of data access. In other features, an increased level of data access corresponds to obtaining more detailed data. In other features, the low level of data access relates to an entity of the set of entities being (i) permitted to obtain at least one of statistical data and group data and (ii) restricted from obtaining individual data. In other features, the higher level of data access relates to an entity of the set of entities being permitted to obtain aggregate data. In other features, the system includes dynamically adjusting, by the one or more processors, the number of roles to accommodate fine-grained permissions.

[0025] A method includes receiving, by one or more processors, a transaction request for a digital transaction to be performed on behalf of a business. The request is received from a device corresponding to a business entity and indicates a transaction type of the digital transaction, a transaction amount, and an account identifier of a counterparty account of the transaction. The method includes determining, by the one or more processors, whether the business entity has sufficient authorization to initiate the digital transaction requested by the business entity based on the transaction type and a set of authorization rules defined by the business. In response to determining that the business entity does not have sufficient authorization to initiate the digital transaction, the method includes determining, by the one or more processors, a second business entity that can authorize the digital transaction based on the set of authorization rules defined by the business, and sending, by the one or more processors, an authorization request to a user device of the second business entity. The authorization request requests that the second business entity approve or deny the digital transaction, and the one or more processors receive a response from the user device of the second business entity indicating whether the second business entity approved or denied the digital transaction, and, in response to the second entity's denial of the digital transaction, preventing execution of the digital transaction. The method includes, in response to determining that the business entity has sufficient authorization to initiate the digital transaction or that a second business entity has authorized the digital transmission, selecting a digital wallet from a plurality of business digital wallets to execute the digital transaction based on the transaction amount, the transaction type, and a set of authorization rules, wherein the plurality of digital wallets include different digital wallets managed by the business, and each business wallet of the plurality of business digital wallets manages one or more respective accounts of the business.

[0026] In other features, the method includes initiating a transaction monitoring workflow to monitor a result of the transaction in response to the selected digital wallet transferring the transaction amount to the counterparty account. In other features, the business entity is an employee of the business. In other features, determining whether the business entity has sufficient authorization to initiate the digital transaction includes determining a business entity's role in the business based on a business entity data store storing a set of entity records, each respective entity record defining a set of attributes of each entity associated with the business, including the respective entity's role within the organization, and determining whether the business entity has sufficient authorization to initiate the digital transaction based on the business role and the set of authorization rules. The set of authorization rules includes rules defining different types of digital transactions permitted to be performed on behalf of the business, and for each type of digital transaction, one or more roles of the business that have sufficient authorization to initiate each type of digital transaction. In other features, determining whether the business entity has sufficient authorization to initiate the digital transaction includes determining a business unit within the enterprise to which the business entity belongs based on an enterprise entity data store storing a set of entity records, each respective entity record defining a set of attributes of the respective entity related to the enterprise including the respective business unit of the respective entity; and determining whether the business entity has sufficient authorization to initiate the digital transaction based on the enterprise's business unit and the set of authorization rules. The set of authorization rules includes rules defining different types of digital transactions authorized to be performed on behalf of the enterprise and, for each type of digital transaction, one or more business units of the enterprise authorized to initiate each type of digital transaction.In other features, determining whether the business entity has sufficient authorization to initiate the digital transaction is further based on a transaction amount indicated by the transaction request. In other features, the authorization rules define transaction thresholds for different types of entities within the enterprise, such that a transaction request initiated by each entity requesting a transaction amount above the respective threshold triggers a request for approval from one or more other entities designated by the enterprise. In other features, the method includes verifying, by one or more processors, a digital signature corresponding to a response from the user device of the second business entity based on a public key associated with the second business entity. The digital signature is generated by the second user device using a private key associated with the second business entity, and determining, by the one or more processors, that the digital transaction is approved in response to verifying the digital signature and verifying that the response indicates that the second business entity approves the transaction. In other features, selecting a digital wallet from the plurality of enterprise digital wallets includes determining a transaction rail for executing the digital transaction from a plurality of potential transaction rails based on a transaction type defined in the transaction request, and selecting a digital wallet from the plurality of enterprise digital wallets is further based on the determined transaction rail. In other features, selecting a digital wallet from the plurality of corporate digital wallets includes determining one or more compatible corporate digital wallets from the plurality of digital wallets that can execute the transaction using the determined transaction rail based on the transaction type, and selecting the digital wallet from the one or more compatible digital wallets based on the transaction amount and a set of permission rules.

[0027] The system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions from the memory hardware. The instructions include receiving, by the one or more processors, a transaction request requesting a digital transaction to be performed on behalf of a business. The request is received from a device corresponding to a business entity and indicates a transaction type, a transaction amount, and an account identifier of a counterparty account for the digital transaction. The instructions include determining, by the one or more processors, whether the business entity has sufficient authorization to initiate the digital transaction requested by the business entity based on the transaction type and a set of authorization rules defined by the business. The instructions include, in response to determining that the business entity does not have sufficient authorization to initiate the digital transaction, determining, by the one or more processors, a second business entity that can authorize the digital transaction based on the set of authorization rules defined by the business, and sending, by the one or more processors, an authorization request to a user device of the second business entity. The authorization request requests that the second corporate entity approve or deny the digital transaction, and the one or more processors receive a response from the user device of the second corporate entity indicating whether the second corporate entity approved or denied the digital transaction, and in response to the second entity denying the digital transaction, block execution of the digital transaction. The instructions include, in response to determining that the corporate entity has sufficient authorization to initiate the digital transaction or that the second corporate entity has authorized the digital transmission, selecting a digital wallet from a plurality of corporate digital wallets to execute the digital transaction based on the transaction amount, the transaction type, and a set of authorization rules. The plurality of digital wallets include different digital wallets managed by the enterprise, and each corporate wallet of the plurality of corporate digital wallets manages one or more respective accounts of the enterprise.

[0028] In other features, the system includes initiating a transaction monitoring workflow to monitor a result of the transaction in response to the selected digital wallet transferring the transaction amount to the counterparty account. In other features, the corporate entity is an employee of the enterprise. In other features, determining whether the corporate entity has sufficient authorization to initiate the digital transaction includes determining a role of the corporate entity within the enterprise based on an enterprise entity data store storing a set of entity records, each respective entity record defining a set of attributes of each entity associated with the enterprise including the respective role of the respective entity within the organization, and determining whether the corporate entity has sufficient authorization to initiate the digital transaction based on the enterprise role and the set of permission rules. The set of permission rules includes rules defining different types of digital transactions that the entity is authorized to perform on behalf of, and for each type of digital transaction, one or more roles of the enterprise that have sufficient authorization to initiate each type of digital transaction. In other features, determining whether the business entity has sufficient authorization to initiate the digital transaction includes determining a business unit within the enterprise to which the business entity belongs based on an enterprise entity data store that stores a set of entity records, each entity record defining a set of attributes for each entity related to the enterprise including the respective business unit of the respective entity, and determining whether the business entity has sufficient authorization to initiate the digital transaction based on the business unit of the enterprise and the set of authorization rules. The set of authorization rules includes rules that define different types of digital transactions that are authorized to be performed on behalf of the enterprise and, for each type of digital transaction, one or more business units of the enterprise that are authorized to initiate each type of digital transaction.In other features, determining whether the business entity has sufficient authorization to initiate the digital transaction is further based on a transaction amount indicated by the transaction request. In other features, the authorization rules define transaction thresholds for different types of entities within the enterprise, such that a transaction request initiated by each entity requesting a transaction amount above the respective threshold triggers a request for approval from one or more other entities designated by the enterprise. In other features, the system includes verifying, by one or more processors, a digital signature corresponding to a response from the user device of the second business entity based on a public key associated with the second business entity. The digital signature is generated by the second user device using a private key associated with the second business entity, and the one or more processors verify the digital signature and determine, by verifying that the response indicates that the second business entity approves the transaction.

[0029] The non-transitory computer-readable medium includes instructions including receiving, by one or more processors, a transaction request requesting a digital transaction to be performed on behalf of a business. The request is received from a device corresponding to a business entity and indicates a transaction type of the digital transaction, a transaction amount, and an account identifier of a counterparty account of the transaction. The instructions include determining, by the one or more processors, whether the business entity has sufficient authorization to initiate the digital transaction requested by the business entity based on the transaction type and a set of authorization rules defined by the business. In response to determining that the business entity does not have sufficient authorization to initiate the digital transaction, the instructions include determining, by the one or more processors, a second business entity that can authorize the digital transaction based on the set of authorization rules defined by the business, and sending, by the one or more processors, an authorization request to a user device of the second business entity. The authorization request requests that the second business entity approve or deny the digital transaction. The instructions include receiving, by the one or more processors, a response from the user device of the second business entity indicating whether the second business entity has approved or denied the digital transaction. The instructions include, in response to the second entity rejecting the digital transaction, preventing execution of the digital transaction. The instructions include, in response to determining that the business entity has sufficient authorization to initiate the digital transaction or that the second business entity has authorized the digital transmission, selecting a digital wallet from a plurality of corporate digital wallets to execute the digital transaction based on the transaction amount, the transaction type, and a set of authorization rules. The plurality of digital wallets include different digital wallets managed by the business, and each corporate wallet of the plurality of corporate digital wallets manages one or more respective accounts of the business. The instructions include instructing the selected digital wallet to transfer the transaction amount to an account of the counterparty indicated by the transaction request.

[0030] In other features, the non-transitory computer-readable medium includes initiating a transaction monitoring workflow to monitor a result of the transaction in response to the selected digital wallet transferring the transaction amount to the counterparty account.

[0031] A method includes monitoring, by a transaction system executed by one or more processors, a data pool that aggregates multiple compliance standards associated with one or more types of digital transactions. The data pool maintains multiple different compliance parameters representing different values ​​and requirements used to facilitate compliance with the multiple compliance standards. One or more of the multiple different compliance parameters are updated in response to one or more changes to the compliance standards. The method includes receiving, by the transaction system, a transaction request to be executed on behalf of an enterprise. The method includes executing, by the transaction system, a transaction compliance workflow with respect to the transaction request. Executing the transaction compliance workflow includes: accessing, by the transaction system, the data pool to obtain an updated set of compliance parameters corresponding to one or more compliance standards associated with a type of transaction indicated in the transaction request; and parameterizing, by the transaction system, conditional logic defined in a compliance checklist with the updated set of compliance parameters; validating, based on the conditional logic parameterized with the updated set of compliance parameters, that the requested transaction complies with the one or more compliance standards associated with the type of transaction requested; and executing the digital transaction in response to verifying that the requested transaction complies with the one or more compliance standards.

[0032] In other features, the compliance standards are government regulatory standards, and the compliance parameters are values ​​and requirements defined by a governing body. In other features, the plurality of compliance standards include reporting requirements including a threshold for transactions requiring reportable amounts, and the compliance parameters include a threshold defining the threshold. In other features, the plurality of compliance standards include tax regulations, and the compliance parameters include one or more tax rates applicable to different types of transactions. In other features, the plurality of compliance standards are enterprise standards, and the plurality of compliance parameters are values ​​and requirements defined by the enterprise. In other features, the plurality of compliance standards include transaction amount limits, and the plurality of compliance parameters include a set of roles within the enterprise and, for each role, a maximum transaction amount that can be executed in each transaction initiated by the enterprise entity of the respective role. In other features, the plurality of compliance standards include account access rules, and the plurality of compliance parameters include a set of roles within the enterprise and, for each role, a set of enterprise accounts that can be used in each transaction initiated by the enterprise entity of the respective role. In other features, the plurality of compliance standards include accounts, and the plurality of compliance parameters include a set of roles within the enterprise and, for each role, a maximum transaction amount that can be executed in each transaction initiated by the enterprise entity of the respective role. In other features, the data pool is maintained by a company. In other features, the data pool is maintained by a regulatory body.

[0033] The system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions from the memory hardware. The instructions, executed by the one or more processors, include monitoring, by a transaction system, a data pool aggregating multiple compliance standards associated with one or more types of digital transactions. The data pool maintains multiple different compliance parameters representing different values ​​and requirements used to facilitate compliance with the multiple compliance standards. One or more of the multiple different compliance parameters are updated in response to one or more changes to the compliance standards. The instructions include receiving, by the transaction system, a transaction request to be executed on behalf of an enterprise. The instructions include executing, by the transaction system, a transaction compliance workflow with respect to the transaction request. Executing the transaction compliance workflow includes: accessing, by the transaction system, the data pool to obtain an updated set of compliance parameters corresponding to one or more compliance standards associated with a type of transaction indicated in the transaction request; parameterizing, by the transaction system, conditional logic defined in a compliance checklist with the updated set of compliance parameters; validating, based on the conditional logic parameterized with the updated set of compliance parameters, that the requested transaction complies with the one or more compliance standards associated with the type of transaction requested; and executing the digital transaction in response to verifying that the requested transaction complies with the one or more compliance standards.

[0034] In other features, the compliance standards are government regulatory standards, and the compliance parameters are values ​​and requirements defined by a governing body. In other features, the plurality of compliance standards include reporting requirements including a threshold for transactions requiring reportable amounts, and the compliance parameters include a threshold defining the threshold. In other features, the plurality of compliance standards include tax regulations, and the compliance parameters include one or more tax rates applicable to different types of transactions. In other features, the plurality of compliance standards are enterprise standards, and the plurality of compliance parameters are values ​​and requirements defined by the enterprise. In other features, the plurality of compliance standards include transaction amount limits, and the plurality of compliance parameters include a set of roles within the enterprise and, for each role, a maximum transaction amount that can be executed in each transaction initiated by the enterprise entity of the respective role. In other features, the plurality of compliance standards include account access rules, and the plurality of compliance parameters include a set of roles within the enterprise and, for each role, a set of enterprise accounts that can be used in each transaction initiated by the enterprise entity of the respective role. In other features, the plurality of compliance standards include accounts, and the plurality of compliance parameters include a set of roles within the enterprise and, for each role, a maximum transaction amount that can be executed in each transaction initiated by the enterprise entity of the respective role.

[0035] The non-transitory computer-readable medium includes instructions executed by one or more processors, including monitoring, by a transaction system, a data pool that aggregates multiple compliance standards associated with one or more types of digital transactions. The data pool maintains multiple different compliance parameters representing different values ​​and requirements used to facilitate compliance with the multiple compliance standards. One or more of the multiple different compliance parameters are updated in response to one or more changes to the compliance standards. The instructions include receiving, by the transaction system, a transaction request to be executed on behalf of an enterprise. The instructions include executing, by the transaction system, a transaction compliance workflow with respect to the transaction request. Executing the transaction compliance workflow includes: accessing, by the transaction system, the data pool to obtain an updated set of compliance parameters corresponding to one or more compliance standards associated with a type of transaction indicated in the transaction request; parameterizing, by the transaction system, conditional logic defined in a compliance checklist with the updated set of compliance parameters; validating, based on the conditional logic parameterized with the updated set of compliance parameters, that the requested transaction complies with the one or more compliance standards associated with the type of transaction requested; and executing the digital transaction in response to verifying that the requested transaction complies with the one or more compliance standards.

[0036] The instructions further include executing a transaction platform, executing a market orchestration system, executing a market orchestration architecture platform, executing a governance system, executing an intelligent data layer system, executing a cross-market transaction engine, executing a market prediction system, executing a quantum computing system, executing a trust network, executing a dual-process artificial neural network, executing an intelligence services system, executing a generative AI system, executing a graph data processing system, and executing an enterprise access system.

[0037] The method includes maintaining a first data item machine learning model configured to output a first score in response to a first type of input data. The method includes maintaining a second data item machine learning model configured to output a second score in response to a second type of input data. The method includes, in response to receiving the first input data, selectively processing a first subset of the first input data, including inputting the first subset of the first input data to the first data item machine learning model to generate a first score, and selectively storing the first subset of the first input data and the first score. The method includes selectively processing a second subset of the first input data, including inputting the second subset of the first input data to the second data item machine learning model to generate a second score, and selectively storing the second subset of the first input data and the second score. The method includes maintaining a data source machine learning model configured to output a source score in response to a source identifier. The method includes identifying a first source of the set of target data in response to a data access request () from a requester that identifies a set of target data responsive to the data access request, determining a first source score based on the identifier of the first source, and outputting a data access response to the requester. The method includes excluding the set of target data from the response in response to the first source score being below an access threshold, and selectively including the set of target data in the response in response to the first source score being above the access threshold.

[0038] In another feature, the method includes determining a first source score by inputting an identifier of the first source into a data source machine learning model. In another feature, the method includes determining the first source score by searching a stored score previously generated by inputting the identifier of the first source into the data source machine learning model. In another feature, the method includes determining an access threshold based on an identity of a requester. In another feature, the method includes determining the access threshold based on a role of the requester. In another feature, the data access request specifies a use case. The method further includes determining the access threshold based on the use case. In another feature, selectively processing the first subset of the first input data includes generating the first subset of the first input data by selecting data items of the first input data that match a first type, and in response to the first subset being non-empty, generating a first score by inputting the first subset of the first input data into a first data item machine learning model, and selectively storing the first subset of the first input data and the first score. In other features, generating the first subset of the first input data includes at least one of selecting all of the data items of the first input data that match the first type or selecting a random sampling of the data items of the first input data that match the first type. In other features, selectively storing the first subset of the first input data and the first score includes storing the first subset of the first input data and storing the first score in response to the first score satisfying a storage criterion, and discarding the first subset of the first input data in response to the first score not satisfying the storage criterion. In other features, satisfying the storage criterion includes at least one of the first score exceeding a storage threshold or the first score corresponding to one of a set of defined values ​​indicative of reliability.In other features, the identifier of the first source is a fully qualified domain name (FQDN) of a uniform resource locator (URL) at which the first source is hosted, accessed, or described.

[0039] The system includes memory hardware configured to store instructions and processor hardware configured to execute the instructions from the memory hardware. The instructions include maintaining a first data item machine learning model configured to output a first score in response to a first type of input data. The instructions include maintaining a second data item machine learning model configured to output a second score ( ) in response to a second type of input data. The instructions include, in response to receiving the first input data, selectively processing a first subset of the first input data, including generating a first score by inputting the first subset of the first input data to the first data item machine learning model and selectively storing the first subset of the first input data and the first score. The instructions include selectively processing a second subset of the first input data, including generating a second score by inputting a second subset of the first input data to the second data item machine learning model and selectively storing the second subset of the first input data and the second score. The instructions include maintaining a data source machine learning model configured to output a source score in response to a source identifier. The instructions include, in response to a data access request from a requester, identifying a set of target data responsive to the data access request, identifying a first source of the set of target data, determining a first source score based on the identifier of the first source, and outputting a data access response to the requester. The instructions include, in response to the first source score falling below an access threshold, excluding the set of target data from the response, and in response to the first source score rising above the access threshold, selectively including the set of target data in the response.

[0040] In other features, the system includes determining a first source score by inputting an identifier of the first source into a data source machine learning model. In other features, the system includes determining the first source score by searching a stored score previously generated by inputting the identifier of the first source into the data source machine learning model. In other features, the system includes determining an access threshold based on an identity of a requester. In other features, the system includes determining the access threshold based on a role of the requester. In other features, the data access request specifies a use case. The instructions further include determining the access threshold based on the use case. In other features, selectively processing the first subset of the first input data includes generating the first subset of the first input data by selecting data items of the first input data that match a first type. The instructions include, in response to the first subset being non-empty, generating a first score by inputting the first subset of the first input data into a first data item machine learning model and selectively storing the first subset of the first input data and the first score.

[0041] The non-transitory computer-readable medium includes instructions including maintaining a first data item machine learning model configured to output a first score in response to a first type of input data. The instructions include maintaining a second data item machine learning model configured to output a second score in response to a second type of input data. The instructions include, in response to receiving the first input data, selectively processing a first subset of the first input data, including generating a first score ( ) by inputting the first subset of the first input data to the first data item machine learning model and selectively storing the first subset of the first input data and the first score. The instructions include selectively processing a second subset of the first input data, including generating a second score by inputting a second subset of the first input data to the second data item machine learning model and selectively storing the second subset of the first input data and the second score. The instructions include maintaining a data source machine learning model configured to output a source score in response to a source identifier. The instructions include, in response to a data access request from a requester, identifying a set of target data responsive to the data access request, identifying a first source of the set of target data, determining a first source score based on the identifier of the first source, and outputting a data access response to the requester. The instructions include, in response to the first source score falling below an access threshold, excluding the set of target data from the response, and in response to the first source score rising above the access threshold, selectively including the set of target data in the response.

[0042] In other features, selectively storing the first subset of the first input data and the first score includes storing the first subset of the first input data and storing the first score in response to the first score satisfying a storage criterion, and discarding the first subset of the first input data in response to the first score not satisfying the storage criterion. [Brief explanation of the drawings]

[0043] The present disclosure and detailed description of certain embodiments thereof can be understood by reference to the following drawings.

[0044] [Figure 1] FIG. 1 is a schematic diagram of components of a platform that enables intelligent trading according to an embodiment of the present disclosure.

[0045] [Figure 2A] 2A and 2B are schematic diagrams of additional components of a platform that enables intelligent trading according to embodiments of the present disclosure. [Figure 2B] 2A and 2B are schematic diagrams of additional components of a platform that enables intelligent trading according to embodiments of the present disclosure.

[0046] [Figure 3] FIG. 3 is a schematic diagram of additional components of a platform that enables intelligent trading according to an embodiment of the present disclosure.

[0047] [Figure 4] Figure 4 illustrates the system components and interactions that enable transactional, financial, and marketplace functionality.

[0048] [Figure 5] Figure 5 illustrates the components and interactions of a set of data processing layers of the system that implement transactional, financial, and marketplace functionality.

[0049] [Figure 6] Figure 6 illustrates the adaptive intelligence and robotic process automation (RPA) capabilities of the system that enable transactional, financial, and marketplace functions.

[0050] [Figure 7]Figure 7 illustrates the opportunity mining capabilities of the transactional, financial, and marketplace support system.

[0051] [Figure 8] Figure 8 illustrates adaptive edge computation management and edge intelligence capabilities for transactional, financial, and marketplace support systems.

[0052] [Figure 9] Figure 9 illustrates the protocol adaptation and adaptive data storage capabilities of the transaction, financial, and marketplace support system.

[0053] [Figure 10] Figure 10 illustrates the robotic operational analytics capabilities of trading, financial, and marketplace support systems.

[0054] [Figure 11] Figure 11 shows a blockchain and smart contract platform for event access futures markets.

[0055] [Figure 12] Figure 12 shows the algorithm and dashboard of the blockchain and smart contract platform for the event access rights futures market.

[0056] [Figure 13] Figure 13 shows the blockchain and smart contract platform for futures market demand aggregation.

[0057] [Figure 14] Figure 14 shows the algorithm and dashboard of the blockchain and smart contract platform for futures market demand aggregation.

[0058] [Figure 15]Figure 15 shows a blockchain and smart contract platform for crowdsourcing innovation.

[0059] [Figure 16] Figure 16 shows the algorithm and dashboard of a blockchain and smart contract platform for crowdsourcing innovation.

[0060] [Figure 17] Figure 17 shows a blockchain and smart contract platform for the purpose of crowdsourcing evidence.

[0061] [Figure 18] Figure 18 shows the algorithm and dashboard of a blockchain and smart contract platform for crowdsourcing evidence.

[0062] [Figure 19] Figure 19 shows the components and interactions in an example implementation of a lending platform with a set of data integration microservices including data collection and monitoring services for processing lending entities and transactions.

[0063] [Figure 20] Figure 20 shows an example of an energy and computational resource platform.

[0064] [Figure 21] Figure 21 shows an example of a facility data record.

[0065] [Figure 22] Figure 22 shows an example schema for a personal data record.

[0066] [Figure 23]Figure 23 shows the cognitive processing system.

[0067] [Figure 24] Figure 24 shows the process by which a lead generation system generates a lead list.

[0068] [Figure 25] Figure 25 illustrates the process by which the lead generation system determines facility output for identified leads.

[0069] [Figure 26] Figure 26 shows the process for generating and outputting personalized content.

[0070] [Figure 27] FIG. 27 is a schematic diagram illustrating a portion of an example information technology system for trading artificial intelligence utilizing digital twins, according to one embodiment of the present disclosure.

[0071] [Figure 28] FIG. 28 is a schematic diagram illustrating a compliance system that facilitates licensing of moral rights according to one embodiment of the present disclosure.

[0072] [Figure 29] FIG. 29 shows a schematic diagram illustrating example components of a compliance system in accordance with one embodiment of the present disclosure.

[0073] [Figure 30] FIG. 30 illustrates a set of operations for a method for screening potential licensees for the purpose of licensing personality rights of a licensor, in one embodiment of the present disclosure.

[0074] [Figure 31] FIG. 31 illustrates a set of operations for a method by which a licensee can facilitate licensing of a licensor's personality rights, according to one embodiment of the present disclosure.

[0075] [Figure 32] FIG. 32 illustrates a set of operations for a method of detecting potential circumvention of rules or regulations by a licensor and / or licensee, according to one embodiment of the present disclosure.

[0076] [Figure 33] Figure 33 shows an example of how to select an AI solution.

[0077] [Figure 34] Figure 34 shows an example of how to select an AI solution.

[0078] [Figure 35] Figure 35 shows an example of an assembled AI solution.

[0079] [Figure 36] Figure 36 shows the AI ​​solution selection and configuration system.

[0080] [Figure 37] FIG. 37 shows a system for selecting and configuring artificial intelligence models.

[0081] [Figure 38] FIG. 38 shows how to select and configure an artificial intelligence model.

[0082] [Figure 39] FIG. 39 is a schematic diagram illustrating an example of an architecture of a digital twin system according to an embodiment of the present disclosure.

[0083] [Figure 40] FIG. 40 is a schematic diagram illustrating exemplary components of a digital twin management system according to an embodiment of the present disclosure.

[0084] [Figure 41]FIG. 41 is a schematic diagram illustrating an example of a digital twin I / O system that interfaces with an environment, a digital twin system, and / or components thereof and provides bidirectional data transfer between connected components, according to an embodiment of the present disclosure.

[0085] [Figure 42] FIG. 42 is a schematic diagram illustrating examples of identified states related to an industrial environment that may be identified and / or stored by a digital twin system and accessible to an intelligent system (e.g., a cognitive intelligence system) or a user of the digital twin system in an embodiment of the present invention.

[0086] [Figure 43] FIG. 43 is a schematic diagram illustrating an exemplary embodiment showing how a client application and / or one or more embedded digital twins can update the attribute set of a digital twin of the present disclosure.

[0087] [Figure 44] FIG. 44 is a schematic diagram illustrating an exemplary embodiment showing how a set of shutdown probability values ​​for a manufacturing facility in an enterprise digital twin may be updated on behalf of a client application.

[0088] [Figure 45] FIG. 45 is a schematic diagram illustrating an illustrative embodiment of a method for updating a set of downtime cost values ​​for machines in a digital twin of a manufacturing facility.

[0089] [Figure 46] FIG. 46 is a schematic diagram illustrating components of a knowledge distribution system and communication network for facilitating management of digital knowledge according to an embodiment of the present disclosure.

[0090] [Figure 47] FIG. 47 is a schematic diagram illustrating a ledger network of a knowledge distribution system according to an embodiment of the present disclosure.

[0091] [Figure 48] Figure 48 is a schematic diagram of the knowledge distribution system of Figure 46, including details of the smart contracts and smart contract system of the knowledge distribution system according to an embodiment of the present invention.

[0092] [Figure 49] FIG. 49 is a schematic diagram of multiple data stores in a knowledge distribution system according to an embodiment of the present invention.

[0093] [Figure 50] FIG. 50 illustrates a method for deploying knowledge tokens and associated smart contracts through a knowledge distribution system according to an embodiment of the present disclosure.

[0094] [Figure 51] FIG. 51 illustrates a method for executing a high-level process flow of a smart contract for distributing digital knowledge through a knowledge distribution system according to an embodiment of the present disclosure.

[0095] [Figure 52] FIG. 52 is a schematic diagram illustrating another embodiment of components of a knowledge distribution system and a communication network for facilitating management of digital knowledge, according to an embodiment of the present disclosure.

[0096] [Figure 53] FIG. 53 shows a knowledge distribution system for controlling rights associated with digital knowledge.

[0097] [Figure 54] FIG. 54 illustrates a computer-implemented method for controlling rights associated with digital knowledge.

[0098] [Figure 55] FIG. 55 is a computer-implemented method for controlling rights associated with digital knowledge.

[0099] [Figure 56] FIG. 56 is a knowledge distribution system for controlling rights associated with digital knowledge.

[0100] [Figure 57] Figure 57 shows possible components of a 3D printer instruction set.

[0101] [Figure 58] Figure 58 shows the possible content of tokenized digital knowledge.

[0102] [Figure 59] Figure 59 shows the possible actions of a smart contract.

[0103] [Figure 60] Figure 60 shows the possible conditions associated with a trigger event.

[0104] [Figure 61] Figure 61 shows the possible controls and access privileges.

[0105] [Figure 62] Figure 62 shows the possible trigger events.

[0106] [Figure 63] FIG. 63 illustrates an example of a computer-implemented method for controlling rights associated with digital knowledge.

[0107] [Figure 64] FIG. 64 illustrates an example of a computer-implemented method for controlling rights associated with digital knowledge.

[0108] [Figure 65] Figure 65 shows an example of crowdsourced information.

[0109] [Figure 66]Figure 66 shows the possible contents of a distributed ledger.

[0110] [Figure 67] Figure 67 shows the possible parameters.

[0111] [Figure 68] Figure 68 shows an example implementation of a knowledge distribution system for controlling rights associated with digital knowledge.

[0112] [Figure 69] Figures 69-74 show examples of operations for controlling rights associated with digital knowledge. [Figure 70] Figures 69-74 show examples of operations for controlling rights associated with digital knowledge. [Figure 71] Figures 69-74 show examples of operations for controlling rights associated with digital knowledge. [Figure 72] Figures 69-74 show examples of operations for controlling rights associated with digital knowledge. [Figure 73] Figures 69-74 show examples of operations for controlling rights associated with digital knowledge. [Figure 74] Figures 69-74 show examples of operations for controlling rights associated with digital knowledge.

[0113] [Figure 75] FIG. 75 is a diagrammatic view illustrating an example implementation of a knowledge distribution system including a trust network that uses consensus trust scores to identify potential fraudulent transactions and prevent such fraudulent transactions in one embodiment of the present disclosure.

[0114] [Figure 76] FIG. 76 shows an example method for illustrating the operation of the example trust network shown in FIG. 75 in one embodiment of the present disclosure.

[0115] [Figure 77] FIG. 77 illustrates a schematic diagram of a transaction being processed by a ledger network including multiple node computing devices, according to one embodiment of the present invention.

[0116] [Figure 78] Figure 78 is a schematic diagram showing an exemplary embodiment of a knowledge distribution system including a digital marketplace that provides an environment for knowledge providers and knowledge recipients to conduct commercial transactions related to the transfer of digital knowledge, in accordance with one embodiment of the present invention.

[0117] [Figure 79] FIG. 79 is a schematic diagram illustrating an example user interface of a digital marketplace that enables trading and commerce between users of a knowledge distribution system, according to one embodiment of the present disclosure.

[0118] [Figure 80] FIG. 80 is a schematic diagram illustrating an example embodiment of a market orchestration system according to one embodiment of the present disclosure.

[0119] [Figure 81] Figure 81 is a schematic diagram illustrating an example embodiment of a marketplace orchestration system that includes a marketplace configuration system that enables the configuration and activation of a marketplace.

[0120] [Figure 82] FIG. 82 is a diagram illustrating an exemplary embodiment of a method for configuring and launching a marketplace in accordance with one embodiment of the present invention.

[0121] [Figure 83] FIG. 83 is a schematic diagram illustrating an example embodiment of a marketplace orchestration system with a robotic process automation system that automates internal marketplace workflows based on robotic process automation (RPA).

[0122] [Figure 84] FIG. 84 is a schematic diagram illustrating an example embodiment of a market orchestration system with edge devices performing edge computing and intelligence.

[0123] [Figure 85] FIG. 85 is a schematic diagram illustrating an example embodiment of a market orchestration system including a digital twin system configured to integrate adaptive edge computing systems with the market orchestration digital twin.

[0124] [Figure 86] FIG. 86 is a schematic diagram of a digital twin system in some embodiments. Market Orchestration Architecture Diagram

[0125] [Figure 87] FIG. 87 shows a block diagram of a market orchestration architecture that integrates the cross-market exchange methods and systems described herein.

[0126] [Figure 88] Figure 88 shows an example of normalizing the value of an item in an exchange-specific currency.

[0127] [Figure 89] Figure 89 shows an example of normalizing item values ​​in exchange-specific currencies between sets.

[0128] [Figure 90] Figure 90 shows an example of normalizing the value of an item in multiple exchange-specific currencies.

[0129] [Figure 91] Figure 91 shows an example of item value conversion between exchanges.

[0130] [Figure 92]Figure 92 shows an example of conditional item value conversion between exchanges.

[0131] [Figure 93] FIG. 93 illustrates an example of the generation of an item representative token for use at a target exchange based on the characteristics of an item at a source exchange.

[0132] [Figure 94] FIG. 94 shows an example of generating an item representative token by applying the item characteristic extraction algorithm of FIG.

[0133] [Figure 95] Figure 95 shows an example of generating the item representative token of Figure 93 through processing of a smart contract associated with the item at the source exchange.

[0134] [Figure 96] FIG. 96 shows an example of generating an entitlement token for an item based on one or more of the item's smart contract or terms of use.

[0135] [Figure 97] FIG. 97 illustrates an example of generating rights tokens for an item based on one or more of the item's smart contract or terms of use, and subject to the governing rules of the exchange platform.

[0136] [Figure 98] Figure 98 shows an example of generating entitlement tokens for an item based on whether the detected entitlements comply with exchange governance rules, based on one or more of the item's smart contract and / or terms of use.

[0137] [Figure 99] Figure 99 shows an example of generating adaptive rights tokens for an item based on one or more of the item's smart contract and / or terms of use and the target exchange's adaptive rules.

[0138] [Figure 100] Figure 100 shows an example of automatically cascading actions between exchanges where workflows are automated through Robotic Process Automation (RPA).

[0139] [Figure 101] Figure 101 shows an example of automatically cascading workflow initiation actions between exchanges where workflows are automated through Robotic Process Automation (RPA).

[0140] [Figure 102] Figure 102 shows an example of automatically cascading workflow actions between exchanges where workflows are automated through Robotic Process Automation (RPA).

[0141] [Figure 103] Figure 103 shows an example of applying robotic process automation to generate a cross-exchange smart contract from an exchange-specific smart contract.

[0142] [Figure 104] Figure 104 illustrates an example of a self-adaptive asset data distribution network infrastructure pipeline that includes one or more of the normalization, value transformation, item tokenization, or rights tokenization methods or systems described herein. Intelligent Data Layer Diagram

[0143] [Figure 105] Figure 105 shows a block diagram of exemplary functions, capabilities, and interfaces of the Intelligent Data Layer Platform.

[0144] [Figure 106]Figure 106 shows an example block diagram of an intelligent data layer architecture.

[0145] [Figure 107] Figure 107 shows a block diagram of an independently operating intelligent data layer that generates data for multiple data consumers.

[0146] [Figure 108] Figure 108 shows a deployment block diagram of an intelligent data layer platform for an enterprise data strategy approach.

[0147] [Figure 109] Figure 109 shows a block diagram of a remote intelligent data layer with actively deployed elements for dynamic on-demand IDL manipulation.

[0148] [Figure 110] Figure 110 shows a diagram of the mapping parameters between data producers (e.g., sources) and data consumers.

[0149] [Figure 111] Figure 111 shows a block diagram of an intelligent data layer deployment in an enterprise.

[0150] [Figure 112] Figure 112 shows a block diagram of a network configured with an intelligent data layer.

[0151] [Figure 113] Figure 113 shows a block diagram of an exemplary cloud-based deployment of the Intelligent Data Layer architecture.

[0152] [Figure 114]Figure 114 shows a block diagram of a multi-use (configurable) intelligent data layer architecture that generates different layer content and intelligence for different purposes / uses / consumers.

[0153] [Figure 115] Figure 115 shows a block diagram of the Intelligent Data Layer marketplace / transaction environment deployment.

[0154] [Figure 116] Figure 116 is a block diagram illustrating the use of an intelligent data layer for source discovery. Market Orchestration Diagram of Data and Network Pipelines.

[0155] [Figure 117] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 118] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 119] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 120] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 121] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 122] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 123] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 124] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 125] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 126] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 127] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 128] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 129] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 130] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 131] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 132] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 133]Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram. [Figure 134] Figures 117-134 show the various functions associated with the data network and infrastructure pipeline. Cross-Market Trading Engine Diagram.

[0156] [Figure 135] FIG. 135 illustrates an exemplary environment for a cross-market trading engine in one embodiment of the present disclosure.

[0157] [Figure 136] 136 illustrates another exemplary environment for a cross-market trading engine in accordance with one embodiment of the present disclosure.

[0158] [Figure 137] 137 is a schematic diagram illustrating an embodiment of a market prediction system platform according to the present disclosure.

[0159] [Figure 138] FIG. 138 is a schematic diagram illustrating an example embodiment of a quantum computing service according to some embodiments of the present disclosure.

[0160] [Figure 139] Figure 139 illustrates the process of requesting quantum computing services in one embodiment of the present invention. Trust network diagram.

[0161] [Figure 140] 140-144 illustrate an exemplary trust network in communication with a cryptocurrency trading device, an intermediary trading system, and an automated trading system. [Figure 141] 140-144 illustrate an exemplary trust network in communication with a cryptocurrency trading device, an intermediary trading system, and an automated trading system. [Figure 142] 140-144 illustrate an exemplary trust network in communication with a cryptocurrency trading device, an intermediary trading system, and an automated trading system. [Figure 143] 140-144 illustrate an exemplary trust network in communication with a cryptocurrency trading device, an intermediary trading system, and an automated trading system. [Figure 144] 140-144 illustrate an exemplary trust network in communication with a cryptocurrency trading device, an intermediary trading system, and an automated trading system.

[0162] [Figure 145] FIG. 145 shows a method for illustrating the operation of an exemplary trust network.

[0163] [Figure 146] FIG. 146 is a functional block diagram of an example node that calculates local and consensus confidence scores.

[0164] [Figure 147] FIG. 147 is a functional block diagram of an exemplary node that calculates a consensus confidence score.

[0165] [Figure 148] FIG. 148 is a flowchart of an exemplary method for calculating a consensus confidence score.

[0166] [Figure 149] Figure 149 is a functional block diagram of an exemplary node that calculates reputation values.

[0167] [Figure 150] Figure 150 is a functional block diagram of an example node implementing a token economy for a trust network.

[0168] [Figure 151] Figure 151 shows an example method to explain how the reward protocol works.

[0169] [Figure 152] 152 and 153 show a graphical user interface (GUI) for requesting and reviewing a trust report.

[0170] [Figure 153] 152 and 153 show a graphical user interface (GUI) for requesting and reviewing a trust report. [Fig. 154] Figure 307 is a functional block diagram of the trust network used in implementing payment insurance.

[0171] [Figure 155] Figure 155 is an example showing the relationship between staked tokens and the cost of the consensus trust score.

[0172] [Figure 156] Figure 156 shows example services associated with different levels of nodes.

[0173] [Figure 157] Figure 157 shows an exemplary relationship between the number of nodes, the number of clans, address overlap, and the probability that a node will have a single address under its control.

[0174] [Figure 158] Figure 158 shows an example of the amount of token stake and the number of nodes.

[0175] [Figure 159] Figure 159 is a functional block diagram of an exemplary trust score determination module and local trust data store.

[0176] [Figure 160] Figure 160 is a technique that illustrates the operation of an exemplary confidence score determination module.

[0177] [Figure 161]Figure 161 shows the functional block diagram of the data acquisition and processing module.

[0178] [Figure 162] Figure 162 is a functional block diagram of the blockchain data acquisition and processing module.

[0179] [Figure 163] Figures 163-164 illustrate the creation and processing of the blockchain graph data structure. [Fig. 164] Figures 163-164 illustrate the creation and processing of the blockchain graph data structure.

[0180] [Figure 165] Figure 165 is a functional block diagram of the scoring feature generation module and the scoring model generation module.

[0181] [Figure 166] Figure 166 is a functional block diagram that explains the operation of the score generation module.

[0182] [Figure 167] Figure 167 shows an environment containing a cryptocurrency blockchain network running smart contracts.

[0183] [Figure 168] Figure 168 shows how the environment in Figure 167 works.

[0184] [Figure 169] Figure 169 is a functional block diagram showing the interaction between the sender user device, the intermediate transaction system, the blockchain network, and the trust network / system.

[0185] [Figure 170]Figures 170-171 show an example trust system and an example trust node that can determine the trust score of a blockchain address. [Figure 171] Figures 170-171 show an example trust system and an example trust node that can determine the trust score of a blockchain address.

[0186] [Figure 172] Figures 172-173 show an example sender interface on a user device. [Figure 173] Figures 172-173 show an example sender interface on a user device.

[0187] [Fig. 174] Figure 174 shows an exemplary way of explaining the operation of an intermediate trading system.

[0188] [Figure 175] Figure 175 shows an exemplary way of explaining the operation of a trust network / system: a dual-process artificial neural network diagram.

[0189] [Figure 176] Figure 176 is a schematic diagram of a dual-process artificial neural network system according to some embodiments.

[0190] [Figure 177] FIG. 177 is a schematic diagram illustrating an example of a biologically based system according to the present disclosure.

[0191] [Figure 178] 178 is a schematic diagram of a Thalamic Service Intelligence Service System according to the present disclosure.

[0192] [Figure 179] FIG. 179 is a schematic diagram illustrating an example of an intelligence services system according to some embodiments.

[0193] [Figure 180] FIG. 180 is a schematic diagram illustrating an example of a neural network according to some embodiments.

[0194] [Figure 181] FIG. 181 is a schematic diagram illustrating an example of a convolutional neural network in some embodiments.

[0195] [Figure 182] FIG. 182 is a schematic diagram illustrating an example of a neural network in some embodiments.

[0196] [Figure 183] FIG. 183 is a diagram of a reinforcement learning based approach in some embodiments.

[0197] [Figure 184] Figure 184 shows a block diagram of exemplary functions, capabilities, and interfaces of a robust generative artificial intelligence platform. Enterprise Access Layer Diagram.

[0198] [Figure 185] Figure 185 is a schematic diagram illustrating an example of an enterprise ecosystem including an enterprise access layer.

[0199] [Figure 186] Figure 186 is a functional block diagram of an exemplary implementation of the Enterprise Access Layer.

[0200] [Figure 187] Figure 187 is an exemplary schematic diagram of how the enterprise access layer in Figure 186 integrates with each part of the enterprise ecosystem.

[0201] [Figure 188] FIG. 188 is a schematic diagram illustrating an example marketplace orchestration system including an enterprise access layer.

[0202] [Figure 189] FIG. 189 is a functional block diagram of an exemplary implementation of an intelligence system.

[0203] [Figure 190] FIG. 190 is a functional block diagram of an exemplary implementation of a data pool system.

[0204] [Figure 191] FIG. 191 is a functional block diagram of an exemplary implementation of the scoring system. DETAILED DESCRIPTION OF THE INVENTION

[0205] (Detailed explanation) As used herein, the term "service / microservice" (and similar terms) should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, a service / microservice includes a system (or platform) configured to perform the functions of the service. The system is data-integrated and may include data collection circuitry, blockchain circuitry, artificial intelligence circuitry, and / or smart contract circuitry for processing loan entities and transactions. A service / microservice facilitates data processing and may include the following functions: data extraction, transformation, and loading functions; data cleansing and deduplication functions; data normalization functions; data synchronization functions; data security functions; computation functions (e.g., performing predefined computational operations on data streams and providing output streams); compression and decompression functions; analytics functions (e.g., providing automated generation of data visualizations), data processing functions, and / or data storage functions (including storage retention, formatting, compression, migration, etc.).

[0206] A service / microservice may include controllers, processors, network infrastructure, input / output devices, servers, client devices (e.g., laptops, desktops, terminals, mobile devices, dedicated devices), sensors (e.g., IoT sensors associated with one or more entities, equipment, or collateral), actuators (e.g., automatic locks, notification devices, lighting controls, camera controls, etc.), virtualized versions of one or more of the above (e.g., cloud storage, outsourced computing resources such as computing operations, virtual sensors, collected subscription data such as stock or commodity prices, record logs, etc.), and / or components configured as computer-readable instructions that, when executed by a processor, cause the processor to perform one or more functions of the service. A service may be distributed across multiple devices, and / or the functions of a service may be performed by one or more devices that cooperate to perform the given functions of the service.

[0207] A service / microservice may include application programming interfaces that facilitate connectivity between components of a system that executes the service (e.g., a microservice) and between the system and entities external to the system (e.g., programs, websites, user devices, etc.). Without limiting other aspects of this disclosure, examples of microservices that may be present in particular embodiments include: (a) a set of multimodal data collection circuitry that collects and monitors information about entities related to loan transactions; (b) a blockchain circuitry for maintaining a secure historical ledger of loan-related events, with access control capabilities that manage access by the set of parties involved in the loan; (c) a set of application programming interfaces, data integration services, data processing workflows, and user interfaces for processing loan-related events and activities; and (d) a smart contract circuitry for specifying the terms of a smart contract that governs at least one of the loan terms, loan-related events, or loan-related activities. Any service / microservice may be controlled by or have control over a controller. A particular system may not be considered a service / microservice. For example, a point-of-sale device that simply charges a flat fee for goods or services may not be considered a service. As another example, a service that tracks the cost of goods or services and triggers notifications when the value changes may depend on a rating service rather than being the rating service itself, or may be a component of a rating service in certain embodiments.A particular circuit, controller, or device may be a service or a component of a service if its functionality or capabilities are configured to support a service or microservice described herein, but may not be a service or a component of a service in other embodiments (e.g., if the functionality or capabilities of the circuit, controller, or device are not related to the service or microservice described herein). As another example, a mobile device operated by a user may constitute part of a service described herein (e.g., when the user accesses the service's functionality through an application or other communication from the mobile device, or when monitoring functions are performed via the mobile device). However, it may not constitute a component of a service at other times (e.g., after a transaction is completed, after the user uninstalls the application, and / or when the monitoring function is stopped or delegated to another device). Accordingly, the benefits of this disclosure are applicable to a variety of processes and systems, and such processes and systems may be considered services (or components of services) herein.

[0208] A person skilled in the art, armed with the disclosure herein and commonly available knowledge of such systems, will be able to determine which aspects of the present specification will be beneficial to a particular system and how to combine and build processes and systems herein to provide performance characteristics (e.g., bandwidth, computational power, response time, etc.) or operational functionality (e.g., time between checks, availability requirements (e.g., long-term requirements including continuous operation time and / or time-order based requirements (e.g., time of day, calendar time, etc.)), sensor resolution and / or accuracy, data determination (e.g., accuracy, timing, data volume), and / or actuator confirmation functionality) of service components sufficient to provide a particular embodiment of the service, platform, and / or microservice (including the "Services" listed below). Considerations that a person skilled in the art should consider when determining the configuration of components, circuits, controllers, and / or devices to implement the service, platform, and / or microservice (including the "Services" listed below) include, but are not limited to, the following: Not including: the balance between capital and operational costs in implementing and operating the service; the availability, speed, and / or bandwidth of network services available to system components, service users, and other entities that interact with the service; response time considerations for the service (e.g., the speed at which decisions within the service are implemented to support the service's commercial function, the uptime of artificial intelligence or other computationally intensive operations) and / or the capital or operational costs of supporting a particular response time; the location of interacting components of the service and the impact such location has on the operation of the service (e.g., location of data storage and related regulatory frameworks, network communication limitations and / or costs, power costs depending on location, availability of support in time zones relevant to the service, etc.); the availability of particular sensor types, support for those sensors; and the availability of sufficient alternatives for the sensor's purposes (e.g., cameras may require supplemental lighting or may require high-bandwidth network or local storage);Aspects of the value underlying certain aspects of the Services (e.g., the principal amount of the loan, the value of the collateral, the volatility of the collateral value, the net worth or relative net worth of the lender, guarantor, and / or borrower, etc.); the time sensitivity of the underlying value (e.g., whether its value changes rapidly or slowly relative to the operation of the Services or the term of the loan); trust metrics between the transacting parties (e.g., the trading history, credit ratings, social reputation, or other external metrics between the transacting parties, whether the activity related to the transaction conforms to industry standards or other standardized transaction types, etc.); and / or cost recovery options available for particular configurations and / or functionality of the Services, platform, and / or microservices (e.g., subscriptions, fees, service consideration, etc.). Without being limited to any other aspect of this disclosure, certain operations performed by the Services may include modifying loans in real time based on tracked data; utilizing data to execute secured smart contracts; revaluing debt transactions in response to tracked terms or data, etc. While specific service / microservice examples and considerations are described herein for illustrative purposes, any system benefiting from the disclosure herein and any considerations understood by one of ordinary skill in the art having the benefit of the disclosure herein are expressly encompassed within the scope of this specification;

[0209] Services include, but are not limited to, financial services (e.g., loan transaction services), data collection services (e.g., data collection services (data collection and monitoring)), blockchain services (e.g., blockchain services (maintaining secure data)), data integration services (e.g., data integration services (aggregating data)), smart contract services (e.g., smart contract services that determine the elements of a smart contract), software services (e.g., software services that extract data related to entities from public information sites), crowdsourcing services (e.g., crowdsourcing services that collect and report information), internet of things services (e.g., internet of things services that monitor the environment), publishing services (e.g., publishing data services that perform one or more functions include: publishing services that publish data, microservices (e.g., having a set of application programming interfaces that facilitate connectivity between microservices), valuation services (e.g., using valuation models to set values ​​for collateral based on information), artificial intelligence services, market value data collection services (e.g., monitoring and reporting marketplace information), clustering services (e.g., grouping collateral items based on matching attributes), social networking services (e.g., enabling configuration of social network parameters), asset identification services (e.g., identifying sets of assets for which a financial institution has custody responsibility), identity management services (e.g., verifying identities and entitlements for a financial institution), and similar functional terms. Exemplary services that perform one or more functions herein include computing devices; servers; network-connected devices; user interfaces; device-to-device interfaces (e.g., communication protocols, shared information and / or information storage, and / or application programming interfaces (APIs)), sensors (e.g., IoT sensors operatively connected to monitored components, equipment, locations, etc.), distributed ledgers, circuits, and / or computer-readable code configured to perform one or more functions of the service. An aspect or component of the service may be:They may be distributed across multiple devices or may be integrated in whole or in part into a particular device. In embodiments, aspects or components of the services may be implemented at least in part through circuitry, such as, by way of non-limiting example, a data collection service implemented at least in part through circuitry structured as data collection circuitry and performing data collection and monitoring; a blockchain service configured at least in part as blockchain circuitry and designed to maintain secure data; a data integration service configured at least in part as data integration circuitry and designed to aggregate data; a smart contract service configured at least in part as smart contract circuitry and designed to determine aspects of smart contracts; a software service configured at least in part as software service circuitry and designed to extract data related to entities from public information sites; a crowdsourcing service implemented at least in part as crowdsourcing circuitry and having information gathering and reporting capabilities; an IoT service. the service is implemented at least in part as an IoT circuit and has a function of monitoring the environment; the publishing service is implemented at least in part as a publishing service circuit and has a function of publishing data; the microservice service is implemented at least in part as a microservice circuit and has a function of interconnecting a plurality of service circuits; the valuation service is implemented at least in part as a valuation service circuit that accesses a valuation model based on the data to set a value for the collateral; the artificial intelligence service is implemented at least in part as an artificial intelligence service circuit; the market value data collection service is implemented at least in part as a market value data collection service circuit that monitors and reports market information; the clustering service is implemented at least in part as a clustering service circuit that groups collateral items based on attribute matches; and the social network service is implemented in part or in whole as a social network analysis service circuit and has a function of setting parameters related to the social network.and similar services, implementing some or all of the asset identification service as an asset identification service circuit and functioning to identify a set of assets for which a financial institution has custody responsibility. Accordingly, the benefits of the present disclosure are applicable to a variety of systems, and such systems may be discussed with respect to the items and services described herein. However, in certain embodiments, a particular system may not be discussed with respect to the items and services described herein. Armed with the disclosure herein and commonly available knowledge of such systems, one skilled in the art can readily identify which aspects of the present disclosure are beneficial to a particular system, or how to combine processes or systems herein to improve the operation of such a system. In determining the configuration for a particular service, considerations that a person skilled in the art should take into account include: distribution and access devices available to one or more of the parties to a particular transaction; jurisdictional restrictions on the storage, type, and communication of particular types of information; requirements or desired aspects regarding the security and verification of information communication in the service; information collection, communication between parties, and response times for decisions made by algorithms, machine learning components, or artificial intelligence components in the service; cost considerations for the service (including capital expenditures and operating costs); and how costs will be incurred, including who will bear the costs and the means of cost recovery (e.g., subscriptions, service fees, etc.); the amount of information stored and / or communicated to support the service; and / or the processing or computing power utilized to support the service.

[0210] As used herein, "items" and "services" (and similar terms) should be interpreted broadly. Without being limited to any other aspect or explanation of this disclosure, items and services include any items and services, including, but not limited to, those used as compensation, those used as collateral, those subject to negotiation, and the like. For example, guarantees or applications for guarantees on items subject to loans, collateral for loans, or the like, products, services, offers, solutions, physical products, software, service levels, service qualities, financial instruments, debt, collateral, performance of services, or other goods. Without being limited to any other aspect or description of this disclosure, goods and services may include physical goods (e.g., vehicles, ships, aircraft, buildings, homes, real estate, undeveloped land, farms, crops, local utilities, warehouses, inventory, antiques, fixed equipment, vehicles, ships, aircraft, buildings, homes, real estate, undeveloped land, farms, crops, local utilities, warehouses, inventory, antiques, fixed equipment, vehicles, ships, aircraft, buildings, homes, real estate, undeveloped land, farms, crops, local utilities, warehouses, inventory, antiques, fixed equipment, furniture, equipment, tools, machine parts, personal property), financial instruments (e.g., commodities, securities, currency, tokens of value, tickets, crypto assets), consumable goods (e.g., edible goods, beverages), valuable goods (e.g., precious metals, jewelry, gemstones), intellectual property (e.g., intellectual property, intellectual property rights, contractual rights), and the like. Thus, the benefits of the present disclosure are applicable to a variety of systems, and such systems may be discussed with respect to the goods and services described herein. However, in certain embodiments, a particular system may not be discussed with respect to the goods and services described herein. Given the contents of this disclosure and commonly available knowledge of such systems, one skilled in the art can readily determine which aspects of the present disclosure will benefit a particular system, or how the processes and systems of the present disclosure can be combined to improve the operation of that system.

[0211] As used herein, the terms “agent,” “automated agent,” and similar terms should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, an agent or automated agent may process events related to the value, status, or ownership of collateral or assets. In response to processed events, the agent or automated agent may also perform actions related to loans, debt transactions, bond transactions, subsidized loans, or similar transactions to which the collateral or assets are subject. An agent or automated agent may interact with a marketplace for purposes such as data collection, spot market transaction testing, and transaction execution, where dynamic system behavior involves complex interactions. Such system behavior may be something a user wants to understand, predict, control, or optimize. Some systems may not be considered agents or automated agents. For example, if events are simply collected but not processed, the system may not be considered an agent or automated agent. In some examples, loan-related actions not taken in response to processed events may not have been performed by an agent or automated agent. Those skilled in the art can readily determine, based on the contents of this disclosure and commonly available knowledge of such systems, which portions of this disclosure involve or benefit from agents or automated agents. Considerations for one of ordinary skill in the art, or examples of agents or automated agents of this disclosure, include, but are not limited to, rules for determining changes in the value, condition, or ownership of assets or collateral, and / or rules for determining whether a change requires further action in a loan or other transaction, and other considerations. Specific examples of market value and marketplace information are described herein for illustrative purposes, but any embodiment benefiting from the teachings of this disclosure, and any considerations understood by one of ordinary skill in the art having the benefit of the teachings of this disclosure, are expressly encompassed within the scope of this disclosure.

[0212] As used herein, the terms "marketplace information," "market value," and similar terms should be interpreted broadly. Without being limited to other aspects or explanations of this disclosure, market information and market value describe the condition or value of an asset, collateral, food, or service at a defined point in time or period. Market value may refer to the expected value assigned to an item in a market or auction setting, or the price or financial data of items similar to the item, asset, or collateral in at least one public market. For a company, market value may be the number of shares outstanding multiplied by the current stock price. Valuation services may include market value data collection services that monitor and report market information related to value (e.g., market value) of collateral, issuers, sets of bonds, sets of assets, sets of subsidized loans, parties, etc. Market value may be dynamic in nature, as it depends on a variety of factors, from physical operating conditions to economic conditions and trends in supply and demand. Market value may be affected by the following factors. Market information may also include the following: proximity to other assets, asset inventory or supply, asset demand, origin of the item, history of the item, current value of the item's components, legal entity bankruptcy status, legal entity seizure status, legal entity default status, legal entity regulatory violation status, legal entity criminal status, legal entity export control status, legal entity embargo status, legal entity customs status, legal entity tax status, legal entity credit report, legal entity credit rating, legal entity website rating, a set of customer reviews for the legal entity's products, a legal entity social network rating, a set of legal entity credentials, a set of legal entity referrals, a set of legal entity testimonials, a set of legal entity actions, an entity's location, and an entity's geolocation. In certain embodiments, market value may include information such as value volatility, value sensitivity (e.g., relative sensitivity to other parameters involving uncertainty), and the particular value between the valued object and a particular party (e.g., an object may be worth more when held by a second party than when held by a first party).

[0213] Certain information may not be marketplace information or market value. For example, if value-related variables are not market-derived, they may be use value or investment value. In certain embodiments, investment value may be considered market value (e.g., if the appraiser intends to use the asset as an investment if acquired), while in other embodiments, it is not considered market value (e.g., if the appraiser intends to immediately sell the investment if acquired). One skilled in the art can readily determine which portions of this disclosure would benefit from market information or market value based on the content of this disclosure and commonly available knowledge of the system. Considerations for an artisan to determine whether the term "market value" refers to an asset, item, collateral, product, or service include the existence of similar assets in the market, fluctuations in value by location, whether the bid price for the item exceeds the list price, and other considerations. While specific examples of market value and market information are provided herein for illustrative purposes, all embodiments benefiting from the disclosure herein, and all considerations understood by one skilled in the art with the benefit of the disclosure herein, are expressly encompassed within the scope of this disclosure.

[0214] The terms "allocated value" or "allocated value" and similar terms used herein should be interpreted broadly. Without being limited to other aspects or explanations of this disclosure, allocated value refers to the proportional distribution or allocation of value, or the process of dividing and allocating value according to the rules of pro rata distribution. Value allocation may involve multiple parties (e.g., each party is the beneficiary of a portion of the value), multiple transactions (e.g., each transaction utilizes a portion of the value), and / or many-to-many relationships (e.g., the total value of multiple objects is allocated among multiple parties and / or transactions). In some examples, the value is a net loss, and allocated value represents the allocation of liabilities to each entity. In other examples, allocated value refers to the distribution or allocation of economic profits, real estate, collateral, or the like. In certain embodiments, allocation may include the relative consideration of value between the parties. For example, in a 50 / 50 allocation of $10 million in assets between two parties, one party may account for the different value resulting from the allocation if the parties have different value considerations for the assets. In certain embodiments, the allocation may include consideration of the relative value of the transactions, for example, the same asset may be valued differently in a first transaction type (e.g., a long-term loan) than in a second transaction type (e.g., a short-term line of credit).

[0215] Certain conditions or processes may not be relevant to the allocated value. For example, the total value of an item indicates its intrinsic value, but not the percentage of that value held by each identified entity. Given the contents of this disclosure and knowledge of allocated value, one of ordinary skill in the art can readily determine which portions of this disclosure are useful in a particular application of allocated value. Considerations for those skilled in the art, or examples of allocated value in this disclosure, include, but are not limited to: the currency of the principal amount, the expected type of transaction (loan, bond, debt), the specific type of collateral, the loan-to-value ratio, the collateral-to-loan ratio, the total transaction amount / loan amount, the principal amount, the number of debtors, the value of the collateral, and the like. While specific examples of allocated value are provided herein for illustrative purposes, all embodiments benefiting from the disclosure herein, and all considerations understood by one of ordinary skill in the art with the benefit of the disclosure herein, are expressly encompassed within the scope of this disclosure.

[0216] As used herein, "financial condition" and similar terms should be interpreted broadly. Without being limited to other aspects or explanations of this disclosure, financial condition describes the current state of an entity's assets, liabilities, and capital at a particular point in time or period. Financial condition may be recorded in financial statements. Financial condition may further include an assessment of an entity's ability to weather future risk scenarios or meet future or maturing obligations. Financial status may be calculated based on attributes of the entity selected from the following attributes: the entity's publicly disclosed valuation, the set of assets owned by the entity as shown in public records, the valuation of the set of assets owned by the entity, the entity's bankruptcy status, the entity's foreclosure status, the entity's contract default status, the entity's regulatory violation status, the entity's criminal status, the entity's export control status, the entity's embargo status, the entity's tariff status, the entity's tax status, the entity's credit report, the entity's credit rating, the entity's website rating, the entity's set of customer reviews for the entity's products, the entity's social network rating, the entity's set of credentials, the entity's set of referrals, the entity's set of testimonials, the entity's set of actions, the entity's location, and the entity's geolocation. Financial status may also describe requirements or thresholds for contracts or loans. For example, the conditions for a developer to proceed with work may include various certifications and agreement to financial payments. This means that the developer's ability to continue work depends on financial factors, among other factors. Some conditions may not be applicable to financial status. For example, a credit card balance may provide a hint at financial condition, but does not, in itself, constitute financial condition. In another example, a payment schedule may determine the period for which a debt appears on an entity's balance sheet, but may not, by itself, accurately reflect financial condition. A person skilled in the art can readily determine, based on the contents of this disclosure and commonly available knowledge of such systems, which portions of this disclosure include or benefit from financial condition.Considerations that an engineer may use to determine whether the term "financial condition" refers to the current state of a company's assets, liabilities, and capital at a particular point in time or period, or for a particular purpose, include: reporting multiple financial data points, the ratio of loans to collateral value, the ratio of loans to collateral value, total transaction value / loan amount, borrower and lender credit scores, and other considerations. While specific examples are set forth herein for illustrative purposes, all embodiments benefiting from this disclosure, and all considerations understood by one of ordinary skill in the art having the benefit of this disclosure, are expressly encompassed within the scope of this specification.

[0217] As used herein, "interest rate" and similar terms should be interpreted broadly. Without being limited to any other aspect or explanation of this disclosure, an interest rate refers to the percentage of interest paid per period on a loan, deposit, or borrowing amount. The total interest on a loan or borrowing amount may depend on the principal amount, the interest rate, the frequency of compounding, and the term of the loan, deposit, or borrowing. Interest rates are typically expressed as an annual percentage rate, but may be defined for any period. Interest rates indicate the terms under which a bank or other lending institution lends funds or the interest rate a bank or other institution pays depositors for depositing funds in a deposit account. Interest rates may be either floating or fixed. For example, interest rates may fluctuate depending on the instructions of governments or other interested parties, the currency of the loan or borrowing principal, the maturity of the investment, the borrower's perceived probability of default, market supply and demand, the amount of collateral, economic conditions, or special features such as call provisions. In certain embodiments, the interest rate may be a relative interest rate (e.g., relative to a base rate, an inflation index, etc.). In certain embodiments, the interest rate may take into account costs or fees (e.g., "points") applied to adjust the interest rate. A nominal interest rate may not be inflation-adjusted, while a real interest rate does account for inflation. Certain examples may not qualify as interest rates in certain embodiments. For example, a bank account that increases by a fixed dollar amount each year and / or a fixed fee amount may not be an example of an interest rate in certain embodiments. One of ordinary skill in the art can readily determine the characteristics of an interest rate in certain embodiments based on the disclosure herein and their knowledge of interest rates. Interest rate considerations for those skilled in the art or embodiments herein include, but are not limited to: principal currency, interest rate setting variables, interest rate change criteria, the type of transaction contemplated (loan, bond, debt), the specific type of collateral, loan-to-collateral value ratio, collateral-to-loan ratio, total transaction amount / loan amount, principal amount, the appropriate remaining term of the transaction and / or collateral in a particular industry, the likelihood that the lender will sell and / or consolidate the loan during the term of the loan, and similar matters.The specific examples of interest rates described herein are for illustrative purposes, and all embodiments benefiting from the disclosure herein, and all considerations understood by those skilled in the art having the benefit of the disclosure herein, are expressly encompassed within the scope of this specification.

[0218] As used herein, the term "valuation service" (and similar terms) should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, a valuation service includes a service that sets a value for a product or service. A valuation service may use a valuation model to set a value for collateral based on information obtained from a data collection and monitoring service. A smart contract service may process the output of a valuation service to allocate sufficient collateral as collateral for a loan or allocate the value of collateral among a set of lenders or transactions. A valuation service may include an artificial intelligence service that iteratively improves a valuation model based on resulting data regarding transactions of collateral. A valuation service may include a market value data collection service that monitors and reports market information related to the value of collateral. Some processes may not be considered valuation services. For example, a sales terminal that simply charges a flat fee for a product or service may not be considered a valuation service. As another example, a service that tracks the cost of a product or service and triggers notifications when the value changes may not be considered a valuation service by itself, but may depend on or constitute part of a valuation service. Accordingly, the benefits of this disclosure may be applicable to a variety of process systems, and such processes or systems may be considered evaluation services herein. However, in certain embodiments, certain services may not be considered evaluation services herein. One skilled in the art, based on the contents of this disclosure and commonly available knowledge of such systems, can readily determine which portions of this disclosure will benefit a particular system and how the processes and systems of this disclosure may be combined to improve the operation of or provide evaluation services for the system under consideration.Considerations that one of ordinary skill in the art would consider when determining whether a system under consideration constitutes a rating service, or whether particular aspects of this disclosure would benefit or enhance the functionality of such a system, include, but are not limited to, the following: modifying loans in real time based on the value of collateral; utilizing marketplace data to execute collateral-backed smart contracts; revaluing collateral based on storage condition or geographic location; the volatility of collateral in value, likelihood of use, and / or likelihood of transfer; and similar considerations. While specific examples and considerations of rating services are provided herein for illustrative purposes, any system benefiting from the disclosure herein, and any considerations that would be understood by one of ordinary skill in the art in light of the disclosure herein, are expressly intended to be encompassed within the scope of this specification.

[0219] As used herein, "collateral attributes" (and similar terms) should be interpreted broadly. Without being limited to other aspects or explanations of this disclosure, collateral attributes include, but are not limited to: durability (the ability of the collateral to withstand wear or the useful life of the collateral), value, identifiability (whether the collateral has distinct characteristics and is easy to identify or sell), stability of value (whether the collateral maintains its value over time), standardization, grade, quality, marketability, liquidity, transferability, attractiveness, traceability, deliverability (the ability of the collateral to be delivered or transferred without a decrease in value), market transparency (whether the value of the collateral is easily ascertainable or widely agreed upon), physical or virtual. Collateral attributes may be measured on an absolute or relative basis and may include qualitative (e.g., categorical descriptions) or quantitative descriptions. Collateral attributes may vary by industry, product, factor, application, etc. Collateral attributes may be assigned quantitative or qualitative values. Values ​​associated with collateral attributes may be determined based on a scale (e.g., 1 to 10) or relative designations (high, low, better, etc.). Collateral may contain various components. Each component may have collateral attributes, and therefore, multiple values ​​may exist for the same collateral attribute. In some examples, the values ​​of multiple collateral attributes may be combined to generate a single value for each attribute. Some collateral attributes may only apply to certain areas of the collateral. Some collateral attributes may have different values ​​for specific components of the same collateral depending on the type of stakeholder (e.g., stakeholders who value certain aspects more highly than others) and / or the type of transaction (e.g., when collateral is more valuable or appropriate for a second type of loan than a first type of loan). Certain attributes associated with collateral may not qualify as collateral attributes for purposes of this description. For example, a product may be valued as more durable than similar products.However, if the lifespan of a product is significantly shorter than the term of a particular loan, the durability of the product may be evaluated differently (e.g., not durable) or may not be relevant (e.g., if current inventory of the product is pledged as collateral and is expected to change over the life of the loan). Accordingly, the benefits of this disclosure are applicable to a variety of attributes, and such attributes may be considered collateral attributes herein. Meanwhile, in certain examples, certain attributes may not be considered collateral attributes. One armed with the disclosure herein and knowledge of collateral attributes generally available to those skilled in the art can readily determine which portions of this disclosure benefit particular collateral attributes. Considerations that one of ordinary skill in the art would consider when determining whether a contemplated attribute is an attribute and whether a particular aspect of the present disclosure would benefit or enhance a contemplated system include, but are not limited to, the source of the attribute and the source of the attribute's value (e.g., whether the attribute and attribute value originate from a trusted source), the volatility of the attribute (e.g., whether the collateral's attribute value fluctuates or is a new attribute to the collateral), the relative differences in attribute values ​​among similar collateral, exceptional values ​​for the attribute (e.g., a high value such as the 98th percentile or a very low value such as the 2nd percentile compared to similar collateral classes), the fungibility of the collateral, the type of transaction related to the collateral, and / or the intended use of the collateral with a particular party or transaction. While specific examples of collateral attributes and considerations are described herein for illustrative purposes, any system benefiting from this disclosure, and any considerations understood by one of ordinary skill in the art having the benefit of this disclosure, are expressly encompassed within the scope of this specification.

[0220] As used herein, the term "blockchain service" (and similar terms) should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, blockchain services include services related to processing, recording, and / or updating a blockchain, such as processing blocks, calculating hash values, generating new blocks within a blockchain, adding blocks to a blockchain, generating forks within a blockchain, merging forks within a blockchain, verifying past calculations, updating a shared ledger, updating a distributed ledger, generating cryptographic keys, validating transactions, maintaining the blockchain, updating the blockchain, validating the blockchain, and generating random numbers. These services may be performed by executing computer-readable instructions running on a local computer or by remote servers and computers. While certain services may not be considered blockchain services individually, they may be considered blockchain services depending on the end use and specific implementation of the service. For example, hash value calculations may be performed in a context other than a blockchain (e.g., in the context of secure communications). Some initial services may be performed without first being applied to a blockchain, but additional actions or services performed in conjunction with the initial services may associate the initial services with elements of a blockchain. For example, random numbers may be periodically generated and stored in memory. These random numbers may be used in a blockchain even if they were not originally generated for that purpose. Accordingly, the benefits of this disclosure are applicable to a variety of services, and such services may be considered blockchain services herein. However, in certain embodiments, a particular service may not be considered a blockchain service herein. Given the disclosure herein and knowledge of blockchain services typically available for such services, one skilled in the art can readily determine which aspects of this disclosure are configurable to implement or benefit a particular blockchain service.Considerations that a person skilled in the art might consider when determining whether a service under consideration is a blockchain service and / or whether elements of this disclosure would benefit or enhance the system under consideration include, but are not limited to, the scope of the service, the source of the service (e.g., if the service is associated with a known or verifiable blockchain service provider), the responsiveness of the service (e.g., if some blockchain services have an expected completion time or may be determined through usage), the cost of the service (e.g., if the service is associated with a known or verifiable blockchain service provider), the responsiveness of the service (e.g., some blockchain services may have an expected completion time or may be determined through usage), the cost of the service, the amount of data required by the service, and / or the amount of data generated by the service (blocks on a blockchain or keys associated with a blockchain may be of a particular size or range of sizes). While specific examples and considerations of blockchain services are described herein for illustrative purposes, any system that would benefit from the disclosure herein and any considerations that would be understood by a person skilled in the art in light of the disclosure herein are expressly intended to be encompassed within the scope of this specification.

[0221] As used herein, "blockchain" (including cryptocurrency ledger and other similar terms) is understood to broadly refer to a cryptocurrency ledger that records, manages, or processes online transactions. Blockchains may be public, private, or a combination thereof. Blockchains may also be used to represent digital transactions, agreements, terms, or other sets of digital value. Without being limited to other aspects or descriptions of this disclosure, in the former case, blockchains may also be used in conjunction with investment applications, token trading applications, or digital / cryptocurrency-based marketplaces. Blockchains may also be used to pay for goods, services, items, fees, access to restricted areas or events, data, or other valuable benefits. Blockchains may be included in various forms when discussing units of consideration, collateral, currency, cryptocurrency, or other forms of value. Those skilled in the art, armed with the contents of this disclosure and commonly available knowledge of the system under consideration, can readily determine the value a blockchain symbolizes or represents. While specific examples of blockchains are described herein for illustrative purposes, all embodiments benefiting from the disclosure herein, and all considerations understood by those skilled in the art having the benefit of the disclosure herein, are expressly encompassed within the scope of this specification.

[0222] As used herein, the terms "ledger" and "distributed ledger" (and similar terms) should be interpreted broadly. Without being limited to other aspects or explanations of this disclosure, a ledger may be a document, file, computer file, database, book, etc. that maintains a record of transactions. A ledger may be physical or digital. A ledger may include records related to sales, accounts, purchases, transactions, assets, liabilities, income, expenses, capital, etc. A ledger may provide a history of transactions associated with time. A ledger may be centralized or decentralized / distributed. A centralized ledger is a document that is managed, updated, or viewable by one or more selected entities or clearing houses, and changes or updates to the ledger are managed or controlled by those entities or clearing houses. A distributed ledger is a ledger that is distributed across multiple entities, participants, or geographies, all of which can independently, simultaneously, or by consensus, update or modify their own copies of the ledger. Ledgers and distributed ledgers may incorporate security measures and cryptographic features to sign, conceal, or verify content. In the case of distributed ledgers, blockchain technology may be used. In a distributed ledger implemented using blockchain, the ledger may be a Merkle tree, consisting of a linked list of nodes, where each node stores the hashed or encrypted transaction data of the previous node. Some transaction records may not be considered ledgers. A file, computer file, database, or book may or may not be a ledger depending on the data it stores and how the data is organized, maintained, or protected. For example, a list of transactions may not be considered a ledger if it is unreliable or unverifiable, or if it is based on inconsistent, fraudulent, or incomplete data. Data in a ledger may be organized in any format, such as a table, list, or binary data stream, depending on convenience, data source, data type, environment, application, etc.While a ledger shared among multiple entities is not necessarily a distributed ledger, the distinction of being distributed is determined based on which entities are allowed to modify the ledger and how those modifications are shared and processed among the different entities. Accordingly, the benefits of this disclosure are applicable to a variety of data, and such data may be considered a ledger herein. However, in certain embodiments, certain data may not be considered a ledger herein. Given this disclosure and commonly available knowledge of ledgers and distributed ledgers, those skilled in the art can readily determine which aspects of this disclosure are applicable to or benefit a particular ledger implementation. Considerations that one of ordinary skill in the art might consider when determining whether a contemplated data is a ledger and / or whether aspects of the present disclosure would benefit or improve a contemplated ledger include, but are not limited to, the security of the data in the ledger (whether the data can be tampered with or changed), the time required to make a change to the data in the ledger, the cost of the change (computational and monetary), the granularity of the data, the organization of the data (whether the data needs to be processed for use by an application), the entity that controls the ledger (whether that entity can be trusted or relied upon to control the ledger), the confidentiality of the data (who can view or track the data in the ledger), the size of the infrastructure, communication requirements (distributed ledgers may require communication interfaces or specific infrastructure), and fault tolerance. While specific examples of blockchain services and considerations are provided herein for illustrative purposes, any system that would benefit from the disclosure herein, and any considerations that would be understood by one of ordinary skill in the art in light of the disclosure herein, are expressly encompassed within the scope of this specification.

[0223] As used herein, the term "loan" (and similar terms) should be interpreted broadly. Without being limited to any other aspect or explanation of this disclosure, a loan is an agreement for an asset to be borrowed and returned in kind (e.g., borrowed money is returned) or as an agreed-upon transaction (e.g., an initial good or service is borrowed and money, another good or service, or a combination thereof is returned). Assets include money, property, time, physical objects, virtual objects, services, rights (e.g., tickets, licenses, or other rights), depreciation, credits (e.g., tax credits, emissions credits, etc.), agreed-upon risk or liability assumptions, and / or combinations thereof. A loan is a formal or informal agreement between the lender and borrower in which the lender provides an asset to the borrower for a fixed, variable, or indefinite period. The lender and borrower may be individuals, corporations, businesses, governments, groups, organizations, etc. Types of loans include mortgages, personal loans, secured loans, unsecured loans, preferential loans, commercial loans, and microloans. A contract between a lender and a borrower sets out the terms of the loan. The borrower may be obligated to return the borrowed asset or repay with a different asset. In some cases, interest may be repaid on the borrowed asset. The lender and borrower may act as intermediaries between other entities and may not own or use the asset. In some embodiments, a loan may not be associated with a direct transfer of goods but may be associated with a right of use or a shared right of use. In certain embodiments, the contract between a borrower and a lender may be concluded between the borrower and the lender or through an intermediary (e.g., sale of the loan rights through the beneficiary of the loan rights). In certain embodiments, the contract between a borrower and a lender may be concluded through the Services. For example, a loan may be entered into through a smart contract service that determines some of the terms of the loan and, in certain embodiments, may bind the borrower and / or lender to the terms of the agreement. This agreement may be a smart contract.In certain embodiments, the smart contract service may automatically enter the terms of the contract and present them to the borrower and / or lender for execution. In certain embodiments, the smart contract service may automatically bind either the borrower or the lender to the terms of the contract (at least as a proposal) and present that proposal to the other borrower or lender for execution. In certain embodiments, a loan agreement may include multiple borrowers and / or multiple lenders. For example, a set of loans may have multiple beneficiaries of payments for that set of loans or multiple borrowers for that set of loans. In certain embodiments, the risks and / or obligations of a set of loans may be individualized (e.g., each borrower and / or lender is associated with a specific loan within the set of loans), allocated (e.g., losses associated with the default of a specific loan are allocated among the lenders), or a combination thereof (e.g., one or more subsets of the set of loans are treated separately and / or allocated).

[0224] Some Agreements May Not Be Considered Loans. Agreements involving the transfer or borrowing of assets may not be considered loans depending on the assets being transferred, the method of asset transfer, or the relationship between the parties. For example, if the transfer of assets occurs for an indefinite period, the transfer may be considered a sale or permanent transfer of the assets. Similarly, if assets are borrowed or transferred without clear terms or agreements, or if there is a lack of agreement between the lender and borrower, some cases may not be considered loans. Even if a written agreement does not expressly state a formal provision, an agreement may be considered a loan if the parties voluntarily and knowingly agree to it, or if ordinary practice (e.g., practice in a particular industry) treats the transaction as a loan. Therefore, the benefits of this disclosure are applicable to a variety of agreements, and such agreements may be considered loans herein. However, in certain embodiments, certain agreements may not be considered loans herein. Those equipped with the disclosures herein and knowledge of lending generally available to those skilled in the art can readily determine which portions of this disclosure implement, utilize, or benefit a particular lending transaction. Considerations that one of ordinary skill in the art would consider in determining whether the data under consideration applies to a loan or whether particular aspects of this disclosure would benefit or enhance the loan under consideration include, but are not limited to, the value of the assets involved, the borrower's ability to repay or repay the loan, the type of asset involved (e.g., whether the asset is consumed through use), the repayment period associated with the loan, the interest rate on the loan, the method of entering into the loan agreement, the form of the agreement, the details of the agreement, the details of the loan agreement, the attributes of the collateral associated with the loan, and / or the business expectations under which any of the above elements would normally be expected in the particular context. While particular loan examples and considerations are set forth herein for illustrative purposes, any system benefiting from the disclosure herein, and any considerations understood by one of ordinary skill in the art having the benefit of the disclosure herein, are expressly encompassed within the scope of this specification.

[0225] As used herein, the term "loan-related event" (and similar terms, e.g., loan-related event) should be interpreted broadly. Without being limited to other aspects or explanations of this disclosure, a loan-related event includes an event related to the terms of a loan or an event triggered by a contract related to a loan. A loan-related event includes a loan default, breach of contract, performance, repayment, payment, interest rate change, late fee imposition, refund imposition, distribution, and similar events. A loan-related event may be triggered by an explicit contractual provision. For example, if a contract provides that an interest rate will increase after a certain period of time has passed since the inception of the loan, an increase in interest rate triggered by such contract may be a loan-related event. A loan-related event may also be implicitly triggered by the terms of the relevant loan agreement. In certain embodiments, the occurrence of an event related to the assumptions of the loan agreement or the expectations of the parties to the loan agreement may be considered the occurrence of an event. For example, if the collateral for the loan is assumed to be exchangeable (e.g., inventory), a change in inventory levels may be considered the occurrence of a loan-related event. As another example, if collateral is subject to screening or verification, a problem with the collateral, such as inaccessibility of the collateral or failure or malfunction of a monitoring sensor, may also be considered a loan-related event. In certain embodiments, a circuit, controller, or other device described herein may automatically trigger a loan-related event determination. In some embodiments, a loan-related event may be triggered by an entity managing the loan or loan-related agreement. A loan-related event may be conditionally triggered based on one or more terms in the loan agreement. A loan-related event may be related to a task or requirement that the lender, borrower, or a third party must complete. A particular event may be considered a loan-related event in certain embodiments and / or in certain contexts, but may not be considered a loan-related event in other embodiments or contexts. While many events are related to loans, they may be caused by external triggers unrelated to loans.However, in certain embodiments, an event caused by an external trigger (e.g., a change in the price of a commodity related to the collateral property) may be considered a lending-related event. For example, a renegotiation of loan terms initiated by a lender may not be considered a lending-related event if the terms and / or performance of the existing loan agreement did not cause the renegotiation. Accordingly, the benefits of this disclosure are applicable to a variety of events, and such events may be considered lending-related events herein. However, in certain embodiments, certain events may not be considered lending-related events herein. A person skilled in the art can readily determine, based on the contents of this disclosure and commonly available knowledge of the system, which portions of this disclosure are considered lending-related events in the context of the system and / or the particular transaction the system facilitates.Considerations for engineers in determining whether contemplated data constitutes a loan-related event or whether particular aspects of this disclosure would benefit or enhance a contemplated trading system include, but are not limited to: the impact of the relevant event on the loan (events that cause loan defaults or terminations may have a greater impact), the costs (capital and / or operational costs) associated with the event, the costs (capital and / or operational costs) of monitoring for the occurrence of the event, the entity responsible for responding to the event, the duration and / or response time associated with the event (e.g., the time required to complete the event and the time allocated from the time the event is triggered to the time the event is processed or detected), and the responsibility for the event. The information may include, but is not limited to, the entity responsible for the event, the data required to process the event (including the time allotted to complete processing or detection of the event), the entity responsible for the event, the data required to process the event (including the time allotted to complete processing or detection of the event), the entity responsible for the event, the data required to process the event (e.g., the time required to complete the event, the period from when the event is triggered until the event is desired to be processed or detected), the entity responsible for responding to the event, the data required to process the event (e.g., sensitive information may be subject to different security measures or restrictions), the availability of mitigation measures in the event of an undetected event, and / or remedies available to the party at risk if an event occurs undetected. While specific examples of events and considerations related to lending are described herein for illustrative purposes, any system benefiting from the disclosures herein, and any considerations understood by one of ordinary skill in the art with the benefit of the disclosures herein, are expressly encompassed within the scope of this specification.

[0226] As used herein, "lending-related activities" (and similar terms) should be interpreted broadly. Without being limited to other aspects or explanations of this disclosure, lending-related activities include activities related to the origination, maintenance, termination, collection, enforcement, servicing, billing, marketing, performance, or negotiation of loans. Lending-related activities include executing a loan agreement or promissory note, reviewing loan documents, processing payments, valuing collateral, assessing a borrower's or lender's compliance with loan terms, renegotiating terms, perfecting a loan's collateral or security interest, and / or negotiating terms. Lending-related activities include activities prior to the formal agreement on the terms of a loan (e.g., activities related to initial negotiations). Lending-related operations may relate to events occurring during the life of a loan and after the loan's termination. Lending-related operations may be performed by the lender, the borrower, or a third party. While certain activities may not individually be considered lending-related activities, they may be considered lending-related activities due to the activity's unique nature in the loan's life cycle. For example, invoicing and billing related to an outstanding loan may be considered loan-related activity, but if the invoicing and billing for the loan is combined with invoicing and billing for elements unrelated to the loan, the invoicing may not be considered loan-related activity. Some activities may occur in connection with an asset regardless of whether the asset is related to a loan. In such cases, the activity may not be considered loan-related activity. For example, periodic audits related to an asset may occur regardless of whether the asset is related to a loan and may not be considered loan-related activity. As another example, if a loan agreement requires periodic audits related to an asset and would not normally occur without the loan, the activity may be considered loan-related activity. In some embodiments, an activity may be considered loan-related activity even if it would not normally occur if the loan were in effect or does not exist (e.g., even if audits are normally performed, an audit may be considered loan-related activity if the lender does not have the authority to conduct or review the audit).Accordingly, the benefits of this disclosure are applicable to a variety of events, and such events may be considered loan-related events herein. However, in certain embodiments, certain events may not be considered loan-related events. One skilled in the art can readily determine loan-related activity in a given system based on the disclosure herein and commonly available knowledge of the system. Considerations for a person skilled in the art in determining whether the data under consideration constitutes loan-related activity or whether elements of this disclosure would benefit or enhance the loan under consideration include, but are not limited to, the necessity of the activity for the loan (whether the loan agreement or terms can be met without the activity), the cost of the activity, the specificity of the activity to the loan (whether the activity is similar or identical to that in other industries), the time required for the activity, the impact of the activity on the loan lifecycle, the entity performing the activity, the amount of data required for the activity (whether the activity requires confidential information about the loan or personal information about the entity), and the ability of the parties to perform or review the activity. Specific examples of lending-related events and considerations are set forth herein for illustrative purposes, but all systems benefiting from the disclosure herein and considerations that would be understood by a person skilled in the art in light of the disclosure herein are intended to be within the scope of this disclosure.

[0227] As used herein, terms such as "loan terms," ​​"loan agreement terms," ​​"loan terms," ​​"terms and conditions," and "terms and conditions" should be interpreted broadly ("loan terms"). Without limiting any other aspect or description of this disclosure, loan terms include the terms, rules, restrictions, contractual obligations, and similar matters relating to the timing, repayment, origination, and other enforceable terms agreed upon by the borrower and lender of the loan. Loan terms may be set forth in a formal agreement executed between the borrower and lender. Loan terms may include interest rate elements, collateral, foreclosure conditions, debt attribution, payment options, payment schedules, covenants, and similar matters. Loan terms may be negotiable or may change during the term of the loan. Loan terms may change or be affected by market prices, bond prices, lender or borrower-related conditions, and similar external factors. Certain aspects of a loan may not be considered loan terms. In certain instances, aspects of a loan that are not formally agreed upon between the lender and borrower and / or that are not commonly understood in business operations (and / or a particular industry) may not be considered loan terms. Certain aspects of a loan may be considered provisional or informal until formally agreed upon or confirmed in a contract or formal agreement. Certain aspects of a loan may not be considered loan terms individually, but may be considered loan terms because they are unique to a particular loan. Certain aspects of a loan may not be considered loan terms at a particular point in the loan, but may be considered loan terms at another point in the loan (e.g., obligations and / or waivers arising through the parties' performance or the expiration of the loan term). For example, an interest rate is typically not considered a loan term unless it is defined in the context of the loan and the method of compounding the interest rate (e.g., annually, monthly, etc.), the calculation method, etc. are clearly specified. Certain aspects of a loan are not considered loan terms if they are uncertain or unenforceable. Some aspects may not in themselves be considered loan terms, even if they express or relate to the terms of the loan. For example, the term of a loan agreement may refer to the repayment period of the loan (e.g., one year).The term may not specify the repayment method over the year (e.g., 12 monthly payments or one annual payment). In this case, the monthly payment plan may not be considered a provision of the loan agreement because it is merely one of several repayment options not directly specified in the loan agreement. Accordingly, the benefits of this disclosure may be applicable to various aspects of the loan agreement, and such aspects may be considered provisions of the loan agreement under this disclosure. However, in certain embodiments, certain aspects may not be considered provisions of the loan agreement. A person skilled in the art, with knowledge of the contents of this disclosure and the contemplated system, and given the information typically available to such person, can readily determine which aspects of this disclosure constitute loan terms in the contemplated system.

[0228] Factors a professional in the field may consider in determining whether the contemplated data constitutes a loan term or whether aspects of this disclosure benefit or enhance the contemplated loan include, but are not limited to, the following: the enforceability of the clause (whether the lender or borrower can enforce the clause), the cost of enforcing the clause (the time or effort required to ensure the clause is complied with), the complexity of the clause (how easily the parties can comply with or understand the clause, whether the clause is prone to error or misinterpretation), who is responsible for the clause, the fairness of the clause, the stability of the clause (how often does it change), the verifiability of the clause (can other parties verify the clause), the party-friendliness of the clause (whether the clause favors the borrower or lender), the risks associated with the loan (whether the clause depends on the possibility that the loan will not be repaid), the characteristics of the borrower or lender (their ability to meet the clause), and / or normal expectations regarding lending and / or the related industry.

[0229] While specific examples of loan terms are described herein for illustrative purposes, any system benefiting from the disclosure herein and any considerations that would be understood by a person skilled in the art in light of the disclosure herein are expressly encompassed within the scope of the present specification.

[0230] As used herein, terms such as "loan terms," ​​"loan conditions," "loan terms," ​​"terms and conditions," and the like, should be interpreted broadly ("loan terms"). Without being limited to other aspects or explanations herein, loan terms include those regarding rules, restrictions, and / or obligations related to the loan. Loan terms include rules or required obligations regarding obtaining, maintaining, applying for, transferring, etc. the loan. Loan terms include the principal amount of the debt, the remaining balance of the debt, fixed interest rate, variable interest rate, payment amount, payment schedule, lump-sum repayment schedule, collateral designation, collateral fungibility designation, treatment of the collateral, access to the collateral, parties, guarantees, guarantors, collateral, personal guarantees, liens, term, contract terms, foreclosure conditions, default conditions, conditions regarding the borrower's other obligations, and consequences of default.

[0231] Certain aspects of a loan may not be considered loan conditions. Elements of a loan that are not formally agreed upon between the lender and borrower and / or that are not commonly understood in the normal course of business (and / or a particular industry) may not be considered loan conditions. Certain elements of a loan may be considered preliminary or informal until formally agreed upon or confirmed in a contract or formal agreement. Certain aspects of a loan may not be considered loan conditions individually, but may be considered loan conditions if the aspect is unique to a particular loan. Certain aspects of a loan may not be considered loan conditions at a particular point in the loan, but may be considered loan conditions at another point in the loan (e.g., obligations and / or waivers arising through the parties' performance and / or expiration of loan conditions). Accordingly, the benefits of this disclosure are applicable to various aspects of a loan, and such aspects may be considered loan conditions for purposes of this disclosure. Conversely, in certain embodiments, certain aspects may not be considered loan conditions for purposes of this disclosure. A person skilled in the art, with the contents of this disclosure and commonly available knowledge of the system, can readily determine which aspects of this disclosure constitute loan terms under the system. Considerations for a person skilled in the art in determining whether the data under consideration constitutes a loan term or whether aspects of this disclosure would benefit or enhance the loan under consideration include, but are not limited to, the following: the enforceability of the term (whether the lender or borrower can enforce the term), the cost of enforcing the term (the time and effort required to ensure the term is complied with), the complexity of the term (how easy it is for the parties to comply with or understand the term, whether the term is prone to error or misinterpretation), who is responsible for the term, the fairness of the term, the verifiability of the term (whether the term can be verified by a third party), whether the term is favorable or unfavorable to one party (whether the term is favorable to the borrower or the lender), the risks associated with the loan (the term may depend on the possibility that the loan will not be repaid), and / or normal expectations in the lending and / or related industry.

[0232] While specific examples of loan terms are set forth herein for illustrative purposes, any system benefiting from the disclosure herein and any considerations understood by one of ordinary skill in the art having the benefit of the disclosure herein are expressly encompassed within the scope of the present disclosure.

[0233] As used herein, terms such as "loan collateral," "collateral," "pledged property," and "collateralized items" should be interpreted broadly. Without being limited to other aspects or explanations of this disclosure, loan collateral refers to assets or property pledged by a borrower to a lender as security for a loan and / or assets or property pledged as collateral for a loan. Collateral refers to items of value that are accepted as an alternative means of repayment in the event of a loan default. Examples of collateral include vehicles, vessels, aircraft, buildings, homes, real estate, undeveloped land, farms, crops, utilities, warehouses, inventory, merchandise, securities, currency, value tokens, tickets, cryptocurrencies, consumables, edible goods, beverages, precious metals, jewelry, gemstones, intellectual property rights, contractual rights, antiques, fixtures, furniture, equipment, tools, machinery, and personal property. Collateral may include one or more items or types of items.

[0234] Collateral describes assets, property, value, or other items defined as collateral for a loan or transaction. A set of collateral may be defined, and collateral may be swapped, removed, or added within that set. For example, collateral may include, but is not limited to, vehicles, vessels, aircraft, buildings, homes, real estate, undeveloped land, farms, crops, utilities, warehouses, sets of inventory, commodities, securities, currency, tokens of value, tickets, cryptocurrencies, consumables, edibles, beverages, precious metals, jewelry, gemstones, intellectual property rights, intellectual property rights, contractual rights, antiques, fixtures, furniture, equipment, tools, machinery, or personal property, or similar. When a set or plurality of collateral is defined, swapping, removing, or adding collateral may apply. For example, swapping, removing, or adding collateral from a set of collateral. Without limiting any other aspect or description of this disclosure, collateral or set of collateral may be used in combination with other terms related to contracts or loans. For example, representations, warranties, indemnities, covenants, outstanding debt, fixed interest rate, variable interest rate, payment amount, payment schedule, lump sum payment schedule, identification of collateral, identification of collateral substitutability, security interests, personal guarantees, liens, term, foreclosure conditions, default conditions, and consequences of default. In certain embodiments, the smart contract may calculate whether the borrower has met the terms or covenants, and if the borrower has not met these terms or covenants, may take automated action or trigger other conditions or covenants that affect the status, ownership, or transfer of the collateral, or may initiate the substitution, removal, or addition of collateral from the set of collateral for the loan. Given this disclosure and knowledge of collateral, one skilled in the art can readily determine the purpose and use of collateral (including its substitution, removal, or addition) in various embodiments and contexts disclosed herein.

[0235] While specific examples of loan collateral are described herein for illustrative purposes, any system benefiting from the disclosure herein and any considerations understood by one of ordinary skill in the art having the benefit of the disclosure herein are expressly encompassed within the scope of the present disclosure.

[0236] As used herein, the term "smart contract service" (and similar terms) should be interpreted broadly. Without being limited to other aspects or descriptions herein, a smart contract service includes a service or application that manages a smart contract or a smart loan contract. For example, a smart contract service may define the terms and conditions of a smart contract, such as in a rules database, or process the output of an evaluation service to allocate sufficient collateral as collateral for a loan. A smart contract service may automatically execute a set of rules and conditions embodying a smart contract, the execution of which is based on or utilizes collected data. A smart contract service may automatically initiate a loan payment request, automatically initiate foreclosure proceedings, automatically initiate a claim on substitute or backup collateral or a transfer of ownership of collateral, automatically initiate inspection proceedings, automatically modify payment or interest terms based on collateral, or configure a smart contract to automatically perform a loan-related action. A smart contract may govern at least one of loan terms, loan-related events, or loan-related activities. A smart contract is an agreement encoded as a computer protocol that may facilitate, verify, or enforce the negotiation or performance of the smart contract. A smart contract may be partially or fully self-executable or self-enforceable, or neither.

[0237] Certain processes may not be considered smart contract-related individually, but may be considered smart contract-related in the aggregate. For example, a process that automatically performs actions related to lending may not be smart contract-related in one case, but may be governed by the terms of a smart contract in another. Accordingly, the benefits of this disclosure are applicable to a variety of process systems, and such processes or systems may be considered smart contracts or smart contract services herein. However, in certain embodiments, a particular service may not be considered a smart contract service herein.

[0238] Based on the contents of this disclosure and generally available knowledge of the system in question, a person skilled in the art can readily determine which aspects of this disclosure will benefit a particular system and how the processes and systems of this disclosure can be combined to implement smart contract services or improve the operation of the system under consideration. Considerations for a person skilled in the art when determining whether a contemplated system includes smart contract services or smart contracts, or whether particular aspects of this disclosure would benefit or enhance the functionality of a contemplated system, include, but are not limited to, the following: the ability to automatically transfer ownership of collateral in response to an event; automated actions available when compliance (or non-compliance) with contractual terms is determined; collateral clustering, rebalancing, allocation, addition, replacement, and removal of items from collateral; the ability to modify parameters of aspects of a loan in response to an event (e.g., timing, complexity, applicability to loan type, etc.); the benefit of quickly determining or predicting changes in the complexity of the terms and conditions of loans in the system, particularly in the entities (e.g., collateral, financial condition of the parties, offsetting collateral, or the industry associated with the parties); matters related to lending; the eligibility for automatic generation of contract terms and / or enforcement of contract terms appropriate for the type of loan, parties, and / or industry contemplated by the system; and similar matters. Specific examples of smart contract services and considerations are described herein for illustrative purposes, but any system benefiting from the disclosure herein and any considerations that would be understood by a person skilled in the art having the benefit of the disclosure herein are expressly encompassed within the scope of this specification.

[0239] As used herein, "IoT system" (and similar terms) should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, an IoT system includes a system consisting of uniquely identified and interconnected computing devices, mechanical and digital machines, sensors, and objects that can transfer data over a network without human intervention. Even if a particular component is not considered an IoT system on its own, it may be considered an IoT system as part of an aggregated system, such as a single networked system.

[0240] Even if a sensor, smart speaker, and / or medical device alone is not considered an IoT system, it may be considered an IoT system or part of an IoT system when combined with other similar components as part of a larger system. In certain embodiments, a system may be considered an IoT system for some purposes but not for others. For example, a smart speaker may be considered part of an IoT system for certain operations, such as providing surround sound, but not for other operations, such as streaming content directly from a source connected to a single local network. Furthermore, in certain embodiments, systems that appear similar may be distinguished when determining whether or what type of IoT system they are. For example, if one group of medical devices does not share data with an aggregated HER database at a particular time, while another group of medical devices shares data with an aggregated HER for clinical research purposes, one group may be considered an IoT system and the other may not be considered an IoT system. Thus, the benefits of the present disclosure are applicable to a variety of systems, and such systems may be considered IoT systems herein. However, in certain embodiments, a particular system may not be considered an IoT system herein. Based on the contents of this disclosure and commonly available knowledge of such systems, one of ordinary skill in the art will readily be able to identify which aspects of this disclosure will benefit a particular system, how the processes and systems of this disclosure can be combined to improve the operation of such a system, and the circuits, controllers, or devices that comprise an IoT system in such a system.Considerations that one of ordinary skill in the art might consider when determining whether a system under consideration is an IoT system or whether elements of the present disclosure would benefit or enhance the system under consideration include, but are not limited to, the system's transmission environment (e.g., availability of low power, presence or absence of networking between devices); shared data storage by a group of devices; establishment of geofences by a group of devices; functioning as a blockchain node; asset, collateral, or entity monitoring capabilities; data relay between devices; ability to aggregate data from multiple sensors or monitoring devices, etc. While specific examples and considerations of IoT systems are described herein for illustrative purposes, any system that would benefit from the disclosure herein and any considerations that would be understood by one of ordinary skill in the art having the benefit of the disclosure herein are expressly encompassed within the scope of this specification.

[0241] As used herein, the term "data collection service" (and similar terms) should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, a data collection service includes any service that collects data or information. This includes circuits, controllers, devices, or applications that store, transmit, transfer, share, process, organize, compare, report, or aggregate data or information. A data collection service may include or communicate with a data collection device (e.g., a sensor). A data collection service may monitor an entity to identify the data or information to be collected. A data collection service may retrieve data from an application in an event-driven, periodic, or specific point during the application's execution. A particular process may not be considered a data collection service in isolation, but may be considered a data collection service as part of an aggregated system. For example, a network-attached storage device may function as a component of a data collection service in some cases and have independent functionality in other cases. Thus, the benefits of the present disclosure are applicable to a variety of process systems, and such processes or systems may be considered data collection services herein. However, in certain embodiments, a particular service may not be considered a data collection service herein. Those skilled in the art will be able to readily determine, based on the disclosure herein and commonly available knowledge of such systems, which aspects of the present specification would benefit a particular system and how the processes and systems herein may be combined to perform data collection services or otherwise improve the operation of the system under consideration.Considerations that may help one of ordinary skill in the art determine whether a system under consideration qualifies as a data collection service, or whether particular aspects of the present disclosure would benefit or enhance the functionality of the system under consideration, include, but are not limited to, the ability to change business rules in real time and adjust data collection protocols; real-time monitoring of events; connecting data collection devices to a monitoring infrastructure and executing computer-readable instructions that cause a processor to log or track events; utilizing automated inspection systems; sales occurring at networked points of sale; the need for data from one or more distributed sensors or cameras; and the like. While specific examples and considerations for data collection services are described herein for illustrative purposes, any system that would benefit from the disclosure herein, and any considerations that would be understood by one of ordinary skill in the art having the benefit of the disclosure herein, are expressly encompassed within the scope of this specification.

[0242] As used herein, the term "data integration service" (and similar terms) should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, a data integration service includes any service that integrates data or information. This includes any device or application that extracts, transforms, loads, normalizes, compresses, decompresses, encodes, decodes, or otherwise processes data packets, signals, or other information. A data integration service may include the ability to monitor entities to identify data or information to be integrated. A data integration service can integrate data regardless of the required frequency, communication protocol, or business rules required for complex integration patterns. Therefore, the benefits of this disclosure are applicable to a variety of process systems, and such processes or systems may be considered data integration services herein. However, in certain embodiments, a particular service may not be considered a data integration service herein. Given the disclosure herein and commonly available knowledge of such systems, one skilled in the art can readily determine which aspects of this disclosure benefit a particular system and how the processes and systems herein may be combined to implement a data integration service or improve the operation of the system under consideration. Considerations that one of ordinary skill in the art might consider when determining whether a contemplated system is a data integration service or whether particular aspects of the present disclosure would benefit or enhance the functionality of a contemplated system include, but are not limited to, the following: the ability to change business rules in real time and adjust data integration protocols; the ability to acquire and integrate data by communicating with third-party databases; synchronization of data across different platforms; connectivity to a central data warehouse; data storage, processing, and / or communication capacity distributed across the system; connectivity of decoupled automated workflows; and similar considerations.Specific examples of data integration services and considerations are described herein for illustrative purposes, but all systems that benefit from the disclosure herein and considerations that would be understood by a person skilled in the art in light of the disclosure herein are intended to be within the scope of this specification.

[0243] As used herein, the term "computational service" (and similar terms) is intended to be broadly construed. Without being limited to other aspects or descriptions of this disclosure, a computational service may be included as part of one or more services, platforms, or microservices, such as blockchain services, data collection services, data integration services, evaluation services, smart contract services, data monitoring services, data mining, or services that facilitate the collection, access, processing, transformation, analysis, storage, visualization, and sharing of data. A particular process may not be considered a computational service. For example, a process may not be considered a computational service depending on the type of rules for the service, the end product of the service, or the purpose of the service. Accordingly, the benefits of this disclosure are applicable to a variety of process systems, and such processes or systems may be considered computational services herein. Conversely, in certain embodiments, a particular service may not be considered a computational service herein. Given the disclosure herein and commonly available knowledge of such systems, those skilled in the art can readily determine which aspects of this disclosure benefit a particular system and how the processes and systems herein may be combined to implement one or more computational services or improve the operation of the system under consideration. Considerations that would help one of ordinary skill in the art determine whether a contemplated system is a computational service and / or whether particular aspects of the present disclosure would benefit or enhance the functionality of such a system include, but are not limited to, the following: agreement-based access to services; brokering exchanges between different services; providing on-demand computational resources for web services; and enabling one or more of monitoring, collecting, accessing, processing, transforming, analyzing, storing, integrating, visualizing, mining, or sharing data. While specific examples of computational services and considerations are provided herein for illustrative purposes, any system that would benefit from the disclosure herein and any considerations that would be understood by one of ordinary skill in the art having the benefit of the disclosure herein are expressly encompassed within the scope of this specification.

[0244] The term "sensor" as used herein should be interpreted broadly. Without being limited to other aspects or descriptions of the present disclosure, a sensor is a device, module, machine, or subsystem that detects or measures a physical property, event, or change. In embodiments, the sensor records, displays, transmits, or otherwise responds to the results of the detection or measurement. Examples of sensors include sensors that detect the motion of an object, sensors that detect the temperature, pressure, or other attributes of an object or its environment, cameras that take still or video images of an object, and sensors that collect data about collateral or assets (e.g., location, condition (health, physical, or other condition), quality, security, ownership, etc.). In embodiments, a sensor is sensitive to the property being measured but does not affect other properties. Sensors can be analog or digital. Sensors include a processor, transmitter, transceiver, memory, power source, sensor circuitry, electrochemical liquid reservoir, light source, etc. Further examples of sensors that may be used in the system include biosensors, chemical sensors, black silicon sensors, infrared sensors, acoustic sensors, inductive sensors, motion sensors, optical sensors, opacity sensors, proximity sensors, inductive sensors, eddy current sensors, passive infrared proximity sensors, radar, capacitive sensors, capacitive displacement sensors, Hall effect sensors, magnetic sensors, GPS sensors, thermal imaging sensors, thermocouples, thermistors, photoelectric sensors, ultrasonic sensors, infrared laser sensors, inertial motion sensors, MEMS internal motion sensors, ultrasonic 3D motion sensors, accelerometers, inclinometers, force sensors, piezoelectric sensors, rotary encoders, linear encoders, ozone sensors, smoke sensors, heat sensors, magnetometers, carbon dioxide detectors, carbon monoxide detectors, oxygen sensors, glucose sensors, smoke detectors, metal detectors, rain sensors, altimeters, GPS, exterior detection, context detection, activity detection, object detectors (e.g., collateral), marker detectors (e.g., geolocation markers), laser range finders, sonar, capacitance, optical response, heart rate sensors, or RF / micropower pulsed radio (MIR) sensors.In certain embodiments, a sensor may be a virtual sensor. For example, the sensor may determine a parameter of interest as a calculated value based on parameters detected by other sensors in the system. In certain embodiments, the sensor may be a smart sensor. For example, the sensor may report the detected value as an abstracted communication (e.g., a network communication). In certain embodiments, the sensor may provide the detected value directly (e.g., a voltage level, a frequency parameter, etc.) to a circuit, controller, or other device in the system. One skilled in the art can readily determine which aspects of the present disclosure would benefit from a sensor based on the contents of this disclosure and commonly available knowledge of the system. Considerations for a person skilled in the art when determining whether a device under consideration is a sensor or whether an aspect of the present disclosure would benefit or be enhanced by a sensor under consideration include, but are not limited to, the following: making system activation / deactivation dependent on environmental quality; converting electrical output to a measurement; the ability to enforce geofencing; automatic loan modifications based on collateral changes; and the like. While specific examples of sensors and considerations are provided herein for illustrative purposes, any system benefiting from the disclosure herein, and any considerations as understood by a person skilled in the art having the benefit of the disclosure herein, are expressly intended to be encompassed within the scope of this specification.

[0245] As used herein, "storage conditions" and similar terms should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, storage conditions include the environment, physical location, environmental quality, exposure levels, security measures, maintenance instructions, accessibility instructions, etc., associated with the storage of a contract, loan, or asset, collateral, or entity supporting a contract, loan, or other agreement. Based on the storage conditions of collateral, assets, or entities, measures may be taken to maintain, improve, or verify the condition of the asset. Based on the storage conditions, measures may be taken to modify the terms or conditions of a loan or bond. Storage conditions may be classified based on various rules, thresholds, conditional procedures, workflows, model parameters, etc., and may be determined based on self-reported or data from IoT devices, data from a set of environmental condition sensors, data from a set of social network analysis services, a set of algorithms querying network domains, social media data, crowdsourced data, etc. Storage conditions may be tied to geographic locations associated with collateral, issuers, borrowers, allocations of funds, or other geographic locations. Examples of IoT data include images, sensor data, location data, etc. Examples of social media or crowdsourced data include the actions of parties to a loan agreement, their financial condition, and compliance with the terms or conditions of a loan agreement or bond. Parties to a loan include the bond issuer, affiliates, lenders, borrowers, and third parties with an interest in the debt. Storage conditions may include asset or collateral type (e.g., municipal property, vehicles, vessels, aircraft, buildings, homes, real estate, undeveloped land, farms, crops, municipal facilities, warehouses, inventory, commodities, securities, currency, value tokens, tickets, cryptocurrencies, consumables, edibles, beverages, precious metals, jewelry, gemstones, intellectual property rights, contractual rights, antiques, fixtures, furniture, equipment, tools, machinery, personal possessions, etc.). Storage conditions may include environment, which may include an environment selected from municipal environment, corporate environment, securities trading environment, real estate environment, commercial facility, warehouse facility, transportation environment, manufacturing environment, storage environment, residential, and vehicle.Actions based on the custody status of collateral, assets, or entities may include administering, reporting, modifying, pooling, consolidating, terminating, maintaining, modifying terms, seizing assets, or disposing of loans, contracts, or agreements. A person skilled in the art can readily determine which portions of this disclosure are useful for applying specific custody conditions, based on the contents of this disclosure and knowledge of the custody conditions under consideration. Considerations for a person skilled in the art in selecting appropriate custody conditions, or examples of this disclosure, include, but are not limited to: the legality of the terms in the jurisdiction of the transaction, available data regarding the collateral, the type of transaction contemplated (loan, bond, debt), the specific type of collateral, the loan-to-collateral value ratio, the collateral-to-loan ratio, the total transaction amount / loan amount, the borrower's and lender's credit scores, general industry practices, and other considerations. The specific examples of custody conditions described herein are for illustrative purposes only, and all embodiments benefiting from the disclosure herein, and all considerations understood by those skilled in the art in light of the disclosure herein, are expressly encompassed within the scope of this disclosure.

[0246] As used herein, "geolocation" and similar terms should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, geolocation includes determining or estimating the real-world geographic location of an object. This includes generating a set of geographic coordinates (e.g., latitude and longitude) and / or generating a street address. Based on the geolocation of collateral, assets, or entities, actions may be taken to maintain or improve the condition of the asset or for the purpose of using the asset as collateral. Based on geolocation, actions may be taken to modify the terms of a loan or bond. Based on geolocation, decisions or predictions regarding transactions may be made. For example, decisions or predictions may be made based on weather in a particular area, civil unrest, or local disasters (e.g., earthquakes, floods, tornadoes, hurricanes, industrial accidents, etc.). Geolocation information may be determined based on various rules, thresholds, conditional procedures, workflows, model parameters, etc., and may be based on self-reported or data from IoT devices, data from environmental condition sensors, data from social network analysis services, sets of algorithms querying network domains, social media data, crowdsourced data, etc. Examples of geolocation information include GPS coordinates, images, sensor data, addresses, etc. Geolocation information may be quantitative (e.g., longitude / latitude, location on a map, etc.) and / or qualitative (e.g., categorical, such as "coastal" or "rural"; "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 or crowdsourced data include behavior of a lending party inferred from its geolocation, a party's financial condition inferred from its geolocation, and compliance with the terms of a loan agreement or bond.Geolocation information may identify the geographic location of assets such as identifying types of assets or collateral (e.g., municipal property, vehicles, vessels, aircraft, buildings, homes, real estate, undeveloped land, farms, crops, municipal facilities, warehouses, inventory, merchandise, securities, currency, tokens of value, tickets, consumables, edibles, beverages, precious metals, jewelry, gemstones, antiques, fixtures, furniture, equipment, tools, machinery, personal property, etc.). Geographic location may be identified for one of the parties, a third party (e.g., inspection services, maintenance services, cleaning services related to the transaction), or any other entity related to the transaction. Geographic location information may include environments selected from municipal environments, corporate environments, securities trading environments, real estate environments, commercial facilities, warehouse facilities, transportation environments, manufacturing environments, storage environments, residential environments, vehicles, etc. Actions based on the geolocation information of collateral, assets, or entities may include managing, reporting, modifying, sharing, consolidating, terminating, maintaining, modifying the terms of, seizing assets, or processing loans, contracts, or agreements. Experts in the field should be aware of the content of this disclosure and the nature of the information under consideration. Knowledge of the system will readily enable one to determine which portions of this disclosure are beneficial for a particular geolocation application and which location information of items constitutes geolocation in the system under consideration. Considerations for a technician or an embodiment of this disclosure to select an appropriate geolocation include, but are not limited to: the legality of geolocation in the jurisdiction of the transaction, available data regarding the collateral, the type of transaction contemplated (loan, bond, debt), the specific type of collateral, the loan-to-collateral value ratio, the collateral-to-loan ratio, the total amount of the transaction / loan, the frequency of travel of the borrower to a particular jurisdiction or other considerations, the mobility of the collateral, and / or the likelihood of location-specific events related to the transaction (e.g., weather, location of relevant industrial facilities, availability of relevant services, etc.). While specific examples of geolocations are provided herein for illustrative purposes, all embodiments benefiting from the disclosure herein and all considerations understood by one of ordinary skill in the art in light of the disclosure herein are expressly encompassed within the scope of this disclosure.

[0247] The terms "location of jurisdiction" and similar terms are intended to be broadly interpreted herein. Without being limited to other aspects or explanations of this disclosure, location of jurisdiction refers to the laws and legal authorities governing a lending entity. Location of jurisdiction may be determined based on the entity's geolocation, the entity's place of registration (e.g., the flag state of a vessel, the state of incorporation of a company, etc.), the state of grant of certain rights such as intellectual property rights, and the like. In certain embodiments, jurisdiction is one or more of the entity's geographic locations within the system. In certain embodiments, jurisdiction may not be the same as the geographic location of any entity within the system (e.g., if a contract specifies another jurisdiction). In certain embodiments, jurisdiction may vary for different entities within the system (e.g., borrower A, lender B, collateral placed in C, contract executed in D, etc.). In certain embodiments, the jurisdiction of a particular entity may change during the operation of the system (e.g., due to collateral movement, changes in related data, changes in contract terms, etc.). In certain embodiments, a particular entity in the system may have locations in multiple jurisdictions, or may have locations in different jurisdictions for different purposes, depending on the operation of relevant law and the options available to one or more parties. The jurisdiction of a collateral, asset, or entity may dictate certain terms or conditions of a loan or bond and / or may indicate different obligations regarding notice to the parties, enforcement of liens and / or defaults, handling of collateral and / or debt securities, and / or handling of various data within the system. While example jurisdictions are specifically set forth herein for illustrative purposes, all embodiments benefiting from the disclosure herein and all considerations understood by those skilled in the art in light of the disclosure herein are expressly encompassed within the scope of this specification.

[0248] As used herein, "value token," "token," and variants thereof (e.g., cryptocurrency tokens, etc.) as units of value are understood to broadly refer to either: (a) units of currency or cryptocurrency (e.g., cryptocurrency tokens), and (b) credentials exchangeable for goods, services, data, or other valuable consideration (e.g., value tokens). Without being limited to other aspects or explanations of this disclosure, in the former case, tokens may be used in conjunction with investment applications, token trading applications, token-based marketplaces, etc. In the latter case, tokens may be associated with the fulfillment of consideration, such as the provision of goods, services, fees, access to restricted areas or events, data, or other valuable benefits. Tokens may or may not be conditional (e.g., conditional access tokens). For example, tokens of value may be exchanged for accommodations (e.g., hotel rooms), food and beverage products and services, spaces (e.g., shared spaces, workspaces, convention spaces, etc.), fitness and wellness products and services, event tickets or admission tickets, travel, airline tickets or other transportation, digital content, virtual goods, license keys, or other valuable goods, services, data, or consideration. Tokens may be included in various forms when discussing consideration, collateral, or units of value, including currency, crypto assets, or forms of value, including goods, services, data, or other benefits. Those skilled in the art can readily determine whether a token represents currency, crypto assets, goods, services, data, or other value, based on the disclosures herein and their knowledge of tokens. While specific examples of tokens are described herein for illustrative purposes, all embodiments benefiting from the disclosures herein and all considerations understood by those skilled in the art with the benefit of the disclosures herein are expressly encompassed within the scope of this specification.

[0249] As used herein, the term "price data" is understood to broadly refer to a quantity of information, such as the price or cost of one or more items in a market. Without being limited to other aspects or descriptions of this disclosure, price data may be used in combination with spot market prices, futures market prices, price discount information, promotional prices, and other information regarding the cost or price of an item. Price data may satisfy one or more conditions or trigger the application of one or more rules in a smart contract. Price data may be used in combination with market value data, accounting data, access data, asset and facility data, employee data, event data, underwriting data, claims data, or other forms of data. Price data may be tailored to the context of the item being valued (e.g., condition, liquidity, location, etc.) and / or the context of a particular party. Given the content of this disclosure and knowledge of the price data, a person skilled in the art can readily determine the purpose and use of price data in the various embodiments and contexts set forth herein.

[0250] Without being limited to other aspects or descriptions of this disclosure, tokens include tokens that function as a representation of value, including, but not limited to, value tokens (e.g., collateral, assets, rewards, etc.). For example, value-holding vouchers exchangeable for goods or services are examples of such tokens. Certain components may not be considered tokens in isolation, but may be considered tokens in an aggregated system. For example, value assigned to an asset may not be a token in itself, but the asset's value may be stored, exchanged, traded, etc. in a value token. For example, as a non-limiting example, a blockchain circuit may be structured to provide a mechanism for lenders to store the value of an asset. In this case, the value assigned to the token is stored in the blockchain circuit's distributed ledger, but the value-assigned token itself may be exchanged or traded, for example, 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 to represent ownership of an asset, but the use of this token is not traded as value, unlike when a token containing the asset's value is traded as value. Accordingly, the benefits of this disclosure are applicable to a variety of systems, and such systems may be considered tokens herein. However, in certain embodiments, a particular system may not be considered a token herein. One of ordinary skill in the art, given the disclosure herein and commonly available knowledge of such systems, can readily determine which aspects of this specification would be beneficial to a particular system or how the processes or systems herein may be combined to improve the operation of that system.Considerations for a person skilled in the art to consider when determining whether a contemplated system is a token or whether aspects of the present disclosure would benefit or improve the functionality of a contemplated system include, but are not limited to, the following: access data (related to access privileges, tickets, tokens, etc.); use in investment applications (e.g., investing in stocks, profits, tokens, etc.); token trading applications; token-based marketplaces; forms of consideration such as monetary compensation or tokens; converting the value of resources into tokens; cryptocurrency tokens; information indicating ownership rights (e.g., identity information, event information, token information); blockchain-based access tokens traded in marketplace applications; pricing applications for conditional access rights, underlying access rights, tokens, and fees; trading applications for trading or exchanging conditional access rights, underlying access rights, or tokens; tokens created on the blockchain that result in ownership rights as a result of conditional access rights (e.g., tickets); and the like.

[0251] As used herein, the term "financial data" is understood to broadly refer to a collection of financial information regarding assets, collateral, or other items. Financial data may include revenues, expenses, assets, liabilities, capital, bond ratings, defaults, return on assets (ROA), return on investment (ROI), past performance, future performance projections, earnings per share (EPS), internal rate of return (IRR), earnings announcements, ratios, statistical analyses of any of the above (e.g., moving averages), and the like. Without being limited to other aspects or descriptions of this disclosure, financial data may be used in combination with pricing data and market value data. Financial data may satisfy one or more conditions of a smart contract or trigger the application of one or more rules of a smart contract. Financial data may be used in combination with market value data, pricing data, accounting data, access data, asset and facility data, employee data, event data, underwriting data, claims data, or other forms of data. Those skilled in the art, with knowledge of the contents of this disclosure and financial data, can readily determine the purpose and application of pricing data in the various embodiments and contexts set forth herein.

[0252] As used in this disclosure, the term "contract clause" is broadly interpreted to describe any provision, agreement, or promise that implies the performance of an act or omission. For example, a contract clause may refer to the conduct or legal status of a party. Without being limited to other aspects or explanations of this disclosure, a contract clause may also be used in conjunction with other related terms related to contracts and loans. For example, the terms include representation, warranty, indemnity, outstanding debt, fixed interest rate, variable interest rate, payment amount, payment schedule, lump sum payment schedule, collateral designation, collateral fungibility designation, parties, guarantee, guarantor, collateral, personal guarantee, lien, term, foreclosure condition, default condition, and consequences of default. A contract clause, or the lack of performance thereof, may satisfy one or more conditions or trigger recovery, default, or other terms or conditions. In certain embodiments, a smart contract calculates whether a contract clause has been satisfied and, if a contract clause has not been satisfied, may enable automated action or trigger other conditions or provisions. Those skilled in the art, armed with the disclosure herein and knowledge of contract clauses, can readily determine the purpose and use of contract clauses in the various embodiments and contexts disclosed herein.

[0253] As used herein, the term "entity" is understood to broadly refer to an identifiable, related object, such as a party, a third party (e.g., an auditor, regulator, service provider, etc.), or a collateral related to a transaction. Exemplary entities include individuals, partnerships, corporations, limited liability companies, or other legal organizations. Other examples of entities include identifiable collateral, offsetting collateral, and potential collateral. For example, an entity may be an individual who is a party to a contract or loan. Data and other terms herein may be characterized as having an entity-related context, such as entity-oriented data. An entity may be characterized in a particular context or use, such as a human entity, a physical entity, a transaction entity, or a financial entity. An entity may have a representative acting on its behalf. Without limiting other aspects or descriptions of this disclosure, entity may be used in conjunction with other related entities or terms related to a contract or loan. For example, representations, warranties, indemnities, contractual provisions, outstanding debt, fixed interest rate, variable interest rate, payment amount, payment schedule, lump sum payment schedule, collateral designation, collateral fungibility designation, parties, guarantees, guarantors, collateral, personal guarantees, liens, term, foreclosure conditions, default conditions, and consequences of default. An entity may have a set of attributes, including, but not limited to, published valuation, a set of properties owned by the entity as shown in public records, a valuation of a set of properties owned by the entity, bankruptcy conditions, foreclosure status, contractual default status, regulatory violation status, criminal status, export control status, embargo status, tariff status, tax status, credit report, credit rating, website rating, a set of customer reviews for the entity's products, social network ratings, a set of credentials, a set of referrals, a set of testimonials, a set of behaviors, location information, and geolocation.In certain embodiments, the smart contract may calculate whether the entity meets the terms or contractual provisions and may take automated actions or trigger other terms or provisions if the entity does not meet those terms or contractual provisions. One skilled in the art, given the disclosure herein and knowledge of the entities, can readily determine the purpose and use of the entities in various embodiments and contexts disclosed herein.

[0254] As used herein, the term "party" is understood to broadly refer to any party to an agreement, including an individual, a partnership, a corporation, a limited liability company, or any other legal entity. For example, a party may include a primary lender, a secondary lender, a loan 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 secured lender, a borrower, a debtor, an underwriter, an inspector, an appraiser, an auditor, a valuation expert, a government official, an accountant, or any other entity with rights or obligations related to a contract, transaction, or loan. The term "party" may be defined differently, such as when multiple parties are involved in a transaction, such as the term "transaction" in the term "multi-party transaction." A party may have a representative acting on its behalf. In certain embodiments, the term "party" may refer to a potential or prospective party, such as a lender or borrower who intends to interact with the system but is not bound by an actual contract during their interaction with the system. Without being limited to other aspects or descriptions of this disclosure, party may be used in combination with other related parties or terms related to an agreement or loan, such as representations, warranties, indemnifications, contractual provisions, outstanding debt, fixed interest rate, variable interest rate, payment amount, payment schedule, lump sum payment schedule, collateral designation, collateral fungibility designation, entity, guarantee, guarantor, collateral, personal guarantee, lien, term, foreclosure conditions, default conditions, and consequences of default. A party may have a set of attributes, including, but not limited to, identity, creditworthiness, activity, behavior, contract performance status, information regarding accounts receivable, information regarding accounts payable, information regarding the value of collateral, and other types of information. In certain embodiments, a smart contract may calculate whether a party has met a condition or contractual provision and, if a party has not met such condition or contractual provision, perform automated actions or trigger other conditions or provisions. Those skilled in the art, given the disclosure herein and their knowledge of parties, can readily determine the purpose and use of party in various embodiments and contexts disclosed herein.

[0255] As used herein, the terms “party attribute,” “entity attribute,” or “party / entity attribute” are understood to broadly describe the value, characteristics, or state of a party or entity. For example, party or entity attributes include, but are not limited to, value, quality, location, net worth, price, physical condition, health, security, safety, ownership, identity, creditworthiness, activities, behavior, business practices, contract performance, information about accounts receivable, information about accounts payable, information about the value of collateral, other types of information, and the like. In certain embodiments, a smart contract may calculate values, states, or conditions associated with a party or entity attribute and perform automated actions or trigger other conditions or provisions if the party or entity does not meet such conditions or contractual provisions. Given the content of this disclosure and knowledge of party or entity attributes, one skilled in the art can readily determine the purpose and use of these attributes in the various embodiments and contexts set forth herein.

[0256] As used herein, the term "lender" broadly refers to a party to an agreement that provides assets for a loan and provides the proceeds of the loan, and includes an individual, partnership, corporation, limited liability company, or other legal entity. For example, a lender may include, but is not limited to, a primary lender, secondary lender, loan syndicate, corporate lender, government lender, bank lender, secured lender, unsecured lender, or any other party with rights or obligations related to the agreement, transaction, or loan that provides the loan to the borrower. A lender may have an agent acting on its behalf. Without being limited to other aspects or descriptions of this disclosure, party may be used in combination with other related parties or terms related to an agreement or loan, such as borrower, guarantor, representation, warranty, indemnity, covenant, outstanding debt, fixed interest rate, variable interest rate, payment amount, payment schedule, lump sum payment schedule, collateral designation, collateral fungibility designation, collateral, personal guarantee, lien, term, foreclosure conditions, default conditions, and consequences of default. In certain embodiments, the smart contract may calculate whether the lender has met the terms or conditions of the contract and may execute automated actions, notifications, or alerts, or trigger other terms or conditions, if the lender has not met those terms or conditions. One skilled in the art, given the disclosure herein and knowledge of lenders, can readily determine the purpose and use of lenders in the various embodiments and contexts disclosed herein.

[0257] As used herein, the term "crowdsourcing service" is understood to broadly refer to services offered or implemented in conjunction with a crowdsourcing model or transaction. In this service, a large number of individuals or entities provide contributions to fulfill a need in a transaction, such as a loan, and receive rewards in return. Crowdsourcing services may be provided by a platform or system. Crowdsourcing requests are sent to a group of information providers, responses to the requests are collected and processed, and rewards are provided to at least one successful information provider. The request and parameters may be configured to obtain information regarding the terms of the loan collateral. Crowdsourcing requests may be publicly available. In certain embodiments, crowdsourcing services may be implemented by a smart contract. In this case, rewards are managed by a smart contract that processes responses to the crowdsourcing request and automatically distributes rewards to information that meets the parameters set for the crowdsourcing request. Based on the content of this disclosure and knowledge of crowdsourcing services, those skilled in the art can readily determine the purpose and use of crowdsourcing services in the various embodiments and contexts set forth in this disclosure.

[0258] As used herein, the term "publishing service" is understood to refer to a set of services that publish crowdsourcing requests. Publishing services may be provided by a platform or a system. In certain embodiments, publishing services may be performed by a smart contract, where crowdsourcing requests are published or publishing is initiated by the smart contract. Those skilled in the art, based on the disclosure herein and knowledge of publishing services, can readily determine the purpose and use of publishing services in various embodiments and contexts disclosed herein.

[0259] As used herein, the term "interface" is understood to broadly refer to components that enable interaction or communication, such as computer components. Such components may be implemented as software, hardware, or a combination thereof. For example, an interface may be deployed for a variety of purposes, applications, and contexts, such as an application programming interface, a graphic user interface, a user interface, a software interface, a marketplace interface, a demand aggregation interface, a crowdsourcing interface, a secure access control interface, a network interface, a data integration interface, a cloud computing interface, or a combination thereof. An interface may function as a means for inputting, receiving, or displaying data in the fields of lending, refinancing, collections, consolidation, factoring, brokerage, or foreclosure. An interface may function as an interface for other interfaces. Without being limited to other aspects or descriptions of this disclosure, an interface may be used as an application, process, module, service, layer, device, component, machine, product, subsystem, interface, connection, or system component. In certain embodiments, an interface may be implemented as software, hardware, or a combination thereof and stored on a medium or memory. Those skilled in the art, when equipped with knowledge of the contents and interfaces herein, can readily determine the purpose and use of the interfaces in the various embodiments and contexts disclosed herein.

[0260] As used herein, the term "graphical user interface" refers to a type of interface through which a user interacts with a system, computer, or other interface. This interaction or communication is achieved through a graphical device or representation. A graphical user interface is a component of a computer and may be implemented as computer-readable instructions, hardware, or a combination thereof. A graphical user interface may serve multiple different purposes or be configured for different applications or contexts. Such an interface may function as a means for receiving or displaying data using visual representations, stimuli, or interactive data. A graphical user interface may interface with other graphical user interfaces or other interfaces. Without being limited to other aspects or descriptions of this disclosure, a graphical user interface may be used as an application, process, module, service, layer, device, component, machine, product, subsystem, interface, connection, or system component. In certain embodiments, a graphical user interface may be embodied as computer-readable instructions, hardware, or a combination thereof and stored on a medium or memory. A graphical user interface may be configured to accommodate any input type, such as a keyboard, mouse, or touchscreen. The graphical user interface can be configured to accommodate any user interaction environment, such as a dedicated application, a web page interface, or a combination thereof. One skilled in the art, based on the contents of this specification and knowledge of graphical user interfaces, can readily determine the purpose and use of the graphical user interface in the various embodiments and contexts disclosed herein.

[0261] As used herein, the term "user interface" refers to a type of interface through which a user interacts with a system, computer, or other device, where the interaction or communication is achieved through a graphical device or representation. A user interface may be a computer component implemented as software, hardware, or a combination thereof. A user interface may be stored on a medium or memory. A user interface may include drop-down menus, tables, forms, and the like with defaults, templates, recommendations, or pre-set conditions. In certain embodiments, a user interface may include voice interaction. Without being limited to other aspects or descriptions of this disclosure, a user interface may be used as an application, circuit, controller, process, module, service, layer, device, component, machine, product, subsystem, interface, connection, or system component. A user interface may serve multiple different purposes or be configured for different applications or contexts. For example, a lender's user interface may include the ability to display multiple customer profiles but may be limited in its ability to make certain changes. A borrower's user interface may include the ability to view and modify user account details. Third-party neutral interfaces (e.g., third parties not involved in the Underlying Transaction, regulators, auditors, etc.) include the ability to view corporate surveillance information and anonymized user data without the ability to manipulate the data, and access permissions may be scheduled depending on the third party and the purpose of the access. Interested third-party interfaces (e.g., interested third parties involved in the Underlying Transaction, such as debt collectors, debtor representatives, investigators, partial owners, etc.) include the ability to view certain user data and may have restrictions on their ability to make changes.Many additional features of these user interfaces are available that are applicable to implementations of the systems and / or procedures described in this disclosure. Accordingly, the benefits of this disclosure are applicable to a variety of processes and systems, and such processes and systems may be considered services herein. One of ordinary skill in the art, armed with knowledge of the disclosures herein and user interfaces, can readily determine the purpose and use of user interfaces in the various embodiments and contexts disclosed herein. Considerations for one of ordinary skill in determining whether a contemplated interface is a user interface or whether elements of this disclosure would benefit or enhance a contemplated system include, but are not limited to, the following: configurable views, the ability to limit operations or views, reporting capabilities, the ability to manipulate user profiles and data, fulfilling regulatory requirements, providing desired user functionality for borrowers, lenders, and third parties, etc.

[0262] As used herein, the terms "interface" and "dashboard" are understood more broadly to describe components that facilitate interaction or communication. For example, they may refer to computer components implemented as software, hardware, or a combination thereof. The interfaces and dashboards acquire, receive, display, or manage items, services, offers, or other aspects of trading or lending. For example, interfaces and dashboards may be configured for a variety of purposes, applications, and contexts, such as application programming interfaces, graphic user interfaces, user interfaces, software interfaces, marketplace interfaces, demand aggregation interfaces, crowdsourcing interfaces, secure access control interfaces, network interfaces, data integration interfaces, cloud computing interfaces, or combinations thereof. An interface or dashboard may serve as a means for receiving or displaying data in the context of lending, refinancing, collections, consolidation, factoring, brokerage, or foreclosure. An interface or dashboard may serve as an interface or dashboard for other interfaces or dashboards. Without being limited to other aspects or descriptions of this disclosure, an interface may be used as a component of an application, circuit, controller, process, module, service, layer, device, component, machine, product, subsystem, interface, connection, or system. In particular embodiments, the interface or dashboard may be embodied as computer-readable instructions, hardware, or a combination thereof, and may be stored on a medium or memory. One skilled in the art can readily determine the purpose and use of the interface and / or dashboard in the various embodiments and contexts set forth in this disclosure based on the content of this disclosure and commonly available knowledge of the contemplated systems.

[0263] As used herein, the term "domain" is understood to broadly describe the scope or context of a transaction and / or communication related to the transaction. For example, domains may be configured for multiple different purposes, applications, and contexts, such as a domain for execution, a domain for digital assets, a domain where requests are issued, a domain where social network data collection and monitoring services are applied, a domain where IoT data collection and monitoring services are applied, a network domain, a geolocation domain, a jurisdictional location domain, and a time domain. Without being limited to other aspects or descriptions of this disclosure, one or more domains may be utilized as an application, circuit, controller, process, module, service, layer, device, component, machine, product, subsystem, interface, connection, or system component. In certain embodiments, a domain may be embodied as computer-readable instructions, hardware, or a combination thereof, and stored on a medium or memory. Given the content of this disclosure and knowledge of the domains, one skilled in the art can readily determine the purpose and use of domains in the various embodiments and contexts set forth herein.

[0264] As used herein, the term "request" (and variations thereof) is intended to be broadly interpreted to describe an act or instance of requesting or initiating the provision of something (e.g., information, a response, an object, etc.). A particular type of request may serve multiple different purposes or be configured for different applications or contexts. For example, but not limited to, a formal legal request (e.g., a subpoena), a refinancing request (e.g., a loan), or a crowdsourcing request. A system may be utilized not only to execute requests but also to fulfill requests. When discussing legal actions, loan refinancing, or crowdsourcing services, requests may be included in various forms. Those skilled in the art can readily determine the value of requests implemented in the examples based on the content of this disclosure and knowledge of the system under consideration. While specific examples are described herein for illustrative purposes, all embodiments benefiting from the disclosure herein and all considerations understood by those skilled in the art in light of the disclosure herein are expressly intended to be within the scope of this disclosure.

[0265] As used herein, the term "reward" (and variations thereof) is understood to broadly refer to any item or consideration received or provided in response to an action or stimulus. Rewards include, but are not limited to, monetary or non-monetary types. Specific types of rewards may serve multiple different purposes or be configured for different applications or contexts, including, but not limited to, reward events, reward claims, monetary rewards, rewards captured as datasets, reward points, and other forms of rewards. Rewards may be triggered, assigned, generated for innovation, provided for evidence submission, requested, offered, selected, managed, configured, assigned, communicated, identified, and other actions, without limitation. Systems may be utilized to perform the above actions. Rewards may be included in various forms in discussions of or promotions of specific actions. In one embodiment of the present specification, rewards may be used as specific incentives (e.g., rewarding specific individuals who respond to a crowdsourcing request) or as general incentives (e.g., providing a reward in addition to or instead of a reward to specific individuals if a crowdsourcing request is successful). Those skilled in the art can easily determine the value of the rewards implemented in the examples based on the disclosure herein and knowledge of the rewards. The specific examples of rewards described herein are provided for illustrative purposes, and all embodiments benefiting from the disclosure herein, and all considerations understood by those skilled in the art having the benefit of the disclosure herein, are expressly encompassed within the scope of this specification.

[0266] As used herein, the term "robotic process automation system" is understood to broadly include systems capable of performing the tasks performed by or meeting the needs provided by the systems herein. For example, a robotic process automation system may be configured, without limitation, to: negotiate a set of loan terms, negotiate loan refinancing, collect on loans, consolidate a set of loans, manage factored loans, broker mortgage loans, train foreclosure negotiations, configure crowdsourcing requests based on a set of loan attributes, set rewards, determine a set of domains to which requests will be posted, configure the content of the request, configure data collection and monitoring actions based on a set of loan attributes, determine a set of domains to which IoT data collection and monitoring services will apply, and iteratively train and improve based on a set of results. 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 that is a component of a higher-level robotic process automation system. The robotic process automation system may include at least one of the following: mortgage activity set or mortgage interaction set, marketing activities, identifying a potential borrower set, identifying properties, identifying collateral, qualifying borrowers, title search, title verification, property valuation, property inspection, property appraisal, income verification, borrower demographic analysis, identifying capital providers, determining available interest rates, determining available payment terms, analyzing existing mortgages, analyzing existing mortgage terms versus new mortgage terms, completing application workflow, populating application fields, creating mortgage agreements, completing mortgage agreement schedules, negotiating mortgage terms with funders, negotiating mortgage terms with borrowers, transferring ownership, establishing mortgages, and closing mortgage agreements.An exemplary and non-limiting robotic process automation system may include a user interface for providing, requesting, or sharing data throughout the system, interfaces with circuits and / or controllers, and / or one or more artificial intelligence circuits configured to iteratively improve one or more operations of the robotic process automation system. Given the contents of this disclosure and generally available knowledge of the contemplated robotic process automation system, one skilled in the art can readily identify circuits, controllers, and / or devices that may be included to implement the robotic process automation system to perform selected functions in the contemplated system. While specific examples of robotic process automation systems are described herein for illustrative purposes, any embodiment benefiting from the disclosure herein and all considerations to be understood will be readily apparent to those skilled in the art.

[0267] "Loan-related action" (and the related terms "loan-related event" and "loan-related activity") is used herein to broadly describe one or more actions, events, or activities related to a transaction that includes a loan. Such actions, events, or activities may occur in a variety of lending contexts, including, but not limited to, lending, refinancing, consolidation, factoring, brokerage, foreclosure, administration, negotiation, collection, procurement, enforcement, and data processing (e.g., data collection). Lending-related action may be used as a noun (e.g., sending a formal notice of default to a borrower may be considered a lending-related action). Lending-related actions, events, or activities may refer to a single instance or may characterize a series of actions, events, or activities. For example, the single act of providing a borrower with a specific notice of late payment may be considered a lending-related action. Similarly, a chain of actions from start to finish related to a default may also be considered a single loan-related action. Activities such as, but not limited to, appraisals, inspections, financing, and recording may all be deemed to have occurred as loan-related actions and may also be deemed loan-related events. Similarly, activities to complete these actions (e.g., appraisals, inspections, financing, recording, etc.) may also be deemed loan-related activities (e.g., but not limited to, appraisals, inspections, financing, recording, etc.). In certain embodiments, a smart contract or robotic process automation system may execute a loan-related action, loan-related event, or loan-related activity behalf of one or more parties and process the appropriate tasks for its completion. In some cases, a smart contract or robotic process automation system may not complete a loan-related action, and such outcome may result in automated actions being taken or other conditions or clauses being triggered.Those skilled in the art, with knowledge of the contents of the disclosure herein and the actions, events, and activities related to lending, can readily determine the purpose and use of this term in the various forms and embodiments described herein.

[0268] The term "loan-related actions, events, and activities" is also used herein to specifically describe the context of a loan invocation. Loan collection is the act of a lender demanding repayment of a loan, typically triggered by other conditions or clauses, such as late payments. For example, if a borrower misses three consecutive payments, causing a material delay in the loan payment schedule and putting the loan into default, loan-related actions aimed at loan collection may be triggered. In such circumstances, the lender may take loan-related actions aimed at loan collection to protect its rights. In such circumstances, if the borrower makes a payment to remedy the delay, that payment may also be considered a loan-related action aimed at loan collection. In some circumstances, smart contracts or robotic process automation systems may initiate, manage, or process loan-related actions aimed at loan collection. This may include providing notices, investigations, collecting payment history, or other tasks performed as part of the loan collection process. A person skilled in the art, having knowledge of the contents of this disclosure and the actions related to the recovery of loans, or having knowledge of other forms of the term and its various forms, can readily determine the purpose and use of the term in the events disclosed in this disclosure and in various other embodiments and contexts.

[0269] The term "loan-related actions, events, and activities" may also be used herein to more specifically describe the context of loan disbursements. In a loan transaction, a loan is typically repaid according to a payment schedule. Various actions may be taken, including actions to provide the borrower with information about the loan repayment and actions by the lender to receive the loan payment. For example, when a borrower makes a payment on a loan, a loan-related action related to the loan disbursement may occur. Without limitation, such a payment may include multiple actions related to the loan disbursement, such as: the payment being presented to the lender, the payment being reflected in the loan ledger or accounting records, a payment receipt being provided to the borrower, and the next payment being billed to the borrower. In some circumstances, a smart contract or robotic process automation system may initiate, manage, or process loan-related actions related to the loan disbursement. This may include providing notices to the lender, researching and collecting payment history, providing receipts to the borrower, notifying the borrower of the next payment due, or other actions related to the loan disbursement. Those skilled in the art, with knowledge of the disclosures herein and the actions involved in disbursing loans, or with knowledge of other forms of the term and its various forms, can readily determine the purpose and use of the term in the events disclosed herein or in various other embodiments and contexts.

[0270] The term "loan-related acts, events, and activities" as used herein may be used more specifically to describe a payment schedule or alternative payment schedule. In a loan transaction, a loan is typically repaid according to a payment schedule. This schedule may change over time. Alternatively, an alternative payment schedule may be established. A payment schedule or alternative payment schedule allows the lender or borrower to take various actions, including the amount of the payment, the payment due date, penalties or fees associated with late payments, and other terms. For example, if the borrower repays the loan early, a loan-related action may be triggered with respect to the loan payment schedule and alternative payment schedule. In that case, the payment may be applied to principal, and regular payments may still be due. Without limitation, a loan-related action with respect to a payment schedule or alternative payment schedule may include multiple actions that occur with respect to the payment of the loan. For example, submitting a payment to the lender, recording the payment in the loan ledger or accounting records, providing the borrower with a receipt indicating the payment was made, calculating whether a fee is charged or a payment is due, and billing the borrower for the next payment. In certain embodiments, an activity that determines a payment schedule or an alternative payment schedule may be a loan-related action, event, or activity. In certain embodiments, an activity that communicates a payment schedule or an alternative payment schedule (e.g., notifying the borrower, lender, or third party) may be a loan-related action, event, or activity.In some circumstances, the smart contract circuitry or robotic process automation system may manage or process, including, but not limited to, providing notices to lenders, researching and collecting payment history, providing receipts to borrowers, calculating the next payment due date, calculating the final payment amount and date and time, notifying borrowers of the next payment due date, determining a payment schedule or alternative payment schedule, notifying payment schedules or alternative payment schedules, or other actions related to the payment of a loan. Those skilled in the art and knowledgeable about the contents of this specification and payment schedules and alternative payment schedules related to loans can readily determine the purpose and use of this term in the events disclosed herein or in various other embodiments and contexts.

[0271] As used herein, the term "regulatory notice requirement" (and its derivatives) is intended to be broadly interpreted and understood to describe any obligation or condition to send a notice or message to another party or entity. Regulatory notice requirements may be required under one or more triggered conditions or may be generally required. For example, a lender may have a regulatory notice requirement to notify a borrower of a loan default, a change in interest rate on a loan, or other notice related to the transaction or loan. The regulatory aspect of the term derives from provisions establishing communication obligations arising from the laws, rules, or codes of a particular jurisdiction. In certain embodiments, policy guidelines may be treated as regulatory notice requirements. For example, this may be the case when a lender has an internal notice policy that exceeds the regulatory requirements of one or more jurisdictions related to the transaction. The notice aspect generally refers to formal communication and may take a variety of forms, but may be specifically identified as registered mail, facsimile, email transmission, other physical or electronic form, the content of the notice, and / or timing requirements for the notice. The requirement aspect arises from the need for the parties to fulfill their obligations to comply with laws, regulations, standards, policies, standard practices, or the terms of the contract or loan. In certain embodiments, a smart contract may handle or trigger regulatory notification requirements and provide appropriate notice to the borrower, determined based on at least one of the following: the lender, the borrower, the funds provided by the loan, the repayment of the loan, the collateral for the loan, or any other location specified in the terms of the loan, transaction, or contract. Failure of a party or entity to meet such regulatory notification requirements may trigger a change in the rights or obligations between the parties. For example, a lender providing a non-compliant notice to the borrower may trigger automated actions or triggers based on the terms and conditions of the loan and / or triggers based on external information (e.g., regulatory instructions, the lender's internal policies, etc.). This may be influenced by smart contract circuitry and / or robotic process automation systems.Those skilled in the art can readily determine the purpose and use of regulatory notification requirements in the various embodiments and contexts set forth in this disclosure based on the content of this disclosure and generally available knowledge of the contemplated system.

[0272] As used herein, the term "regulatory notice requirement" also describes an obligation or condition to send a notice or message to another party or entity based on general or specific policy rather than on a specific jurisdiction, law, regulation, or code of a specific location. Regulatory notice requirements may be established as appropriate or recommended, rather than mandatory or required, unless a specific condition is triggered or generally required. For example, a lender may establish a regulatory notice requirement to provide borrowers with notices about new informational websites, upcoming loan interest rate changes, or advisory or helpful notices regarding transactions or loans as a policy requirement (although mandatory notices may also be included as policy requirements). Thus, when using the term regulatory notice requirement in a policy-based context, the smart contract circuit processes or triggers the regulatory notice requirement to provide borrowers with appropriate notices, even when not necessarily required by law, regulation, or code. The basis for the notice or communication may be based on prudence, courtesy, custom, or obligation.

[0273] The term "regulatory notice" may also be used herein to describe an obligation or condition to send a notice or message to a specific party or entity, such as a lender or borrower. Regulatory notices may be specifically directed to a particular party or entity, or to a group of parties or entities. It may be appropriate or necessary to provide a specific notice or communication to a borrower, for example, when a borrower defaults by failing to make a scheduled loan payment. In such cases, regulatory notices targeted to specific users, such as lenders or borrowers, may be due to regulatory notice requirements based on jurisdiction-specific regulatory requirements or policies, or for other reasons. Accordingly, in some circumstances, a smart contract may process or trigger a regulatory notice to provide appropriate notice to a specific party, such as a borrower. Such notices may not necessarily be required by law, regulation, or code, but may be provided based on prudence, courtesy, or custom. Failure to meet regulatory notice requirements for a specific party or parties may create situations in which one or more parties or entities may waive certain rights, take automated actions, or trigger other conditions or clauses. Those skilled in the art can readily determine the purpose and use of regulatory notification requirements in the various embodiments and contexts disclosed herein based on their generally available knowledge of the subject matter disclosed herein and the systems contemplated.

[0274] As used herein, "regulatory foreclosure requirements" (and derivatives thereof) are understood to broadly describe obligations or conditions for triggering, processing, or completing a loan default, foreclosure, repossession of collateral, or other related foreclosure action. Regulatory foreclosure requirements may be required under one or more triggering conditions or may be generally required. For example, a lender may have a regulatory foreclosure requirement to provide borrowers with notice of loan default or other notice related to a loan default prior to foreclosure. The regulatory aspect of the term arises from communication obligations imposed by laws, regulations, or codes in a particular jurisdiction. The foreclosure aspect generally relates to the specific remedy of foreclosure, or the repossession of secured property and loan default, and may take various forms, but may be specifically set forth in the terms of a loan agreement. The requirement aspect arises from the need for a party to perform its obligations to comply with or fulfill the terms of a law, regulation, code, or contract or loan. In certain embodiments, the smart contract circuitry may process or trigger regulatory seizure requirements and handle appropriate tasks related to such seizure actions, determined based on at least one of the jurisdictions of the lender, borrower, funds provided through the loan, repayment of the loan, or collateral for the loan, or other jurisdictions specified in the terms of the loan, transaction, or agreement. Failure to meet regulatory seizure requirements may cause a party or entity (e.g., a lender) to waive certain rights. Alternatively, failure to comply with regulatory notice requirements may trigger automated actions or other conditions or provisions. Those skilled in the art, given their generally available knowledge of the disclosures herein and the contemplated systems, can readily determine the purpose and use of regulatory seizure requirements in the various embodiments and contexts disclosed herein.

[0275] The term "regulatory foreclosure requirements" may also be used herein to describe obligations to trigger, process, or complete loan defaults, foreclosures, collateral repossessions, or other related foreclosure actions. They may be established based on general or specific policies rather than based on specific jurisdictions, laws, regulations, or codes (e.g., jurisdiction-specific regulatory foreclosure requirements). Regulatory foreclosure requirements may be established as appropriate or recommended, rather than mandatory or required, when specific conditions are triggered or when generally required. For example, a lender may establish regulatory foreclosure requirements as policy-based to provide borrowers with notices regarding loan defaults or advisory or helpful notices related to transactions or loans (although mandatory notices may also be included as policy-based). Thus, when using the term regulatory foreclosure requirements in a policy-based context, a smart contract may process or trigger regulatory foreclosure requirements and provide appropriate notices to borrowers, which may not necessarily be required by law, regulation, or code. The basis for notice or communication may be based on prudence, courtesy, custom, industry practice, or duty.

[0276] The term "regulatory foreclosure requirement" may also be used to describe obligations or conditions that must be fulfilled pursuant to a specific user, such as a lender or borrower. Regulatory notices may be specifically directed to either a specific party or entity, or to multiple parties or entities. For example, if a borrower defaults due to failure to make scheduled loan payments, it may be appropriate or required to provide a specific notice or communication to the borrower. Such regulatory foreclosure requirements may be targeted to specific users, such as lenders or borrowers, and may be based on jurisdiction-specific regulatory foreclosure requirements, policy-based requirements, or other requirements. For example, foreclosure requirements may relate to a specific entity or group of entities (e.g., "preferred" or "first-default" borrowers) involved in a transaction. Thus, in some circumstances, smart contract circuitry may process or trigger obligations or actions that must be fulfilled pursuant to a foreclosure. This action may be directed or issued by a specific party, such as a lender or borrower, and may not necessarily be required by law, regulation, or code, but may be provided based on prudence, courtesy, or custom. Obligations or conditions to be fulfilled for a particular user may form part of the terms and conditions applicable to that user or may be known to that user (e.g. when an insurance company or bank advertises specific treatment for particular customer classes such as first-time default customers or first-time accident customers). Obligations or conditions to be fulfilled for a particular user may not be known to apply to that user (e.g. when a bank has a policy regarding the user class to which a particular user belongs, but the user is not aware of the classification).

[0277] As used herein, "value," "valuation," and "valuation model" (and similar terms) are understood to broadly describe approaches to assessing and determining the estimated value of collateral. Without being limited to other aspects or descriptions herein, a valuation model may be used in combination with: collateral (e.g., collateralized property), artificial intelligence services (e.g., to improve a valuation model), data collection and monitoring services (e.g., to establish a valuation amount), valuation services (e.g., the use, improvement, or process of a valuation model), and / or the results of transactions involving collateral (e.g., as a basis for improving a valuation model). A "jurisdiction-specific valuation model" refers to a valuation model used in a particular geographic / jurisdiction or region, where the jurisdiction is specific to the jurisdiction of the lender, borrower, funds transfer, loan disbursement, or collateral for the loan, or any combination thereof. In certain embodiments, jurisdiction-specific valuation models consider jurisdictional influences on the valuation of collateral, including at least the following: the rights and obligations of borrowers and lenders in the relevant jurisdiction; the jurisdiction's influence on the transfer, import, export, substitution, or liquidation of collateral; the jurisdiction's influence on the timing of default and collateral foreclosure or collection; and / or the jurisdiction's influence on the volatility or sensitivity of collateral value determinations. In certain embodiments, geographic location-specific valuation models consider geographic location influences on the valuation of collateral, and may include similar considerations of jurisdictional influences (although jurisdictional location may differ from geographic location). Additionally, they may include the following additional influences: weather-related influences; the distance between the collateral and monitoring, maintenance, or foreclosure services; and / or proximity to risk phenomena (e.g., fault lines, industrial areas, nuclear power plants, etc.). Valuation models may utilize offset collateral valuations (e.g., general values ​​such as the market value of similar or fungible collateral, or the value of items that correlate with the value of the collateral) as part of the valuation of the collateral.In certain embodiments, the artificial intelligence circuitry iteratively refines the valuation model using information from the same or other transactions, e.g., information over time between multiple transactions involving similar or offsetting collateral, and / or outcome information (e.g., whether a loan transaction completed successfully or unsuccessfully, or in response to a collateral foreclosure or sale event) indicative of a real-world collateral valuation decision, to refine the valuation model. In certain embodiments, the artificial intelligence circuitry is trained on a collateral valuation dataset (e.g., through interaction with a predetermined valuation amount and / or a trainer (e.g., human, accounting valuation, and / or other valuation data)). In certain embodiments, the valuation model and / or parameters of the valuation model (e.g., assumptions, calibration values, etc.) are determined and / or negotiated as part of the terms of the transaction (e.g., a loan, a set of loans, or a subset of a set of loans). Given the content of this disclosure and commonly available knowledge of the system under consideration, one of ordinary skill in the art can readily determine which portions of this disclosure are useful for application to a particular valuation model and how to select or combine valuation models. Considerations that one of ordinary skill in the art would consider in selecting an appropriate valuation model or example of the present disclosure include, but are not limited to, the following: legal considerations for valuation models in the jurisdiction of the collateral; available data regarding the particular collateral; the type of transaction / loan envisaged; the specific type of collateral; the loan-to-collateral value ratio; the collateral-to-loan ratio; the total transaction / loan amount; the borrower's credit score; accounting practices in the type of loan and / or related industry; uncertainties regarding any of the above; and / or sensitivities regarding any of the above. The specific examples of valuation models and considerations described herein are provided for illustrative purposes, and any embodiments benefiting from the disclosure herein and considerations that one of ordinary skill in the art would understand in light of the contents of this disclosure are expressly intended to be within the scope of this disclosure.

[0278] As used herein, "market value data" or "marketplace information" (including other forms or variations) is understood to broadly refer to data or information related to the valuation of real estate, assets, collateral, or other valuable items that are the subject of a loan, security, or transaction. Market value data or marketplace information may change over time and may be estimated, calculated, or determined objectively or subjectively from a variety of sources. Market value data or marketplace information may relate directly to the collateral or offsetting collateral. Market value data or marketplace information may include financial data, market valuations, product evaluations, customer data, market research to understand customer needs and preferences, competitive information regarding competitors and suppliers, sales performance, transactions, customer acquisition costs, customer lifetime value, brand awareness, churn rates, etc. The term may be used in various contracting and lending contexts, including, without limitation, lending, refinancing, consolidation, factoring, brokerage, foreclosure, and data processing (e.g., data collection), or any combination thereof. Market value data or marketplace information may be used as a noun to refer to a single number or multiple numbers or data. For example, market value data or marketplace information may be used by lenders to determine whether real estate or assets qualify as collateral, or to determine foreclosure in the event of a loan default. These use cases are not limited to these. Market value data or market information may also be used to calculate loan-to-value (LTV) ratios. In certain embodiments, aggregation services, smart contract circuitry, and / or robotic process automation systems may estimate or calculate market value data or market information from one or more data sources or information sources. In some cases, market data values ​​or market information (depending on the data / information contained therein) may execute automated actions or trigger other conditions or clauses.Those skilled in the art, in light of the disclosure herein and commonly available knowledge of the system under consideration, as well as available relevant marketplace information, can readily determine the purpose and use of this term in the various forms, embodiments, and contexts disclosed herein.

[0279] As used herein, the terms "similar collateral," "similar to collateral," "offset collateral," and other forms or variations thereof are understood to broadly refer to property, assets, or items of value similar in nature to collateral (e.g., items of value held as security) in a loan or other transaction. Similar collateral refers to property, assets, collateral, or other items of value that may be aggregated with, substituted for, or referenced in combination with other collateral, including the type of collateral item, the category of collateral item, the age of the collateral item, the condition of the collateral item, the history of the collateral item, ownership of the collateral, the custodian of the collateral, security interests in the collateral, the status of the owner of the collateral, liens on the collateral, the storage condition of the collateral, the geographic location of the collateral, the jurisdiction of the collateral, and similar matters. In certain embodiments, offset collateral refers to property that has a value correlation with the collateral. For example, the offset collateral may exhibit similar price fluctuations, volatility, storage requirements, or similar characteristics as the collateral. In certain embodiments, similar collateral may be aggregated to form a larger security interest or pledge for additional lending, distribution, or trading. In certain embodiments, offsetting collateral may be utilized to determine the valuation of collateral. In certain embodiments, smart contract circuitry or robotic process automation systems may estimate or calculate values, data, or information related to similar collateral or perform functions that aggregate similar collateral. One of ordinary skill in the art, with the benefit of this disclosure and commonly available knowledge of the system under consideration, can readily determine the purpose and use of similar collateral, offsetting collateral, or related terms related to collateral in the various forms, embodiments, and contexts disclosed herein.

[0280] As used herein, the term "restructuring" (and other forms of "reorganization") is understood broadly to mean any modification of the terms or conditions, features, collateral, or other considerations affecting a loan or transaction. Restructuring can have successful or unsuccessful outcomes, including when revised terms or conditions are adopted by the parties or when no revision or restructuring occurs. Restructuring can occur in various contract or loan contexts, including, but not limited to, application, lending, refinancing, collection, consolidation, factoring, brokerage, foreclosure, or any combination thereof. Debt may also be restructured, which means that the timing, amount, collateral, or other terms of the debt are changed. For example, a borrower may restructure a loan to address a change in its financial situation, or a lender may propose a debt restructuring to a borrower out of its own necessity or prudence. In certain embodiments, the smart contract circuitry or robotic process automation system may automatically or manually restructure debt based on monitored conditions, create debt restructuring options, manage the debt restructuring negotiation or implementation process, or take other actions related to restructuring or modifying the terms of a loan or transaction debt or transaction. Those skilled in the art, based on the disclosure herein and commonly available knowledge of the contemplated systems, can readily determine the purpose and usage of this term in various embodiments and contexts, including in the context of debt.

[0281] As used herein, the terms "social network data collection," "social network monitoring service," and "social network data collection and monitoring service" (including their various forms or derivatives) are understood to broadly refer to services related to the acquisition, organization, monitoring, or other processing of data or information obtained from one or more social networks. Social network data collection and monitoring services may be offered as part of a related service system or as a standalone service set. Social network data collection and monitoring services may be provided by a platform or system. Social network data collection and monitoring services may be used in a variety of contexts, including, but not limited to, lending, refinancing, negotiation, collection, consolidation, factoring, brokerage, foreclosure, or any combination thereof. Social network data collection and monitoring requests (including configuration parameters) may be requested by other services, initiated automatically, or triggered in response to conditions or circumstances. Interfaces may be provided for configuring, initiating, viewing, or otherwise operating the social network data collection and monitoring service. As used herein, "social network" refers to a large platform where data and communication occurs between individuals and / or entities, and where such data and communication is at least partially accessible by the system. In certain examples, social network data may include publicly available information (e.g., information accessible without authentication). In certain embodiments, social network data may also include information that is appropriately accessible to an embodiment system, but that is not publicly available due to subscription access or other access methods (e.g., access pursuant to a privacy policy between the social network and the user).A social network may be primarily social in nature, but may additionally or alternatively include professional networks, alumni networks, industry-related networks, academic-oriented networks, or similar networks. In certain embodiments, a social network is a platform (e.g., a crowdsourcing platform) configured to accept queries or requests from users (and / or subsets of users who meet certain criteria), and users may be aware that certain communications may be shared with the requestor, a subset of users of the platform, or publicly available. In certain embodiments, the social network's data collection and monitoring services may be performed by smart contract circuitry or a robotic process automation system. One skilled in the art, given the disclosure herein and commonly available knowledge of the contemplated systems, can readily determine the purpose and use of the social network's data collection and monitoring services in various embodiments and contexts disclosed herein.

[0282] As used herein, the terms "crowdsourcing" and "social network information" are understood more broadly to describe information obtained or provided in connection with a crowdsourcing model or transaction, or information obtained or provided on or in connection with a social network. Crowdsourcing and social network information may be provided by a platform or system. Crowdsourcing and social network information may be obtained, provided, or communicated from a group of information providers, and responses to the request may be collected and processed. Crowdsourcing and social network information may provide information, terms, or factors related to a loan or contract. Crowdsourcing and social network information may be provided without restriction, including privately or publicly, or a combination thereof. In certain embodiments, crowdsourcing and social network information may be obtained, provided, organized, or processed without restriction by smart contract circuitry. In this case, crowdsourcing and social network information may be managed by smart contract circuitry that processes the information to meet set parameters. Those skilled in the art can readily determine the purpose and use of these terms in various embodiments and contexts disclosed herein based on the content of this disclosure and commonly available knowledge of the contemplated system.

[0283] As used herein, "negotiation" (and forms such as "negotiate" and "negotiation") is understood broadly to mean discussions or communications between parties or entities to bring about a compromise, outcome, or agreement. Negotiations may result in successful outcomes where terms are agreed upon between the parties, unsuccessful outcomes where the parties do not agree to certain terms, or a combination thereof. Negotiations may be successful in one aspect or for a particular purpose and unsuccessful in another aspect or for a different purpose. Negotiations may occur in a variety of contracting and lending contexts, including lending, refinancing, collection, consolidation, factoring, brokerage, foreclosure, or a combination thereof. For example, a borrower may negotiate interest rates and loan terms with a lender. In another example, a defaulting borrower may negotiate with a lender about alternative solutions to avoid foreclosure. In certain embodiments, smart contract circuitry or a robotic process automation system may negotiate on behalf of one or more parties and process appropriate tasks to complete or attempt to negotiate terms. In some cases, negotiations by a smart contract or robotic process automation system may not be completed or successful. Successful negotiation may trigger automated actions or the implementation of other terms or provisions by a smart contract circuit or robotic process automation system. Those skilled in the art can readily determine the purpose and use of negotiation in the various embodiments and contexts disclosed herein based on the disclosure herein and commonly available knowledge of the system under consideration.

[0284] The term "negotiation" may be used in various forms and may be more specifically used herein as a verb (e.g., negotiate) or a noun (e.g., bargaining) to describe the context of reaching a result through mutual discussion. For example, a robotic process automation system may negotiate contract terms on behalf of parties, which is an example of its use as a verb phrase. In another example, a robotic process automation system may negotiate contract terms regarding loan amendments, an integration proposal, or other terms. As a noun phrase, a negotiation (e.g., an event) may be performed by the robotic process automation system. Thus, in some circumstances, a smart contract circuit or robotic process automation system may negotiate terms (e.g., as a verb phrase), or a description of that performance may be considered a negotiation (e.g., as a noun phrase). Given this disclosure and knowledge of negotiation, or other forms of "negotiation," one skilled in the art can readily determine the purpose and use of this term in various embodiments and contexts disclosed herein.

[0285] The term "negotiation," in its various forms, may also be used to specifically describe an outcome resulting from a mutual compromise or the completion of negotiations. For example, a loan may be considered "negotiated" as a successful outcome of an agreement between the parties, whether by a robotic process automation system or other means. In this case, the smart contract circuitry or robotic process automation system is considered to have negotiated a set of terms, conditions, or the negotiated loan to completion because the negotiations are complete. Those skilled in the art, with their commonly available knowledge of the subject matter disclosed herein and the contemplated systems, can readily determine the purpose and use of this term in relation to a mutually agreed upon outcome through the completion of negotiations in the various embodiments and contexts disclosed herein.

[0286] The term "negotiation," in its various forms, may be used specifically to characterize an event in which a set of agreeable terms between parties is reached (e.g., a negotiation event or event negotiation). Events requiring mutual agreement or compromise between parties may be considered, without limitation, a negotiation event. For example, the process of arriving at a mutually acceptable set of terms between parties during the procurement of a loan may be considered a negotiation event. Accordingly, under some circumstances, smart contract circuitry or robotic process automation systems may handle the communications, actions, or behavior of the parties in a negotiation event.

[0287] As used herein, the term "collection" (and forms such as "collect") is interpreted broadly to describe the act of acquiring tangible (e.g., physical goods), intangible (e.g., data, licenses, or rights), or monetary (e.g., payment) goods or other obligations or assets from a source. The term may refer to the entire acquisition process, from early to later stages of the related tasks, through to the completion of the acquisition of the items. Collection may include the successful outcome of the items being delivered to a party, or the unsuccessful outcome of the items not being delivered or acquired, or a combination thereof (e.g., delayed or defective delivery). Collection occurs in a variety of contracting and lending contexts, including lending, refinancing, consolidation, factoring, brokerage, foreclosure, and data processing (e.g., data collection), including any combination thereof. Collection may be used as a noun (e.g., data collection or collection of a late payment, referring to or characterizing an event), as a noun referring to a collection of items (e.g., collection of collateral for a loan, referring to the number of items in a transaction), or as a verb (e.g., collecting payment from a borrower). For example, a lender may collect a late payment from a borrower through an online payment transaction or successfully collect a late payment obtained through a customer service call. In some embodiments, smart contract circuitry or a robotic process automation system may perform collections on behalf of one or more parties and process the appropriate tasks to complete or attempt to collect one or more items (e.g., a late payment). In some cases, negotiations by a smart contract or robotic process automation system may not be completed or successful, and such results may result in automated actions being taken or other conditions or clauses being triggered. Those skilled in the art, given their generally available knowledge of the present disclosure and the systems envisioned, can readily determine the purpose and use of collection in the various forms, embodiments, and contexts disclosed herein.

[0288] The term "collection" may also be used more specifically herein as a noun to describe an event or thing in context, such as a collection event or a collection payment. For example, a collection event may include, but is not limited to, activities related to the communication to a party or the acquisition of goods in such activities. A "collection payment" may refer, for example, to a payment from a borrower obtained through a collection process or a payment made through a lender's collections department. However, without being limited to late, delinquent, or defaulted loans, collection may characterize an event, payment, department, or other noun related to a transaction or loan as a remedy for a delinquent matter. Thus, in some circumstances, the act of a smart contract circuit or robotic process automation system collecting a payment or installment from a borrower may be considered a collection event.

[0289] The term "collection" may be used more specifically as an adjective or other form to describe a litigation-related context, such as the outcome of a lawsuit regarding a loan delinquency or default payment. For example, the outcome of a collection lawsuit may relate to late payments owed by a borrower or other party, and collection efforts regarding such late payments may be subject to litigation by the party. Accordingly, in some circumstances, smart contract circuitry or robotic process automation systems may receive, determine, or manage the outcome of a collection lawsuit.

[0290] The term "collection" may be used in various forms, more specifically as an adjective or other form, to describe the context of acquisition-related actions. For example, collection actions (e.g., actions that encourage the presentation or acquisition of payment due on a late or defaulted loan or other debt). The terms "collection revenue," "financial revenue from collection," and "collection financial revenue" may be used. The outcome of such collection actions may or may not result in financial revenue. For example, collection actions may result in the elicitation of one or more payments due on a loan, thereby providing financial revenue to another party, such as a lender. Thus, in some circumstances, smart contract circuitry or robotic process automation systems may generate financial revenue from collection actions or manage or assist in the financial revenue. In some instances, collection actions may include the need for collection litigation.

[0291] The term "collection" may be used in various forms (e.g., collections ROI, recovery ROI, collections activity ROI, collections activity ROI, etc.) and may be used more specifically herein to specifically describe contexts in which there is a return on investment (ROI) for actions related to the receipt of value, such as prompting or obtaining payment of outstanding or defaulted payments on loans or other debts (collection actions). The results of such collection actions may or may not have an ROI, either for the collection action itself (as the ROI for the collection action) or for the overall loan or transaction that is the subject of the collection action. For example, the ROI of a collection action on a defaulted loan may or may not be relevant depending on whether the ROI is provided to a party, such as the lender. Projected ROI for collections may be estimated or calculated based on actual events. In some circumstances, smart contract circuitry or robotic process automation systems may calculate an estimated ROI for a collection action or collection event or calculate an ROI for actual events occurring in a collection action or collection event. In some embodiments, such ROI may be either an estimated or actual value, and may be positive or negative.

[0292] Terms such as "reputation," "reputation measurement," "lender reputation," "borrower reputation," and "entity reputation" may include widely shared beliefs, opinions, and / or perceptions about an individual, entity, collateral, etc. Reputation measurements may be determined based on social data (e.g., likes / dislikes, reviews of the entity or products / services it offers, company or product rankings, current market and financial data (e.g., prices, forecasts, buy / sell recommendations, financial news about the entity, competitors, partners, etc.)). Reputation is cumulative; product reputation and the reputation of company leaders or key researchers may influence an entity's overall reputation. The reputation of an entity and its associated institutions (e.g., schools attended by students) may influence the entity's reputation. In some circumstances, smart contract circuitry or robotic process automation systems may collect or direct the collection of data related to the above and determine reputation measurements or rankings. The reputation measurement or ranking of an entity may be used by a smart contract circuit or robotic process automation system to determine whether to enter into a contract with the entity, determine the terms and interest rate of a loan, etc. In certain embodiments, the reputation determination metric may be associated with the outcome of one or more transactions (e.g., a comparison of the number of "likes" in a particular social media dataset with an outcome metric such as a successful payment, a successful negotiation outcome, the liquidation of a particular type of collateral, etc.) and used to determine the reputation measurement or ranking of the entity. Given the disclosure herein and commonly available knowledge of the system under consideration, one skilled in the art can readily determine the purpose and uses of reputation, reputation measurement or ranking, and / or its use in negotiations, determining transaction terms, determining whether to proceed with a transaction, and in various other embodiments and contexts disclosed herein.

[0293] The term "collection" in its various forms (e.g., collector) may be used more specifically herein to describe a party or entity that induces, manages, or facilitates collection actions, collection events, or other collection-related contexts. A measure of a party's (e.g., collector's) reputation may be estimated or calculated using objective, subjective, or historical metrics or data. For example, a collector may engage in collection actions, and the collector's reputation may be used to determine decisions, actions, or terms. Similarly, collection may also be used to describe objective, subjective, or historical metrics or data for measuring the reputation of an involved party, such as a lender, borrower, or debtor. In some circumstances, smart contract circuitry or robotic process automation systems may conduct collections or actions or implement collectors in trading or lending contexts.

[0294] The terms "collection" and "data collection" may be used herein to more specifically describe contexts related to the acquisition, organization, or processing of data or combinations thereof in various forms, including, but not limited to, data collection systems. The results of such data collection may also be related to, but not limited to, the collection of items (e.g., physical or logical grouping) or actions related to deferred payments (e.g., collateral collection, debt collection, etc.). For example, data collection may be performed by a data collection system, and the data may be acquired, organized, or processed for decision-making, monitoring, or other purposes related to future transactions or lending. In some circumstances, smart contracts or robotic process automation systems may incorporate data collection or data collection systems and perform all or part of the data collection. Those skilled in the art, based on the content of this specification and commonly available knowledge of the systems envisioned, can readily identify and distinguish the purpose and use of collection in the context of "data" or "information" as used herein.

[0295] The terms "refinance," "refinance activity," "refinance interactions," "refinance results," and similar terms are to be interpreted broadly herein. Without being limited to other aspects or explanations of this disclosure, refinance and refinance activity include replacing an existing mortgage, loan, bond, debt transaction, or the like with a new mortgage, loan, bond, or debt transaction that repays or terminates the previous financial transaction. In certain embodiments, modifications to the terms and conditions of a loan or material changes to the terms and conditions of a loan may be considered refinance activity. In certain embodiments, refinance activity is limited to modifications to a loan agreement that result in different financial outcomes. Typically, the new loan must be favorable to the borrower or issuer or mutually agreeable (e.g., improving the financial results of one party and improving the collateral or other results of the other party). Refinancing may be undertaken to lower interest rates, reduce periodic payments, change the loan term, change the collateral attached to the loan, consolidate debt into a single loan, restructure debt, change the type of loan (e.g., variable rate to fixed rate), repay loans as they come due, respond to an improvement in credit score, increase the loan amount, and / or respond to changing market conditions (e.g., interest rates, value of collateral, etc.).

[0296] Refinancing activities include initiating refinancing proposals, initiating refinancing requests, setting refinancing interest rates, setting refinancing payment schedules, setting refinance balances based on the amount or terms of the refinanced loan, establishing collateral for the refinance (including changing the collateral used), modifying the terms of the collateral, changing the amount of collateral, managing the use of refinance proceeds, releasing or establishing liens on appropriate collateral based on changes to the terms of the refinance, verifying ownership of new or existing collateral used in the refinance, managing the inspection process for ownership of new or existing collateral used in the refinance, preparing refinance applications, negotiating the terms of the refinanced loan, and completing the refinance. Refinancing and refinancing activities may be disclosed in data collection and monitoring services that collect training sets of interactions between entities regarding loan refinancing activities. Refinancing and refinancing activities may be disclosed in artificial intelligence systems trained using collected training set interactions including refinancing activities and their outcomes. Trained artificial intelligence may be used to provide similar functions, such as recommending and evaluating refinancing activities and making predictions regarding the likely outcomes of refinancing activities. Refinancing and refinancing activities may be implemented in a smart contract system that automates a subset of refinancing interactions and activities. For example, a smart contract system may automatically adjust interest rates on loans based on information collected from one or more of the following systems: an IoT system, a crowdsourcing system, a social network analysis service, and a data collection and monitoring service. Interest rates may be adjusted based on rules, thresholds, and model parameters that determine or recommend interest rates based on available interest rates from the lender's secondary lenders, borrower risk factors (including predicted risk based on one or more predictive models using artificial intelligence), and marketing factors (e.g., competing interest rates offered by other lenders). The outcomes and events of refinancing activities may be recorded on a distributed ledger.Based on the outcome of the refinancing activity, the smart contract for the refinancing loan will be automatically reconfigured to include the terms of the new loan (debt principal amount, debt balance, fixed interest rate, floating interest rate, payment amount, payment schedule, lump sum payment schedule, collateral designation, collateral fungibility designation, parties, guarantee, guarantor, collateral, personal guarantee, lien, term, contract terms, foreclosure conditions, default conditions, and consequences of default).

[0297] Those skilled in the art, based on commonly available knowledge of the content of this disclosure and the contemplated systems, can readily determine which portions of this disclosure would benefit from application to a particular refinancing activity, how to select or combine refinancing activities, how to implement a system, service, or circuit to automatically perform one or more (or all) aspects of a refinancing activity, and similar considerations when selecting an appropriate training set of interactions to train an artificial intelligence or embodiment of the present disclosure. While specific examples of refinancing and refinancing activities are described herein for illustrative purposes, all embodiments benefiting from the disclosure herein, and all considerations understood by those skilled in the art having the benefit of the disclosure herein, are expressly encompassed within the scope of this disclosure.

[0298] As used herein, the terms "consolidation," "consolidation activity," "loan consolidation," "debt consolidation," "consolidation plan," and similar terms should be interpreted broadly. Without being limited to other aspects or descriptions of this disclosure, consolidation, consolidation activity, loan consolidation, debt consolidation, or consolidation plan includes using a single larger loan to repay multiple smaller loans and / or using one or more of a first set of loans to repay at least a portion of a second set of loans. In embodiments, loan consolidations can 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 debtors into compliance with the consolidated loans or their other debt obligations. Potential loans eligible for consolidation are determined based on a model that processes attributes of the parties involved in a set of loans (e.g., party identity, interest rate, payment balance, payment terms, payment schedule, loan type, collateral type, parties' financial status, payment status, collateral status, value of collateral, etc.). Integration activities include managing at least any of the following: identifying loans from candidate loans, creating an integration proposal, creating an integration plan, creating content for the integration proposal, scheduling the integration proposal, notifying the integration proposal, negotiating amendments to the integration proposal, creating an integration agreement, executing the integration agreement, amending collateral for the loans, processing the integration application workflow, managing inspections, managing appraisals, setting interest rates, deferring payment requirements, setting payment schedules, and executing the integration agreement. In embodiments, there are systems, circuits, and / or services configured to determine or recommend an integration action or plan for a set of loan transactions or loans based on one or more events, conditions, states, actions, or the like.In some embodiments, the integration plan may be based on payment status, interest rates for the set of loans, current interest rates in the platform marketplace or external marketplaces, the status of the borrowers for the set of loans, the status of collateral or assets, risk factors of the borrowers, lenders, one or more guarantors, market risk factors, and similar factors. Integration and integration activities may be disclosed in a data collection and monitoring service that collects a training set of interactions between entities related to loan integration activities. Integration and integration activities may be disclosed in an artificial intelligence system trained using the collected training set of interactions (including integration activities and outcomes related to those activities). The trained artificial intelligence may be used based on models that recommend integration activities, evaluate integration activities, or make predictions regarding the likely outcomes of integration activities, based on the status of debt, the terms of the collateral or assets securing or backing the loans, the state of the business or business operations (e.g., accounts receivable, accounts payable, or similar), the terms of the parties (e.g., net worth, assets, debt, location, and other terms), the behavior of the parties (e.g., behavior indicating preferences, behavior indicating debt preference), and similar information. A smart contract may be used for various purposes, including recommending consolidation activities, evaluating consolidation activities, and making predictions regarding likely outcomes of consolidation activities based on models that include the parties' financial information (e.g., accounts receivable, accounts payable, etc.), the parties' status (e.g., net worth, assets, debt, location, and other status), and the parties' behavior (e.g., behaviors indicating preferences, behaviors indicating debt preferences, etc.). Debt consolidation, loan consolidation, and related consolidation activities may be disclosed in a smart contract system that automates a subset of consolidation interactions and activities. In some embodiments, consolidation may include consolidating the terms and conditions of a set of loans, selecting appropriate loans, setting payment terms for the consolidated loans, setting repayment plans for existing loans, communicating to facilitate the consolidation, and similar matters. In some embodiments, the smart contract's artificial intelligence may automatically recommend or set rules, thresholds, actions, parameters, and similar matters by learning based on the results of a training set.This results in the generation of a recommended consolidation plan, which specifies the course of actions necessary to achieve the recommended or desired outcome of the consolidation (e.g., within a range of acceptable outcomes). This plan may be automated and include conditional execution of steps based on monitored conditions and / or smart contract terms, and is created, configured, and / or recorded by the consolidation plan. The consolidation plan is determined and executed based, at least in part, on market factors (e.g., competitive interest rates offered by other lending institutions, value of collateral, etc.) and regulatory and / or compliance factors. Consolidation plans may be generated and / or executed to create new consolidation loans, create secondary loans related to consolidation loans, modify existing loans related to the consolidation, change the refinancing terms of consolidation loans, in foreclosure situations (e.g., changing secured loan interest rates to unsecured loan interest rates), in bankruptcy or default situations, market changes (e.g., changes in applicable interest rates), and other circumstances.

[0299] Some activities related to loans, collateral, legal entities, etc. may apply to various loans and may not expressly apply to integration activities. Whether an activity is classified as an integration activity is determined based on the loan context in which the activity is occurring. However, a person of ordinary skill in the art with the contents of this disclosure and commonly available knowledge of the system under consideration can readily determine which portions of this disclosure would benefit from application to specific integration activities, how to select or combine integration activities, how to implement the services, circuits, and / or systems described in this disclosure to perform particular loan integration operations, etc. While specific examples of integration and integration activities are described herein for illustrative purposes, all embodiments benefiting from the disclosure herein, and all considerations understood by a person of ordinary skill in the art having the benefit of the disclosure herein, are expressly encompassed within the scope of this disclosure.

[0300] Terms such as "loan factoring," "loan factoring transaction," "factor," "loan factoring transaction," "asset or collection of assets used in factoring," and similar terms are to be interpreted broadly herein. Without being limited to any other aspect or explanation herein, factoring may apply to the factoring of assets whose realizable value lies in the future, such as invoices, inventory, and accounts receivable. For example, accounts receivable have higher value when paid and a lower risk of default. Inventory and work in progress (WIP) may have higher value as finished products rather than as components. References to accounts receivable are to be construed as including these terms and are not limiting. Factoring includes transactions in which accounts receivable are sold at a discount to obtain present value (usually cash). Factoring also includes transactions in which accounts receivable are used as collateral for short-term loans. In either case, the value of the receivable or invoice depends on factors such as the future value of money, the payment terms of the receivable (e.g., 30-day net payment vs. 90-day net payment), the degree of default risk on the receivable, the status of the receivable, the status of WIP, the status of inventory, the status of delivery and / or shipment, the financial position of the debtor for the receivable, the shipped or invoiced status, the payment status, the borrower's status, the inventory status, the borrower's risk factors, the lender, one or more guarantors, market risk factors, the status of the debt (are there other liens on the receivable, are payments on inventory outstanding), the amount of secured assets, etc. conditions (e.g., the state of inventory (current or outdated), whether the invoice is outstanding), the state of the parties' business or operations, the parties' circumstances (net worth, assets, liabilities, location, and other conditions), the parties' behavior (e.g., behavior indicating preferences, behavior indicating negotiating style), current interest rates, current regulatory compliance issues related to the inventory or accounts receivable (e.g., if inventory is being factored, whether the target product has the appropriate approvals), legal action against the borrower, and many other factors, including predicted risk based on one or more predictive models using artificial intelligence. A factor is a person, company, entity, or group of persons that provides value in exchange for the direct acquisition of an invoice through the sale of the invoice or the use of the invoice as collateral for a loan.Factoring involves identifying candidates (lenders and borrowers) for factoring, formulating a factoring plan (specifying the proposed scope of receivables (e.g., all, partial, or only those meeting certain criteria) and the proposed discount rate), notifying potential parties of the plan, making and accepting offers, verifying the quality of the receivables, and defining the terms for handling the receivables over the term of the loan. While examples of factoring and factoring activities are provided herein for illustrative purposes, all embodiments benefiting from the disclosure herein and all considerations understood by those skilled in the art in light of the disclosure herein are expressly encompassed within the scope of this specification.

[0301] As used herein, t...

Claims

1. an intelligence system running on a plurality of processors maintaining a plurality of training data sets aggregated from a plurality of different data sources; training, by the intelligence system, a predictive model based on a training dataset of the plurality of training datasets, the predictive model being one of a plurality of different predictive models maintained by the intelligence system, the predictive model being trained to minimize an error rate with respect to an outcome parameter; deploying, by the intelligence system, the predictive model to respond to prediction requests from one or more intelligence service clients of the intelligence system; the intelligence system aggregating result data collected from selected ones of the plurality of different data sources, the result data relating to predictions made by the predictive model, the result data being included in the training data set; said intelligence system enhancing a predictive model based on a training dataset including outcome data; the intelligence system monitoring the outcome data to determine whether the predictive model is biased based on the outcome data and one or more governance parameters; In response to determining that the predictive model is biased with respect to one or more monitored features, preventing the predictive model from being used to service subsequent prediction requests from one or more intelligence service clients; A method comprising:

2. updating the training dataset with the modified training data; retraining the predictive model based on an updated training dataset that includes the synthesized data; The method of claim 1 , further comprising: re-deploying the predictive model to accommodate subsequent prediction requests.

3. 3. The method of claim 2, wherein the predictive model is retrained using a second machine learning algorithm that is different from a first machine learning algorithm used to train the machine learning algorithm.

4. The method of claim 2 , wherein the modified training data is synthetic training data.

5. updating the training data set with modified training data, 5. The method of claim 4, further comprising generating a synthesized training data set based on a sub-segment of the results data.

6. generating a synthesized training data set based on a sub-segment of the resulting data; The method of claim 5 , comprising generating synthetic training data based on the training data using a synthetic minority oversampling technique.

7. 10. The method of claim 1, further comprising: training a new predictive model based on a training dataset including the outcome data, wherein the new predictive model is trained using a second machine learning algorithm that is different from the first machine learning algorithm used to train and enhance the predictive model.

8. The method of claim 1 , further comprising generating a notification that is sent to a human user via a user device.

9. 10. The method of claim 1, wherein monitoring the outcome data to determine whether the model is biased comprises calculating a drift value corresponding to the predictive model based on each feature vector corresponding to each outcome of each prediction made by the predictive model.

10. 10. The method of claim 9, wherein the predictive model is determined to be biased in response to a drift value corresponding to the model violating a threshold defined in a governance criterion.

11. memory hardware configured to store instructions; processor hardware configured to execute instructions from the memory hardware, the instructions comprising: maintaining a plurality of training data sets aggregated from a plurality of different data sources by an intelligence system executed by a plurality of processors; training, by the intelligence system, a predictive model based on a training dataset of the plurality of training datasets, the predictive model being one of a plurality of different predictive models maintained by the intelligence system, the predictive model being trained to minimize an error rate with respect to an outcome parameter; deploying, by the intelligence system, the predictive model in response to prediction requests from one or more intelligence service clients of the intelligence system; aggregating, by the intelligence system, outcome data collected from selected ones of the plurality of different data sources, the outcome data relating to predictions made by the predictive model, the outcome data being included in the training data set; enhancing, by the intelligence system, a predictive model based on a training dataset including outcome data; monitoring, by the intelligence system, the outcome data to determine whether the predictive model is biased based on the outcome data and one or more governance parameters; and and processor hardware, including: in response to determining that the predictive model is biased with respect to one or more monitored features, preventing the predictive model from being used to service subsequent prediction requests from one or more intelligence service clients; A system including:

12. updating the training dataset with the modified training data; retraining the predictive model based on an updated training dataset that includes the synthesized data; and 12. The system of claim 11, further comprising: re-deploying the predictive model to accommodate subsequent prediction requests.

13. 13. The system of claim 12, wherein the predictive model is retrained using a second machine learning algorithm that is different from a first machine learning algorithm used to train the machine learning algorithm.

14. The system of claim 12 , wherein the modified training data is synthesized training data.

15. Updating the training data set with revised training data includes:

15. The system of claim 14, further comprising generating a synthesized training data set based on a sub-segment of the results data.

16. generating the synthesized training data set based on a sub-segment of the resulting data; 16. The system of claim 15, comprising generating synthetic training data based on the training data using a synthetic minority oversampling technique.

17. training a new predictive model based on a training dataset including the outcome data; 12. The system of claim 11, wherein the new predictive model is trained using a second machine learning algorithm that is different from the first machine learning algorithm used to train and enhance the predictive model.

18. The system of claim 11 , further comprising generating a notification that is sent to a human user via a user device.

19. maintaining a plurality of training data sets aggregated from a plurality of different data sources by an intelligence system running on a plurality of processors; training, by the intelligence system, a predictive model based on a training dataset of the plurality of training datasets, the predictive model being one of a plurality of different predictive models maintained by the intelligence system, the predictive model being trained to minimize an error rate with respect to an outcome parameter; deploying, by the intelligence system, the predictive model in response to prediction requests from one or more intelligence service clients of the intelligence system; aggregating, by the intelligence system, outcome data collected from selected ones of the plurality of different data sources, the outcome data relating to predictions made by the predictive model, the outcome data being included in the training data set; enhancing, by the intelligence system, the predictive model based on a training dataset including the outcome data; monitoring, by the intelligence system, the outcome data to determine whether the predictive model is biased based on the outcome data and the one or more governance parameters; and in response to determining that the predictive model is biased with respect to one or more monitored features, preventing the predictive model from being used to service subsequent prediction requests from one or more intelligence service clients; 1. A non-transitory computer-readable medium containing instructions including:

20. updating the training dataset with the modified training data; retraining the predictive model based on an updated training dataset that includes the synthesized data; 20. The non-transitory computer-readable medium of claim 19, further comprising: redeploying the predictive model to accommodate subsequent prediction requests.

21. one or more processors of the platform training a large-scale language model (LLM) on a training dataset including a plurality of workflows, and training, for each of the plurality of workflows, a workflow label indicating a respective purpose of the workflow, wherein each workflow of the plurality of workflows includes a respective set of tasks to be performed in execution of the workflow and a respective set of workflow conditions that trigger execution of each task from the respective set of tasks; receiving, by one or more processors, a request to generate a new workflow on behalf of the enterprise from a user device associated with a user associated with the enterprise, the request indicating an intended purpose of the new workflow; one or more processors inputting a request to an LLM; one or more processors obtaining a proposed workflow from the LLM, the proposed workflow consisting of a proposed task set and a proposed workflow condition set; outputting, by the one or more processors, the proposed workflow to the user equipment; receiving, by one or more processors, from a user device of a user, one or more refinements to the proposed workflow; one or more processors inputting improvements to the LLM; obtaining, by the one or more processors, an updated proposed workflow from the LLM in response to the requested refinements; outputting, by the one or more processors, the updated proposed workflow to the user device; In response to the user approving the updated workflow proposal, The one or more processors store the updated workflow proposal in a workflow library associated with the enterprise; and and deploying, by the one or more processors, the updated proposed workflow on behalf of the enterprise.

22. 22. The method of claim 21, wherein the set of workflows used to train the LLM includes a default workflow.

23. 23. The method of claim 22, wherein the set of workflows used to train the LLM further includes custom workflows defined by or on behalf of the enterprise.

24. 24. The method of claim 23, wherein the set of workflows used to train the LLM includes other enterprise custom workflows, which are custom workflows defined by or on behalf of other enterprises.

25. The method of claim 21 , wherein the one or more improvements include one or more additional tasks added to the proposed workflow.

26. The method of claim 21 , wherein the one or more improvements include one or more proposed tasks being removed from the proposed workflow.

27. 22. The method of claim 21, wherein the one or more improvements include one or more adjustments made to one or more of the set of proposed tasks or one or more of the set of proposed conditions.

28. The method of claim 21 , wherein the one or more refinements include one or more adjustments made to one or more of the set of proposed workflow conditions.

29. 22. The method of claim 21, wherein the one or more refinements include specifying one or more data sources to monitor in connection with execution of the proposed workflow.

30. The method of claim 21 , wherein the training dataset further comprises task labels for tasks defined in the plurality of workflows.

31. memory hardware configured to store instructions; processor hardware configured to execute instructions from the memory hardware, the instructions comprising: one or more processors of the platform training a large scale language model (LLM) on a training dataset including a plurality of workflows, and training, for each of the plurality of workflows, a workflow label indicating a respective purpose of the workflow, each of the plurality of workflows including a respective set of tasks to be performed in execution of the workflow and a respective set of workflow conditions that trigger execution of each task from the respective set of tasks; receiving, by one or more processors, a request to generate a new workflow on behalf of an enterprise from a user device associated with a user associated with the enterprise, the request indicating an intended purpose of the new workflow; one or more processors inputting a request to the LLM; one or more processors obtaining a proposed workflow from the LLM, the proposed workflow consisting of a proposed task set and a proposed workflow condition set; outputting the proposed workflow to the user device by the one or more processors; receiving, by one or more processors, from a user device of a user, one or more refinements to the proposed workflow; one or more processors inputting improvements to the LLM; obtaining, by the one or more processors, an updated workflow proposal from the LLM in response to the requested refinements; outputting the updated proposed workflow to the user device by the one or more processors; In response to the user approving the updated workflow proposal, the one or more processors storing the updated workflow proposal in a workflow library associated with the enterprise; deploying, by the one or more processors, the updated workflow proposal on behalf of the enterprise; processor hardware including: A system including:

32. 32. The system of claim 31, wherein the set of workflows used to train the LLM includes a default workflow.

33. 33. The system of claim 32, wherein the set of workflows used to train the LLM further includes custom workflows defined by or on behalf of the enterprise.

34. 34. The system of claim 33, wherein the set of workflows used to train the LLM includes other enterprise custom workflows, which are custom workflows defined by or on behalf of other enterprises.

35. 32. The system of claim 31, wherein the one or more improvements include one or more additional tasks added to the proposed workflow.

36. 32. The system of claim 31, wherein the one or more improvements include one or more proposed tasks to be removed from the proposed workflow.

37. 32. The system of claim 31, wherein the one or more improvements include one or more adjustments made to one or more of a set of proposed tasks or one or more of a set of proposed conditions.

38. 32. The system of claim 31, wherein the one or more refinements include one or more adjustments made to one or more of a set of proposed workflow conditions.

39. training, by one or more processors of the platform, a large scale language model (LLM) on a training dataset including a plurality of workflows, and training, for each of the plurality of workflows, a workflow label indicating a respective purpose of the workflow, wherein each workflow of the plurality of workflows includes a respective set of tasks to be performed in execution of the workflow and a respective set of workflow conditions that trigger execution of a respective task from the respective set of tasks; receiving, by one or more processors, a request to generate a new workflow on behalf of the enterprise from a user device associated with a user associated with the enterprise, the request indicating an intended purpose of the new workflow; one or more processors inputting a request to the LLM; one or more processors obtaining a proposed workflow from the LLM, the proposed workflow consisting of a proposed task set and a proposed workflow condition set; outputting the proposed workflow to the user device by the one or more processors; receiving, by one or more processors, from a user device of a user, one or more refinements to the proposed workflow; one or more processors inputting improvements to the LLM; obtaining, by the one or more processors, an updated workflow proposal from the LLM in response to the requested refinements; outputting the updated proposed workflow to the user device by the one or more processors; In response to the user approving the updated workflow proposal, the one or more processors storing the updated workflow proposal in a workflow library associated with the enterprise; and one or more processors deploying the updated workflow proposal on behalf of the enterprise.

40. 40. The non-transitory computer-readable medium of claim 39, wherein the set of workflows used to train the LLM includes a default workflow.

41. one or more processors accessing network connectivity information relating to the network connectivity of an authorizing entity, the authorizing entity approving a set of transaction requests to facilitate execution of the set of transactions; one or more processors identifying a problem related to network connectivity; and In response to the above problem, determining, by one or more processors, whether the problem prevents the approving entity from approving the series of transaction requests; automatically generating, by one or more processors, a workflow for correcting the problem in response to a problem that prevents an approving entity from approving a set of transaction requests, the workflow including a set of rules that determine which transactions in the set of transactions can be executed in the absence of network connectivity and approval from the approving entity; and The method includes the step of one or more processors automatically executing a subset of the set of transactions based on the workflow without approval from an approval entity.

42. 42. The method of claim 41, wherein the problem is associated with at least one of a poor signal, a hardware or software failure, a denial of service (DoS) attack, a lack of necessary planning, and network restrictions imposed by a jurisdiction.

43. 42. The method of claim 41, wherein generating a workflow to correct the problem includes accessing, by the one or more processors, an alternative network route that traverses different network nodes.

44. 42. The method of claim 41, wherein the workflow allows a set of steps to be bypassed such that information related to a subset of transactions is shared with a set of trusted systems.

45. 42. The method of claim 41, wherein the workflow allows a series of steps to be bypassed to allow a subset of the transactions to be completed.

46. 42. The method of claim 41, wherein the approving entity is associated with a banking institution.

47. 42. The method of claim 41, wherein the workflow allows transactions in a series of transactions to be completed below a predetermined threshold without approval or pre-approval from an approving entity.

48. 48. The method of claim 47, wherein the predetermined threshold is associated with a monetary threshold.

49. determining, by one or more processors, a trust level of the user associated with the merchant entity based on a threshold number of transactions completed by the user with the merchant entity within a period of time; 42. The method of claim 41, further comprising: in response to the user exceeding a threshold number of transactions with the sales entity, the one or more processors enabling subsequent transactions by the user with the sales entity following the occurrence of a network connectivity problem.

50. 42. The method of claim 41, wherein the workflow further comprises performing offline approval of at least one transaction request of the set of transaction requests.

51. memory hardware configured to store instructions; processor hardware configured to execute instructions from the memory hardware, the instructions comprising: accessing, by one or more processors, network connectivity information relating to the network connectivity of the authorizing entity, whereby the authorizing entity authorizes the set of transaction requests to facilitate execution of the set of transactions; Identifying, by one or more processors, problems related to network connectivity; and In response to the above problem, determining, by one or more processors, whether a problem prevents the approving entity from approving the series of transaction requests; automatically generating, by one or more processors, a workflow for correcting the problem in response to a problem that prevents an approving entity from approving the set of transaction requests, the workflow including a set of rules that determine which transactions in the set of transactions can be executed in the absence of network connectivity and approval from the approving entity; processor hardware, including one or more processors automatically executing a subset of the workflow-based set of transactions without approval from an approval entity; A system including:

52. 52. The system of claim 51, wherein the problem is associated with at least one of a poor signal, a hardware or software failure, a denial of service (DoS) attack, a lack of necessary planning, and network restrictions imposed by a jurisdiction.

53. 52. The system of claim 51, wherein generating a workflow to correct the problem includes accessing, by the one or more processors, an alternative network route that traverses different network nodes.

54. 52. The system of claim 51, wherein the workflow allows a set of steps to be bypassed such that information related to a subset of transactions is shared with a set of trusted systems.

55. 52. The system of claim 51, wherein the workflow allows a series of steps to be bypassed so that a subset of the transaction can be completed.

56. 52. The system of claim 51, wherein the approving entity is associated with a banking institution.

57. 52. The system of claim 51, wherein the workflow allows transactions in a series of transactions to be completed below a predetermined threshold without approval or pre-approval from an approval body.

58. 58. The system of claim 57, wherein the predetermined threshold is associated with a monetary threshold.

59. determining, by one or more processors, a user trust level associated with the merchant entity based on a threshold number of transactions completed by the user with the merchant entity within a period of time; 52. The system of claim 51, further comprising, in response to the user exceeding a threshold number of transactions with the sales entity, by the one or more processors, enabling subsequent transactions by the user with the sales entity following the occurrence of network connectivity issues.

60. 52. The system of claim 51, wherein the workflow performs offline approval of at least one transaction request of the set of transaction requests.

61. one or more processors receiving a set of asset trade requests associated with a set of asset trades, each asset trade request of the set of asset trade requests initiated by an entity of the set of entities; one or more processors determining a status of each asset trade request in the set of asset trade requests; one or more processors determining whether each asset trade request of the set of asset trade requests is authorized for the asset specified by the respective asset trade request; In response to determining that an asset transaction request is fraudulent, one or more processors rejecting the asset trade request; the one or more processors recommending at least one of a similar alternative asset and a set of similar alternative assets as a replacement for the asset; In response to determining that the asset trade request is approved, the one or more processors automatically trigger execution of the asset trade; determining, by one or more processors, a level of data accessibility associated with a set of asset transactions for each entity in the set of entities by determining a role for each entity in the set of entities; 10. A method comprising: automatically adjusting, by one or more processors, a level of data accessibility for each entity of a set of entities based on the entity's role.

62. 62. The method of claim 61, wherein the status includes either a pending status or a requested status.

63. 62. The method of claim 61, wherein rejecting the asset transaction request includes preventing details related to the dispute from being disclosed to the respective entity by the one or more processors.

64. The step of recommending at least one of a similar alternative asset and a set of similar alternative assets includes: automatically identifying, by the one or more processors, at least one of a similar substitute asset and a set of similar substitute assets based on determining similarity to the asset; 62. The method of claim 61, wherein the similarity is determined based on at least one of asset type and asset value.

65. 62. The method of claim 61, further comprising: in response to determining that the asset transaction request is fraudulent for the asset, the one or more processors automatically recommending or indicating a set of assets to be offered as alternative collateral for the lending transaction.

66. 62. The method of claim 61, wherein the role corresponds to a job title in response to an entity in the set of entities being associated with a human being.

67. 67. The method of claim 66, wherein job titles with more privileges correspond to increased levels of access to data, with increased levels of data access providing more detailed data.

68. 68. The method of claim 67, wherein a low level of data access is associated with an entity of the set of entities that (i) is permitted to obtain at least one of statistical data and group data, and (ii) is restricted from obtaining individual data.

69. 68. The method of claim 67, wherein the higher level of data access is associated with an entity of the set of entities that is authorized to obtain the aggregated data.

70. 62. The method of claim 61, further comprising one or more processors dynamically adjusting the number of roles to accommodate fine-grained permissions.

71. memory hardware configured to store instructions; processor hardware configured to execute instructions from the memory hardware, the instructions comprising: receiving, by one or more processors, a set of asset trade requests associated with the set of asset trades, each asset trade request of the set of asset trade requests initiated by an entity of the set of entities; determining, by one or more processors, a status of each asset trade request of the set of asset trade requests; determining, by the one or more processors, whether each asset trade request of the set of asset trade requests is authorized for the asset specified by the respective asset trade request; In response to determining that an asset transaction request is fraudulent, one or more processors rejecting the asset transaction request; recommending, by the one or more processors, at least one of a similar alternative asset and a set of similar alternative assets as a substitute for the asset; automatically triggering execution of the asset transaction by the one or more processors in response to determining that the asset transaction request is approved; determining, by one or more processors, a level of data accessibility associated with a set of asset transactions for each entity in the set of entities by determining a role for each entity in the set of entities; processor hardware, including automatically adjusting, by one or more processors, a level of data accessibility for each entity of the set of entities based on the entity's role; A system including:

72. 72. The system of claim 71, wherein the status includes either a pending status or a requested status.

73. 72. The system of claim 71, wherein rejecting the asset transaction request includes preventing details related to the dispute from being disclosed to the respective entity by the one or more processors.

74. Recommending at least one of a similar alternative asset and a set of similar alternative assets automatically identifying, by the one or more processors, at least one of a similar substitute asset and a set of similar substitute assets based on determining similarity to the asset; 72. The system of claim 71, wherein the similarity is determined based on at least one of an asset type and an asset value.

75. 72. The system of claim 71, further comprising: in response to determining that the asset transaction request is fraudulent for the asset, automatically recommending or indicating, by the one or more processors, a set of assets to be offered as alternative collateral for the lending transaction.

76. 72. The system of claim 71, wherein the role corresponds to a job title in response to an entity in the set of entities being related to a human being.

77. Job titles with more privileges correspond to increasing levels of access to data.

77. The system of claim 76, wherein increasing levels of data access provide more detailed data.

78. 78. The system of claim 77, wherein a low level of data access is associated with an entity of a set of entities that (i) is permitted to obtain at least one of statistical data and group data, and (ii) is restricted from obtaining individual data.

79. 78. The system of claim 77, wherein the higher level of data access is associated with an entity of the set of entities that is authorized to obtain the aggregated data.

80. 78. The system of claim 77, further comprising dynamically adjusting, by one or more processors, the number of roles to accommodate fine-grained permissions.

81. receiving, by one or more processors, a transaction request for a digital transaction to be performed on behalf of a business, the request being received from a device corresponding to the business entity and indicating a transaction type of the digital transaction, a transaction amount, and an account identifier of a counterparty account to the transaction; the one or more processors determining whether the business entity has sufficient authorization to initiate the digital transaction requested by the business entity based on the transaction type and a set of authorization rules defined by the business entity; and In response to determining that a corporate entity does not have sufficient authorization to enter into a digital transaction, the one or more processors determining a second business entity that can authorize the digital transaction based on a set of authorization rules defined by the business; sending, by the one or more processors, an authorization request to a user device of the second business entity, the authorization request requesting that the second business entity approve or deny the digital transaction; receiving, by the one or more processors, a response from the user device of the second business entity indicating whether the second business entity has authorized or denied the digital transaction; In response to the second entity's denial of the digital transaction, preventing the digital transaction from being completed; and In response to determining that the business entity has sufficient authorization to initiate the digital transaction or that the second business entity has authorized the digital transmission, selecting a digital wallet from a plurality of corporate digital wallets for executing the digital transaction based on a transaction amount, a transaction type, and a set of permission rules, the plurality of digital wallets comprising different digital wallets managed by the enterprise, each corporate wallet of the plurality of corporate digital wallets managing one or more respective accounts of the enterprise; and instructing the selected digital wallet to transfer the transaction amount to the counterparty account indicated by the transaction request.

82. 82. The method of claim 81, further comprising initiating a transaction monitoring workflow to monitor the results of the transaction in response to the selected digital wallet transferring the transaction amount to the counterparty account.

83. 82. The method of claim 81, wherein the business entity is an employee of the business.

84. determining whether the business entity has sufficient authorization to initiate the digital transaction, an enterprise entity data store storing a set of entity records, each entity record defining a set of attributes for each entity related to the enterprise, including the respective role of the respective entity within an organization; and determining the role of the enterprise entity within the enterprise based on the enterprise entity data store; 84. The method of claim 83, comprising: determining whether a business entity has sufficient authorization to initiate a digital transaction based on a business role and a set of permission rules, the set of permission rules including rules defining different types of digital transactions that are permitted to be performed on behalf of the business, and for each type of digital transaction, one or more roles of the business that have sufficient authorization to initiate the respective type of digital transaction.

85. The step of determining whether the business entity has sufficient authorization to initiate a digital transaction includes: determining a business unit within the enterprise to which the enterprise entity belongs based on an enterprise entity data store storing a set of entity records, each entity record defining a set of attributes for each entity associated with the enterprise, including the respective business unit of the respective entity; 84. The method of claim 83, comprising: determining whether the business entity has sufficient authorization to initiate the digital transaction based on a business unit of the business and a set of authorization rules, the set of authorization rules including rules defining different types of digital transactions that are authorized to be performed on behalf of the business, and for each type of digital transaction, one or more business units of the business that are authorized to initiate each type of digital transaction.

86. 82. The method of claim 81, wherein determining whether the business entity has sufficient authorization to initiate the digital transaction is further based on a transaction amount indicated by the transaction request.

87. 86. The method of claim 85, wherein the authorization rules define transaction thresholds for different types of entities within the enterprise, and a transaction request initiated by the respective entity requesting a transaction amount above the respective transaction triggers a request for approval from one or more other entities designated by the enterprise.

88. one or more processors verifying a digital signature corresponding to a response from a user equipment of the second business entity based on a public key associated with the second business entity, the digital signature being generated by the second user equipment using a private key associated with the second business entity; 82. The method of claim 81, further comprising: the one or more processors verifying the digital signature and determining that the digital transaction is approved in response to verifying that the response indicates that the second business entity approves the transaction.

89. selecting a digital wallet from the plurality of enterprise digital wallets includes determining a transaction rail for executing the digital transaction from among a plurality of potential transaction rails based on a transaction type defined in the transaction request; 82. The method of claim 81, wherein the step of selecting a digital wallet from a plurality of corporate digital wallets is further based on the determined transaction rail.

90. The step of selecting a digital wallet from a plurality of corporate digital wallets includes: determining, based on the transaction type, from the plurality of digital wallets, one or more compatible corporate digital wallets that can execute the transaction using the determined transaction rails; 90. The method of claim 89, further comprising: selecting a digital wallet from one or more compatible digital wallets based on the transaction amount and a set of permission rules.

91. memory hardware configured to store instructions; processor hardware configured to execute instructions from the memory hardware, the instructions comprising: receiving, by one or more processors, a transaction request requesting a digital transaction to be executed on behalf of the business entity, the request being received from a device corresponding to the business entity and indicating a transaction type of the digital transaction, a transaction amount, and an account identifier of a counterparty account to the transaction; determining, by the one or more processors, whether the business entity has sufficient authorization to initiate the digital transaction requested by the business entity based on the transaction type and a set of authorization rules defined by the business; In response to determining that a corporate entity does not have sufficient authorization to enter into a digital transaction, determining, by the one or more processors, a second business entity that can authorize the digital transaction based on a set of authorization rules defined by the business; sending, by the one or more processors, an authorization request to the user device of the second business entity, the authorization request requesting that the second business entity approve or deny the digital transaction; receiving, by the one or more processors, a response from the user device of the second business entity indicating whether the second business entity has authorized or denied the digital transaction; Preventing execution of the digital transaction in response to the second entity's denial of the digital transaction; and In response to determining that the business entity has sufficient authorization to initiate the digital transaction or that the second business entity has authorized the digital transmission, selecting a digital wallet from a plurality of corporate digital wallets for executing the digital transaction based on a transaction amount, a transaction type, and a set of permission rules, the plurality of digital wallets comprising different digital wallets managed by the enterprise, each corporate wallet of the plurality of corporate digital wallets managing one or more respective accounts of the enterprise; processor hardware, including instructing a selected digital wallet to transfer the transaction amount to a counterparty account indicated by the transaction request; A system including:

92. 92. The system of claim 91, further comprising initiating a transaction monitoring workflow to monitor the results of the transaction in response to the selected digital wallet transferring the transaction amount to the counterparty account.

93. 92. The system of claim 91, wherein the business entity is an employee of the business.

94. Determining whether a business entity has sufficient authorization to initiate a digital transaction includes: determining the role of an enterprise entity within the enterprise based on an enterprise entity data store storing a set of entity records, each entity record defining a set of attributes for each entity related to the enterprise, including the respective role of each entity within the organization; 94. The system of claim 93, comprising: determining whether a business entity has sufficient authorization to initiate a digital transaction based on a business role and a set of permission rules, the set of permission rules including rules defining different types of digital transactions that are permitted to be performed on behalf of the business, and for each type of digital transaction, one or more roles of the business that have sufficient authorization to initiate the respective type of digital transaction.

95. Determining whether a business entity has sufficient authorization to initiate a digital transaction is determining a business unit within the enterprise to which an enterprise entity belongs based on an enterprise entity data store storing a set of entity records, each entity record defining a set of attributes for each entity associated with the enterprise, including a respective business unit for the respective entity; 94. The system of claim 93, determining whether a business entity has sufficient authorization to initiate a digital transaction based on a business unit of the business and a set of authorization rules, the set of authorization rules including rules defining different types of digital transactions that are authorized to be performed on behalf of the business, and for each type of digital transaction, one or more business units of the business that are authorized to initiate each type of digital transaction.

96. 92. The system of claim 91, wherein the determination of whether the business entity has sufficient authorization to initiate the digital transaction is further based on a transaction amount indicated by the transaction request.

97. 96. The system of claim 95, wherein the authorization rules define transaction thresholds for different types of entities within the enterprise such that a transaction request initiated by the respective entity requesting a transaction amount above the respective transaction triggers a request for approval from one or more other entities designated by the enterprise.

98. verifying, by the one or more processors, a digital signature corresponding to the response from the user equipment of the second business entity based on a public key associated with the second business entity, the digital signature being generated by the second user equipment using a private key associated with the second business entity; 92. The system of claim 91, comprising determining, by the one or more processors, that the digital transaction is approved in response to verifying the digital signature and verifying that the response indicates that the second business entity approves the transaction.

99. receiving, by one or more processors, a transaction request requesting a digital transaction to be executed on behalf of the enterprise, the request being received from a device corresponding to an entity of the enterprise and indicating a transaction type, a transaction amount, and an identifier of a counterparty account for the digital transaction; determining, by the one or more processors, whether the entity of the enterprise has sufficient authority to initiate the requested digital transaction based on the transaction type and an enterprise-defined set of authorization rules; If a corporate entity is determined to not have sufficient authority to enter into a digital transaction, one or more processors determining second business entities that can approve the digital transaction based on a set of authorization rules defined by the business; The one or more processors send an authorization request to a user device of the second business entity. The authorization request asks the second business entity to approve or reject the digital transaction; receiving, by the one or more processors, a response from the user device of the second business entity indicating whether the digital transaction has been approved or rejected; Preventing the digital transaction from being executed if the second entity rejects the digital transaction; and If the business entity is determined to have sufficient authority to initiate the digital transaction, or if a second business entity approves the digital transaction, selecting one of a plurality of enterprise digital wallets based on the transaction amount, the transaction type, and the set of authorization rules to execute the digital transaction, the plurality of enterprise digital wallets being composed of different enterprise-managed digital wallets, each enterprise digital wallet managing one or more individual accounts of the enterprise; and instructing the selected digital wallet to transfer the transaction amount to the counterparty account indicated in the transaction request.

100. 100. The non-transitory computer-readable medium of claim 99, further comprising initiating a transaction monitoring workflow to monitor results of the transaction in response to the selected digital wallet transferring the transaction amount to the counterparty account.

101. monitoring, by a trading system executed by one or more processors, a data pool aggregating a plurality of compliance standards related to one or more types of digital transactions, the data pool maintaining a plurality of different compliance parameters representing different values ​​and requirements used to facilitate compliance with the plurality of compliance standards, one or more of the plurality of different compliance parameters being updated in response to one or more changes in the compliance standards; receiving, by a trading system, a request for a trade to be executed on behalf of the enterprise; executing, by the trading system, a trade compliance workflow for the trade request, wherein executing the trade compliance workflow includes: accessing, by the trading system, the data pool to obtain an updated set of compliance parameters corresponding to one or more compliance standards associated with the type of trade indicated in the trade request; parameterizing, by the trading system, the conditional logic defined in the compliance checklist with the updated set of compliance parameters; validating that the requested transaction complies with one or more compliance standards associated with the type of transaction requested based on conditional logic parameterized by the updated set of compliance parameters; and executing the digital transaction in response to verifying that the requested transaction complies with one or more compliance standards.

102. 102. The method of claim 101, wherein the compliance standard is a government regulatory standard and the compliance parameters are values ​​and requirements defined by a governing body.

103. 103. The method of claim 102, wherein the plurality of compliance standards include reporting requirements including a threshold for transactions requiring reporting volume, and the compliance parameters include a threshold defining the threshold.

104. 103. The method of claim 102, wherein the plurality of compliance criteria includes tax regulations and the compliance parameters include one or more tax rates that apply to different types of transactions.

105. 102. The method of claim 101, wherein the plurality of compliance standards are corporate standards and the plurality of compliance parameters are corporate defined values ​​and requirements.

106. 106. The method of claim 105, wherein the plurality of compliance standards includes transaction volume limits, and the plurality of compliance parameters includes, for a set of roles within an enterprise, a maximum transaction volume that can be executed in each transaction initiated by the enterprise entity of the respective role.

107. 106. The method of claim 105, wherein the plurality of compliance standards includes account access rules, and the plurality of compliance parameters includes a set of roles within an enterprise and, for each role, a set of enterprise accounts available for use in each transaction initiated by the enterprise entity of the respective role.

108. 106. The method of claim 105, wherein the plurality of compliance criteria includes accounts, and the plurality of compliance parameters includes a set of roles within an enterprise and, for each role, a maximum transaction volume that can be executed in each transaction initiated by the enterprise entity of the respective role.

109. 102. The method of claim 101, wherein the data pool is maintained by a company.

110. 102. The method of claim 101, wherein the data pool is maintained by a regulatory body.

111. memory hardware configured to store instructions; processor hardware configured to execute instructions from the memory hardware, the instructions comprising: monitoring, by a trading system executed by one or more processors, a data pool aggregating a plurality of compliance standards related to one or more types of digital transactions, the data pool maintaining a plurality of different compliance parameters representing different values ​​and requirements used to facilitate compliance with the plurality of compliance standards, one or more of the plurality of different compliance parameters being updated in response to changes in one or more of the compliance standards; receiving, by a trading system, a request for a trade to be executed on behalf of the enterprise; executing, by a trading system, a trade compliance workflow for the trade request, wherein executing the trade compliance workflow includes: accessing, by the trading system, the data pool to obtain an updated set of compliance parameters corresponding to one or more compliance standards associated with the type of trade indicated in the trade request; parameterizing, by the trading system, the conditional logic defined in the compliance checklist with the updated set of compliance parameters; Validating that the requested transaction complies with one or more compliance standards associated with the type of transaction requested based on conditional logic parameterized by the updated set of compliance parameters; and and processor hardware that executes the digital transaction in response to verifying that the requested transaction complies with one or more compliance standards. A system including:

112. 112. The system of claim 111, wherein the compliance standards are government regulatory standards and the compliance parameters are values ​​and requirements defined by a governing body.

113. 113. The system of claim 112, wherein the plurality of compliance standards include reporting requirements including a threshold for transactions requiring reporting volume, and the compliance parameters include a threshold defining the threshold.

114. 113. The system of claim 112, wherein the plurality of compliance criteria includes tax regulations and the compliance parameters include one or more tax rates that apply to different types of transactions.

115. 112. The system of claim 111, wherein the plurality of compliance standards are corporate standards and the plurality of compliance parameters are corporate-defined values ​​and requirements.

116. 116. The system of claim 115, wherein the plurality of compliance standards includes transaction volume limits, and the plurality of compliance parameters includes a set of roles within a company and, for each role, a maximum transaction volume that can be executed in each transaction initiated by the corporate entity of the respective role.

117. 116. The system of claim 115, wherein the plurality of compliance standards includes account access rules, and the plurality of compliance parameters includes a set of roles within an enterprise and, for each role, a set of enterprise accounts available for use in each transaction initiated by the enterprise entity of the respective role.

118. 116. The system of claim 115, wherein the plurality of compliance criteria includes accounts, and the plurality of compliance parameters includes a set of roles within an enterprise and, for each role, a maximum transaction volume that can be executed in each transaction initiated by the enterprise entity of the respective role.

119. monitoring, by a trading system executed by one or more processors, a data pool aggregating a plurality of compliance standards related to one or more types of digital transactions, the data pool maintaining a plurality of different compliance parameters representing different values ​​and requirements used to facilitate compliance with the plurality of compliance standards, one or more of the plurality of different compliance parameters being updated in response to one or more changes in the compliance standards; receiving, by a trading system, a request for a trade to be executed on behalf of the enterprise; and executing, by the trading system, a trade compliance workflow for the trade request, wherein executing the trade compliance workflow includes: accessing, by the trading system, the data pool to obtain an updated set of compliance parameters corresponding to one or more compliance standards associated with the type of trade indicated in the trade request; parameterizing, by the trading system, the conditional logic defined in the compliance checklist with the updated set of compliance parameters; Validating that the requested transaction complies with one or more compliance standards associated with the type of transaction requested based on conditional logic parameterized by the updated set of compliance parameters; and 12. A non-transitory computer-readable medium comprising instructions, including: executing a digital transaction in response to verifying that the requested transaction complies with one or more compliance standards.

120. running a trading platform; Implementing a market orchestration system; Implementing a market orchestration architecture platform; implementing a governance system; Implementing an intelligent data layer system; running a cross-market trading engine; Implementing a market forecasting system; running a quantum computing system; Running a trust network; Implementing a dual-process artificial neural network; running an information services system; Implementing generative AI systems; Implementing a graph data processing system; and 120. The non-transitory computer-readable medium of claim 119, further comprising instructions comprising: executing an enterprise access system.

121. maintaining a first data item machine learning model configured to output a first score in response to a first type of input data; maintaining a second data item machine learning model configured to output a second score in response to a second type of input data; and In response to receiving the first input data, selectively processing a first subset of the first input data; inputting a first subset of first input data into a first data item machine learning model to generate a first score; Selectively storing a first subset of the first input data and the first score; selectively processing a second subset of the first input data; inputting a second subset of the first input data into a second data item machine learning model to generate a second score; selectively saving a second subset of the first input data and the second scores; maintaining a data source machine learning model configured to output a source score in response to the source identifier; and In response to a data access request from a requester, Identifying a set of target data in response to a data access request; identifying a first source of a target dataset; determining a first source score based on the identifier of the first source; outputting a data access response to the requester; excluding the set of target data from the response in response to the first source score falling below an access threshold; and selectively including a set of target data in the response in response to the first source score exceeding an access threshold.

122. 122. The method of claim 121, further comprising inputting the identifier of the first source into a data source machine learning model to determine a first source score.

123. 122. The method of claim 121, further comprising determining the first source score by looking up a stored score previously generated by inputting an identifier of the first source into the data source machine learning model.

124. 122. The method of claim 121, further comprising determining an access threshold based on the identity of the requester.

125. 122. The method of claim 121, further comprising determining an access threshold based on a role of the requester.

126. The data access request specifies the use case, 122. The method of claim 121, further comprising determining an access threshold based on a use case.

127. Selectively processing a first subset of the first input data comprises: generating a first subset of the first input data by selecting data items of the first input data that match the first type; and In response to the first subset being non-empty, inputting a first subset of the first input data into a first data item machine learning model to generate a first score; and 122. The method of claim 121, comprising selectively storing the first subset of the first input data and the first score.

128. generating the first subset of the first input data includes: Selecting all data items of the first input data that match the first type; or 128. The method of claim 127, comprising at least one of: randomly selecting data items of the first input data that match the first type. The method of claim 121.

129. 122. The method of claim 121, wherein selectively storing the first subset of the first input data and the first score comprises: storing the first subset of the first input data and storing the first score in response to the first score satisfying a storage criterion; and discarding the first subset of the first input data in response to the first score not satisfying the storage criterion.

130. Meeting the storage criteria means: the first score exceeds a storage threshold; or 130. The method of claim 129, wherein the first score corresponds to one of a set of defined values ​​indicating reliability.

131. 122. The method of claim 121, wherein the identifier of the first source is a fully qualified domain name (FQDN) of a uniform resource locator (URL) at which the first source is at least one of hosted, accessed, or described.

132. memory hardware configured to store instructions; processor hardware configured to execute instructions from the memory hardware, the instructions comprising: maintaining a first data item machine learning model configured to output a first score in response to a first type of input data; maintaining a second data item machine learning model configured to output a second score in response to a second type of input data; In response to receiving the first input data, Selectively processing a first subset of first input data, generating a first score by inputting a first subset of first input data into a first data item machine learning model; selectively storing the first subset of the first input data and the first score; selectively processing a second subset of the first input data; generating a second score by inputting a second subset of the first input data into a second data item machine learning model; selectively storing a second subset of the first input data and a second score; maintaining a data source machine learning model configured to output a source score in response to a data access request from a requestor in response to the source identifier; and In response to a data access request from a requestor, identifying a set of target data; identifying a first source of a set of target data; determining a first source score based on the identifier of the first source; outputting a data access response to a request source, excluding the set of target data from the response in response to the first source score being less than the access threshold; processor hardware, responsive to the first source score exceeding an access threshold, selectively including the set of target data in a response; A system including:

133. 133. The system of claim 132, wherein the instructions include inputting an identifier of the first source into the data source machine learning model to determine the first source score.

134. 133. The system of claim 132, wherein the instructions include determining the first source score by searching for a stored score previously generated by inputting an identifier of the first source into the data source machine learning model.

135. 133. The system of claim 132, wherein the instructions include determining the access threshold based on an identity of the requester.

136. 133. The system of claim 132, wherein the instructions include determining the access threshold based on a role of the requester.

137. The data access request specifies the use case, 133. The system of claim 132, wherein the instructions further comprise determining an access threshold based on a use case.

138. 133. The system of claim 132, wherein selectively processing the first subset of the first input data comprises: generating the first subset of the first input data by selecting data items of the first input data that match the first type; generating the first score by inputting the first subset of the first input data to the first data item machine learning model in response to the first subset being non-empty; and selectively storing the first subset of the first input data and the first score.

139. maintaining a first data item machine learning model configured to output a first score for a first type of input data; maintaining a second data item machine learning model configured to output a second score for a second type of input data; Upon receiving the first input data, inputting a first subset of the first input data into a first data item machine learning model to generate a first score; and selectively storing a first subset of the first input data and the first score; Selectively processing a second subset of the first input data, specifically: inputting a second subset of the second input data into a second data item machine learning model to generate a second score; and selectively storing a second subset of the first input data and the second scores; maintaining a data source machine learning model configured to output a source score according to a source identifier; A function to execute the following processes when receiving a data access request from the requester: identifying a target dataset corresponding to a data access request; identifying a first source of the target dataset; determining a first source score based on an identifier of the first source; A function that outputs a data access response to the request source, specifically, excluding the target dataset from the response if the first source score is below the access threshold; and a function for selectively performing a process of selectively including the target dataset in the response if the first source score exceeds an access threshold; A non-transitory computer-readable medium containing instructions for:

140. 140. The non-transitory computer-readable medium of claim 139, wherein selectively storing the first subset of first input data and the first score comprises: storing the first subset of first input data and storing the first score in response to the first score satisfying a storage criterion; and discarding the first subset of first input data in response to the first score not satisfying the storage criterion.

Images