Evaluation and Payment Method of Parametric Risk Compensation for Insurance Difficulty Risks Using a Distributed Ledger and Related Systems

Abstract

A method for evaluating and paying claims for parametric risk compensation for difficult insurance risks using a distributed ledger system is provided to evaluate, manage, and pay claims for parametric risk compensation using a distributed ledger to reduce and / or eliminate human interaction and / or management. A system for facilitating evaluation and payment of parametric risk compensation for difficult insurance risks using a distributed ledger may include an insurance recommendation component, a machine learning model, a data validation and token generation component, a distributed ledger, a self-executing contract execution engine, a payment component, an incentivized token aspect, a marketplace component, and a social incentive component. Also provided is a method for evaluating, managing, and paying claims for parametric risk compensation using a distributed ledger system to reduce and / or eliminate human interaction and / or management by evaluating and paying claims for parametric risk compensation for difficult insurance risks using a distributed ledger system.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 241,558, filed on September 8, 2021, and to U.S. Non - Provisional Patent Application No. 17 / 903,887, filed on September 6, 2022. The foregoing applications are hereby incorporated by reference in their entirety.

[0002] The present disclosure relates to the evaluation and payment of parametric risk compensation for hard - to - insure risks (risks for which it is difficult to obtain insurance coverage, to participate in insurance, or to receive compensation under insurance) using data storage structures, such as distributed ledger technology, in order to reduce and / or eliminate manual operation and / or management. More specifically, the present disclosure relates to the evaluation, management, loss prediction and definition of parametric risk compensation, and insurance payment claims using a data storage structure such as a distributed ledger.

Background Art

[0003] Insurance exists to mitigate financial losses suffered due to a loss when an event related to an insured risk occurs. Traditional insurance contracts can be classified into several types (e.g., property damage, personal injury, health, life, and pensions, etc.), and may also be related to parametric risk indemnity insurance. Parametric risk indemnity insurance is based on the fulfillment of conditions defined by specific parameters. When such conditions are met, for example, when a trigger event occurs or when a financial loss defined within a threshold by the insurance contract occurs, payment can be automatically provided to the insured. However, both traditional insurance and parametric risk indemnity have long struggled to provide insurance to categories where the application of parametric risk indemnity is difficult, such as high-risk categories and consumer insurance. Furthermore, the management of parametric insurance lacked a substantially automated, immutable, and authenticated platform for managing such insurance. Additionally, it is not known to substantially automate at least some (but not all) of the processes for implementing insurance or parametric risk indemnity insurance that uses machine learning or artificial intelligence to provide insurance payments at the time of a risk event.

[0004] Traditional insurance is inefficient in its operation because it is increasingly difficult to insure the risks faced on a daily basis, ranging from infectious diseases and climate change to disruptions in utilities (infrastructure) and event cancellations. In fact, more than 70% of people do not feel that they have adequate compensation for these risks, and consumers in the United States are suffering damages of over $500 billion annually. Since most known solutions strongly focus on business-specific categories and weather-related risks, there is no known solution that utilizes a parametric platform. Furthermore, there are no known insurance or parametric risk compensation management products or methods that substantially automate benefit reduction by leveraging digital tokens that allow consumers to arbitrarily allocate a portion of the benefits obtained from insurance to social incentives. There is no known insurance or parametric risk compensation platform or method that can use digital tokens to compensate the operators of nodes that support the security of the distributed ledger that can be presented as an on-chain repository and the smart contracts stored by the distributed ledger. Additionally, there is no known system or method that facilitates derivative transactions based on tokens related to insurance (insurance contracts) classified by risk level and / or buckets of insurance (insurance contracts).

[0005] Therefore, it is necessary to solve the drawbacks existing in the prior art. What is needed is a system and method for evaluating and compensating insurance difficulty risks. What is needed is a method for analyzing insurance difficulty risks using machine learning to eliminate or reduce the need for human interaction. What is needed is a method for managing data related to insurance contracts, policyholders, and insurance claims using a data storage structure such as a distributed ledger provided, for example, via blockchain. What is needed is a method and system for substantially automatically managing insurance payments for parametric risk compensation claims through the use of self-executing contracts such as smart contracts. What is needed is a method and system for creating marketable tokens related to insurance contracts. What is needed is a method and system for promoting social incentives related to parametric risk compensation. What is needed is a method and system for trading tokens related to risk compensation in a virtual market. What is needed is a method and platform for managing parametric risk compensation using clear, transparent, and predictable conditions. Summary of the Invention

[0006] One aspect of the present disclosure advantageously provides a system and method for evaluating and compensating for insurance difficult risks. One aspect of the present disclosure advantageously provides a method for analyzing insurance difficult risks using machine learning to eliminate or reduce the need for human interaction. One aspect of the present disclosure advantageously provides a method for managing data related to insurance (insurance contracts), policyholders, and insurance claims using a data storage structure such as a distributed ledger that can be provided, for example, via a blockchain. One aspect of the present disclosure advantageously provides a method and system for substantially automatically managing insurance payments for parametric risk compensation claims through the use of self-executing contracts such as smart contracts. One aspect of the present disclosure advantageously provides a method and system for creating marketable tokens related to insurance contracts. One aspect of the present disclosure advantageously provides a method and system for promoting social incentives related to parametric risk compensation. One aspect of the present disclosure advantageously provides a method and system for trading tokens related to risk compensation and / or insurance in a virtual market. One aspect of the present disclosure advantageously provides a method and platform for managing parametric risk compensation using clear, highly transparent, and predictably executed conditions.

[0007] Accordingly, the present disclosure can be characterized by a method for managing parametric risk compensation insurance, the method being operable on a server that stores user information regarding a user in an electronic computer database.

[0008] The method can include obtaining a dataset via a computer communication network operably connected to a server via a network connection, where the dataset can include risk information related to compensable risks. The method can further include analyzing the dataset to model the likelihood of an insurance claim related to the risk and pricing an insurance claim related to the risk by determining a preliminary risk price for the risk based at least on the likelihood of the insurance claim and the cost for the insurance claim. The method can include defining a risk-related trigger that determines when a payment related to an insurance claim to which the trigger applies is made, where the trigger can be stored in a trigger catalog.

[0009] The method can include recommending insurance for the risk. This can further include displaying a survey regarding the risk for which insurance is requested on a user-remote-computing device. This can also further include comparing survey results from the survey with the risk information to determine whether it is compensable. For compensable risks, this can include adjusting the preliminary risk price to determine an insurance risk price and recommending insurance at the insurance risk price. In some embodiments, the method includes recommending compensation for a detected risk that may be related to the user based on the user's individual characteristics (e.g., the user has come to request insurance for interrupted utilities (infrastructure), but based on their geography, the system recommends considering climate change insurance for hurricane-related risks), and the compensation determined to be relevant to the user can be provided to the user without the user specifically requesting it.

[0010] The method may include establishing an insurance contract, which may further include receiving a selection by a user of the insurance contract via a computer communication network. For the insurance contract selected by the user, this may include recording the insurance contract in a distributed ledger and describing a smart contract that defines a trigger that causes an insurance claim for the insurance contract.

[0011] Furthermore, the method may include monitoring for the occurrence of a trigger defined by a self-executing contract such as a smart contract, and upon detecting the occurrence of the trigger, paying an insurance benefit. This may include substantially automatically executing the self-executing contract, substantially automatically disbursing funds for the paid insurance benefit to the user by the smart contract, and recording the payment in a data storage structure, such as a distributed ledger.

[0012] In another aspect, the data set may include a historical data set and a substantially real-time data set.

[0013] In another aspect, the method may further include normalizing at least a portion of the data set to facilitate a comparative analysis of risk information included in the normalized data set, and cleaning the data set to generate a schema that aids in the analysis of the data set.

[0014] In another aspect, the method may further include generating a data model using the schema and the data set via a machine learning model and / or a predictive analytics engine. The data set may include a historical data set and a substantially real-time data set. Further, the data model may include a risk pricing model.

[0015] In another aspect, the method may include validating a data model generated by a machine learning model and / or a predictive analytics engine, and using nodes to validate a data storage structure, such as at least insurance contracts and smart contracts recorded in a distributed ledger.

[0016] In another aspect, the method may include generating an incentivized token associated with an insurance contract and recordable in a data storage structure, such as a distributed ledger.

[0017] In another aspect, the method may include obtaining verification information about a user via a computer communication network. Using a trained machine learning model, the method may further include comparing user information provided by the user with the verification information to determine the likelihood of user verification.

[0018] In another aspect, the data storage structure may be or include a distributed ledger, the self-executing contract may be or include a smart contract, and at least the insurance contract and the smart contract are recorded and made immutable in the distributed ledger.

[0019] In another aspect, the method may include providing, via a market, a derivative transaction related to an insurance (insurance contract) and / or a bucket of insurances (insurance contracts) consisting of a plurality of insurances (insurance contracts). The bucket of insurances (insurance contracts) may be represented by a utility token tradable via the market. The activity of the traded utility token may be recorded in a data storage structure, such as a distributed ledger.

[0020] In another aspect, the method may include selectively providing a recipient payout from at least a portion of the paid insurance benefit when selected by the user as a social incentive. In this aspect, when an auto-executing contract for insurance benefit payment is executed with the recipient payout selected, at least a portion of the paid insurance benefit may be directed as the recipient payout. At least a portion of the remaining portion of the paid insurance benefit may be directed for payment of the insurance benefit to the user. In another aspect, the method may selectively distribute at least a portion of the profit and / or proceeds on the insurance premium paid by the user for risk compensation, e.g., but not limited to, substantially automatically paying a portion of the profit to a designated recipient if the operator of the method determines that a profit has been obtained by executing the method.

[0021] According to embodiments enabled by the present disclosure, a system for managing parametric risk compensation insurance is described. The system can include a server for storing user information regarding the user in an electronic computer database. The system can also include a network connection from the server to a computer communication network. The server can be configured to execute instructions.

[0022] The system may execute obtaining a dataset including risk information related to compensable risks via a computer communication network. The system can perform pricing of insurance benefit claims related to the risk by analyzing the dataset via the server, modeling the likelihood of an insurance benefit claim related to the risk, and determining a pre-risk price for the risk based on at least the likelihood of the insurance benefit claim and the cost for the insurance benefit claim. The system can execute defining a risk-related trigger that determines when a payment related to an insurance benefit claim to which the trigger applies is made.

[0023] The system can recommend insurance against risks. For example, the system can display a survey on the risks of the requested insurance on the user remote computing device, compare the survey results from the survey with the risk information to determine whether the risk is compensable, and for compensable risks, adjust the pre-risk price to determine the insurance risk price and recommend insurance at the insurance risk price.

[0024] The system can establish an insurance contract, including receiving the user's selection of insurance via a computer communication network, recording the insurance contract selected by the user in a data storage structure, and writing a self-executing contract for defining the trigger for insurance claims. The system can monitor the occurrence of the trigger defined by the self-executing contract, and when the occurrence of the trigger is detected, pay the insurance indemnity by substantially automatically executing the self-executing contract, substantially automatically pay the user the funds for the insurance indemnity defined by the self-executing contract, and record the insurance indemnity payment in the data storage structure to pay the insurance indemnity.

[0025] In another aspect, the dataset can include a historical dataset and a substantially real-time dataset.

[0026] In another aspect, at least a part of the dataset is normalized, which can facilitate the comparative analysis of the risk information included in the normalized dataset. Further, the dataset is cleaned, and a schema for assisting in the analysis of the dataset can be generated.

[0027] In another aspect, a machine learning model and / or a predictive analysis engine can be provided to generate a data model using the schema and the dataset. The dataset can include a historical dataset and a substantially real-time dataset. The data model can include a risk pricing model.

[0028] In another aspect, nodes may be provided for validating a data model generated by a machine learning model and / or a predictive analytics engine and for validating at least insurance contracts and self-executing contracts recorded in a data storage structure.

[0029] In another aspect, an incentive token may be generated and associated with an insurance contract recorded in a data storage structure.

[0030] In another aspect, a trigger catalog stored in an electronic computer database and accessible by a server may be provided for storing triggers.

[0031] In another aspect, the data storage structure may be or may include a distributed ledger, the self-executing contract may be or may include a smart contract, and at least the insurance contract and the smart contract are recorded in the distributed ledger and made immutable.

[0032] In another aspect, a market component may be included that provides derivative transactions related to an insurance (insurance contract) and / or a bucket of insurances (insurance contracts) consisting of multiple insurances (insurance contracts). The bucket of insurances (insurance contracts) may be represented by a utility token tradable via the market component. The activity of the utility token being traded may be recorded in the data storage structure.

[0033] In another aspect, a social incentive component can be provided that selectively makes recipient payouts from at least a portion of the payment insurance amount when selected by the user. In this aspect, the execution of the smart contract for payment in the state where the recipient payout is selected can instruct at least a portion of the payment insurance amount as the recipient payout, and can instruct at least a portion of the remaining portion of the payment insurance amount as the insurance payment to the user. In another aspect, a social incentive component can be provided that selectively provides a profit distribution from at least a portion of the profit, selectively instructs at least a portion of the profit distribution as a recipient payout defined by the user, and pays the remaining portion of the profit distribution to the user or retains it by the system operator.

[0034] The terms and expressions used throughout this disclosure should be construed broadly. The terms are intended to be understood according to the definitions provided herein. Technical dictionaries and the general meanings understood in the applicable technical field are intended to supplement these definitions. If an appropriate definition cannot be determined from this specification or a technical dictionary, such terms should be understood according to their plain and ordinary meaning. However, the definitions provided herein apply precedence over all other information sources.

[0035] The various objectives, features, aspects, and advantages described by this disclosure will become more apparent from the following detailed description, together with the accompanying drawings in which like numerals represent like components.

Brief Description of the Drawings

[0036]

Figure 1

[0037]

Figure 2

[0038]

Figure 3

[0039]

Figure 4

[0040]

Figure 5

[0041]

Figure 6

[0042]

Figure 7

[0043]

Figure 8

[0044]

Figure 9

[0045]

Figure 10

[0046]

Figure 11

DETAILED DESCRIPTION OF THE INVENTION

[0047] The following disclosure is provided to describe various embodiments related to the evaluation and payment of parametric risk compensation for insurance hardship risks using a data storage structure system. Those skilled in the art will understand further embodiments and uses of the present invention beyond the examples of the present disclosure. Terms included in the claims should be construed as defined within the present disclosure. Singular forms should be read to assume multiple options and disclose them. Similarly, plural forms should be read to assume singular options and disclose them. Conjunctions should be read as inclusive unless otherwise stated.

[0048] Expressions such as "at least one of A, B, and C" should be read to allow any of A, B, and C alone or in combination with the remaining elements. Further, such groups may include multiple instances of one or more elements within the group that may be included together with other elements of the group. All numerical values, measurements, and values are given as approximations unless explicitly stated otherwise.

[0049] For the purpose of clearly describing the components and features discussed through this disclosure, but not by way of limitation, some commonly used terms are defined. The term "parametric risk compensation", when used through this disclosure, is defined as a risk management product that executes payments based on the occurrence of a trigger or risk event, which may include events occurring in relation to risks and the detection that a trigger parameter has been met or exceeded. In some developments, the trigger may occur in a binary structure and operates when the trigger passes a threshold or affirmatively meets a condition set by a parameter. In some embodiments, multiple triggers may be defined, and each of the multiple triggers may need to be detected to initiate the payment of an insurance benefit under an insurance contract.

[0050] The term "insurance (insurance contract)", when used throughout this disclosure, is defined as the risk compensation provided to an insured and the conditions that define it. The term "insured", when used throughout this disclosure, is defined as a customer or other user who holds and / or takes steps to hold risk compensation insurance as provided by a method and system effective throughout this disclosure. The term "user", when used throughout this disclosure, is defined as an individual or entity that interacts with the methods and systems enabled by this disclosure, which includes the insured.

[0051] The term "data storage structure," as used throughout this disclosure, is defined as an aggregate of data organized to facilitate the storage, organization, modification, manipulation, transmission, and other interactions of the data stored by the data storage structure. In some embodiments, the data storage structure includes a distributed ledger, a localized database, a repository, a cloud-based platform, and / or additional data storage structures that will be understood by those skilled in the art. The term "distributed ledger," as used throughout this disclosure, is defined as a distributed, replicated, shared, and verified data structure that records information, transactions, rights, and other data in a substantially immutable form. A distributed ledger may be included as part of a blockchain, may be verified by nodes of computing devices on a network, and may be configured to operate without a central authority. A distributed ledger may be associated with a public blockchain and ledger, Ethereum, a private blockchain and ledger, Hyperledger, multiple ledgers, and / or other configurations that will be apparent to those skilled in the art. The use of alternative terms for a distributed ledger, such as blockchain, chain, on-chain repository, and other similar terms, may be used throughout this disclosure without limitation. The term "self-executing contract," as used throughout this disclosure, is defined as an agreement of conditions intended to be executed substantially automatically upon detection of a trigger and / or fulfillment of conditions related to the self-executing contract. The term "smart contract," as used throughout this disclosure, is defined as a self-executing contract that can be associated with a distributed ledger, and the conditions and triggers related to the smart contract can be recorded via the distributed ledger.

[0052] Here, various aspects of the present disclosure will be described in detail without limitation. The following disclosure describes the evaluation and payment of parametric risk compensation systems for insurability risks. One of ordinary skill in the art will understand that the evaluation and payment of parametric risk compensation systems for insurability risks can be alternatively expressed as parametric platforms for insurance claim-free compensation for insurability risks, substantially automated parametric risk compensation systems, risk compensation systems that use smart contracts to evaluate risks and use distributed ledgers to manage payments, machine learning parametric risk compensation platforms, the present invention, or other similar names. Similarly, one of ordinary skill in the art will understand that the methods for evaluating and paying parametric risk compensation for insurability risks can be alternatively expressed as methods for managing parametric compensation for insurance claims-free for insurability risks, methods for managing and operating insurance claims for risk compensation using machine learning and distributed ledgers, methods for determining risk compensation events and managing payments using smart contracts, methods, processes, the present invention, or other similar names. A skilled reader should not regard the inclusion of alternative expressions as limiting in any way.

[0053]

Example

[0054] Next, with reference to FIGS. 1 to 11, the evaluation and payment of parametric risk compensation for insurance difficulty risks using a data storage system, for example, a distributed ledger system, will be described in more detail. The evaluation and payment system for parametric risk compensation for insurance difficulty risks includes an insurance recommendation component, a machine learning engine, a data verification and token generation component, a self-executing contract, a payment component, an incentive token mode, a market component, a social incentive component, and additional components to be described in more detail below, and / or a server that can be communicably connected to the server. The evaluation and payment system for parametric risk compensation for insurance difficulty risks can operate interactively with one or more of these components, for example, using a data storage structure such as a distributed ledger, to evaluate, manage, and pay insurance claims related to parametric risk compensation in order to reduce and / or eliminate human operation and / or management.

[0055] In one example configuration, the system implemented by the present disclosure may include a server 110 communicably connected to other elements via a computer communication network 130. The server 110 includes various components, engines, modes, and other operations to facilitate the execution of instructions for providing functions to be described in more detail below, including machine learning modes, artificial intelligence, management of distributed ledgers and / or blockchains, and other operations that will become apparent through the present disclosure. Exemplary components and other features of the server 110 may include, but are not limited to, an insurance recommendation component 200, a data verification and token generation component 300, a payment component 400, an incentive token mode 500, a market component 180, a social incentive component 190, and / or other components and other features.

[0056] Database 120 exchanges data with server 110, stores data from server 110, and can be used to provide information that can be used in the operation of the methods and systems enabled by the present disclosure. In some embodiments, database 120 can be directly connected to server 110. In other embodiments, database 120 can be communicatively connected to server 110 via computer communication network 130. A plurality of databases 120 can be communicatively connected to server 110, such as, but not limited to, a history database, a real-time database, an ID database, and / or other database types that will become apparent to those skilled in the art after benefiting from the present disclosure.

[0057] Additional features can be communicatively connected to server 110 and / or database 120 via computer communication network 130. For example, external computer systems and data sources can use application programming interface (API) 150 to send and receive requests for information and return the requested information. Also, a distributed ledger or other data storage structure 160 can be communicatively connected to server 110 and / or other components via computer communication network 130. Further, user-remote-computing device 140 can be accessible by a user to interact with functions provided by server 110, data included by one or more databases 120, information accessible via API 150, and / or other information that can be related to the operation of the systems and methods implemented by the present disclosure. These features are described in more detail throughout the present disclosure.

[0058] Here, the insurance recommendation component will be described in more detail. FIGS. 1, 2, 7, and 8 highlight examples of the insurance recommendation component, which may also be shown in other figures. The insurance recommendation component 200 can assist in activities related to risk identification, risk pricing (pricing setting), trigger definition, matching of insurers and insurance contracts, insurance recommendation, and / or other activities related to the determination of insurance recommendations and the creation of insurance. The server 110 can request, receive, and / or provide information to one or more connected databases 120, for example, databases containing information on historical and / or substantially real-time content conditions. The historical dataset can be used in the operation of the insurance recommendation component 200 to identify risks, define triggers, and associate such risks and triggers with information provided by insurers and / or other users.

[0059] The exemplary insurance recommendation component 200 can assist in pricing the identified risks. The insurance recommendation component 200 can request information from the connected databases 120, such as a historical database and / or a substantially real-time database. The requested information can be analyzed by the server 110 to detect other information indicating trends, probabilities, and the occurrence of risk events, trigger fulfillment, and / or other conditions that may initiate an insurance claim resulting in the execution of a self-executing contract such as a smart contract related to insurance that may require payment to the insurer. In some embodiments, the analysis of the requested information by the server 110 can advantageously use artificial intelligence and / or machine learning tools. One or more of these analyses and predictions may be assisted by machine learning, which may be trained using past successful predictions, failed predictions, past trends, and / or other information indicating prior prediction accuracy and adjustments that may improve that accuracy.

[0060] To assist server 110 in identifying risks and pricing insurance accordingly, for example, as part of a request for responsive information, information can be transmitted from server 110 to one or more external databases 120. Such information can include the location of potential insurance applicants, past weather events related to such locations, trends in the prevalence of infectious diseases, the operating hours of utility (infrastructure) networks, and / or other information that would be apparent to those skilled in the art after benefiting from the present disclosure. The administrator of database 120 that receives the request can include information related to the request, and this information can be provided to server 110 in response to the request. The database administrator may provide information related to the parameters included in the data request, including details such as those provided in the above example. In some embodiments, establish a commercial relationship with the administrators of various databases 120 to permit information requests and provide the content of information that can be used for pricing identified risks and predicting whether a trigger related to such risks is likely to occur. At least a portion of this information can be used to determine the pre-risk price of future insurance contracts that may compensate insurance claims related to risk events associated with that information.

[0061] By way of example, not limitation, requests can be made to a distributed ledger or other data storage structure 160, such as one that uses distributed ledger technology (DLT), for information stored by the distributed ledger or other data storage structure 160. The data may be stored in a distributed ledger or other data storage structure 160 and may be verified by nodes to provide substantial immutability of such data and high resistance to tampering. The data may be encrypted by server 110, on database 120, on a distributed ledger or other data storage structure 160, and / or at other locations that would be understood by those skilled in the art. The data included on the distributed ledger or other data storage structure 160 may be stored in a zero-knowledge format and may benefit from homomorphic encryption that can be used when querying the encrypted data.

[0062] The analysis of the above information can be used to create a data model, such as a risk pricing model. Exemplary risk pricing models can include considerations based on the analysis of historical data, such as when a risk event will occur, where a risk event will occur, what types of risk events have occurred, trends, and / or other historical data that can indicate the likelihood of a risk event occurring, but are not limited thereto. Further, in at least some embodiments, substantially real-time data can be used to adjust the risk pricing model. In some embodiments, artificial intelligence and / or machine learning can assist in determining and creating the risk pricing model. For example, but not limited to, a feedback loop can be provided to the artificial intelligence and / or machine learning model to increase the price if the damage rate tends to be too high, decrease the price if the price model tends to be too profitable, and / or adjust the risk pricing model to reflect the trends and / or conditions detected through the feedback loop otherwise.

[0063] In some embodiments, referring to the risk pricing model can assist in determining the reserve amount of the insurance premiums paid to ensure the possibility of paying insurance benefits to the insurer when a trigger occurs. In some embodiments, the determination of a satisfactory reserve amount can be assisted by an artificial intelligence and / or machine learning model that can be trained by a feedback loop as illustrated by examples throughout this disclosure. In another embodiment, the prediction of an appropriate reinsurance contract can be determined by a similar analysis of the risk pricing model, the machine learning model, and / or other prediction operations described throughout this disclosure.

[0064] In some embodiments, the risk pricing model may be adjusted for the insurer and / or other users. At least a portion of the risk pricing model may be generalized for such aspects that may be related to, for example, a geographical location, which may be used to generate a pre-risk price for an insurance claim related to a category of compensable risks. The pre-risk price may provide a basis for pricing for an insurance type that may be adjusted to account for specific conditions related to the insurer or the risks being compensated. Adjustment of the objective pre-risk price may be used to generate an insurance risk price that can reflect the subjective price of the requested insurance contract. In some embodiments, at least a portion of the risk pricing model may be stored in a database 120 that is directly and / or communicably connected to the server 110 and accessible by the server 110.

[0065] The server 110 can further define a trigger that can use information from a historical dataset, a substantially real-time dataset, and / or other datasets to determine whether an event has occurred. The trigger may be related to a condition that, when satisfied, indicates that the requirements of the insurance contract are met and an insurance payment may be requested. The trigger may be mapped to identify the risks included in the insurance contract. The trigger may be stored in a database 120 that is directly and / or communicably connected to the server 110. Multiple triggers may be stored in a trigger catalog that may be stored in one or more databases 120. In another embodiment, the trigger and / or the trigger catalog may be stored at least partially on a distributed ledger or other data storage structure 160 and / or other data storage structures.

[0066] Here, without limitation, exemplary triggers will be described to illustrate some events that may lead to an insurance claim and / or payment of insurance benefits to the policyholder. In an example of insurance that compensates for contracting an infectious disease, the trigger may include a positive test result indicating infection with the disease to be compensated, disability due to a disease related to the disease to be compensated, a death certificate, medical records, a patient discharge notice, fulfillment of a prescription, and / or other similar information. In an example of insurance that compensates for a flood event, the trigger may include rainfall duration, rainfall intensity, water levels in neighboring rivers and other water bodies, elevation, postal code, distance from the coast, date of occurrence of the weather event, and / or other information related to the flood event. In an example related to interruption of a utility (infrastructure), the trigger may include downtime reported by the utility company, duration of the utility interruption, postal code, address of the utility service, reports from other utility customers, and / or other information that may be related to the utility interruption. In an example related to event cancellation insurance, the trigger may include weather phenomena, snowfall, date, time, duration, postal code, whether the event is held indoors or outdoors, cancellation of the event by the event organizer, type of the event, and / or other information that may be related to the event.

[0067] In some embodiments, multiple triggers may be defined, and each of the multiple triggers may need to be detected to initiate payment of insurance benefits. In some embodiments, when at least some, but not all, of the triggers are detected, a partial payment of insurance benefits may occur. Embodiments that include partial payments can provide such compensation as an addition to the insurance contract, for example, by adjusting the insurance premium to compensate for including partial payments in the insurance.

[0068] The insurance recommendation component 200 can include a survey that is shared with an insurer and / or other users to assist in determining a risk profile for the requested insurance. The survey can also refer to the claim history of existing and / or past insurance policyholders. For example, the server 110 can communicate a list of questions and requests for information related to the desired risk indemnity insurance to the insurer and / or other users. Such information can include the property to be indemnified, the location of such property, the claim history, the desired indemnity amount, the indemnity period, the desired premium, and / or other information that can help predict the insurance recommended for the insurer and / or other users. The insurer and / or other users can receive the survey on a user-remote-computing device 140 that can be communicatively connected to the server via a computer communication network 130.

[0069] Next, by way of non-limiting example, an exemplary survey will be described. The survey can include questions that can help predict the likelihood of a claim based on whether a trigger is likely to occur for a risk. Exemplary questions can include identification information, claim history, the location of the policyholder, the insurance amount, the ability to pay the premium, the size of the home, employment history, and / or other information that can facilitate determining the insurance that is most likely to suit the needs of the policyholder.

[0070] Information provided by an insurance provider, such as through a survey, may be compared by server 110 to information retrieved from one or more databases used to determine risk and / or pricing. Server 110 may, for example, determine the likelihood of an insurance claim being made due to the occurrence of a trigger event. In making the determination, server 110 may use machine learning to leverage past information and improve its predictive capabilities. Information related to past predictions can be used to train a machine learning model to improve the ability to match risk profiles, included triggers, and survey information, and predict the likelihood of an insurance claim occurring under an insurance contract. The pricing information of the risk pricing model may be adjusted as the machine learning model improves its predictive capabilities. Server 110 can use the risk pricing model, survey results, and / or other information to adjust an objective pre-risk price to an insurance risk price related to the subjective needs of the insurance provider and / or other users and the likelihood of an insurance claim being triggered.

[0071] After analyzing the information, server 110 can propose insurance to the insurance provider at an insurance risk price predicted to match the balance of risk-averse insurance providers, the ability to pay premiums, the likelihood of a trigger being met, and other factors that may contribute to matching the insurance provider with an insurance contract. Such a recommendation to the insurance provider may be stored in database 120, which may be directly and / or communicably connected to server 110 and may be accessible by the insurance recommendation component 200 of server 110 to assist in future predictions and / or training of machine learning models.

[0072] Next, referring to FIG. 2, and not by way of limitation, an exemplary insurance recommendation component will be described. In this exemplary insurance recommendation component, a data storage structure 262, such as a distributed ledger, may be provided to hold information related to an insurance policyholder, an insurance policy, and / or other aspects of insurable risks. The information may be stored using a distributed ledger, an on-chain repository, and / or other cloud platforms. The data included by the data storage structure 262, such as a distributed ledger, may be verified using nodes 268, which may be operated by a third party and / or other parties to provide computing resources that may be used to verify the contents of the data storage structure 262 in exchange for credit or other financial incentives. In another embodiment, at least a portion of the nodes 268 may be provided by an exclusive source and / or operator of the data storage structure 262, such as a distributed ledger.

[0073] One or more databases may be communicatively coupled to the data storage structure 262, such as a distributed ledger, and information may be provided to records held in the data storage structure 262 there through. Such databases may include a historical database 222, a substantially real-time database 224, and / or other databases that will be apparent to those skilled in the art after having the benefit of this disclosure. The data received by the data storage structure 262 may be subject to normalization and cleaning 218. Normalization may include adjusting the data to be consistent with other types of data so that comparative analysis can be done and correlations can be determined. The data may be organized into a table structure, for example, using an API, to facilitate consistent handling of data received through the database, and consistency independent of the source format can be ensured. Cleaning may include formatting the data to be presented in a consistent and readable format by other aspects of the system enabled by this disclosure. In some examples, a flag may be created and / or activated if an error is determined to have occurred in normalization, cleaning, or other handling of data and other information. The normalized and cleaned data may be communicated from the normalization and cleaning element 218 to the data storage structure 262, such as a distributed ledger, to be stored in its usable format.

[0074] The prediction analysis engine 210 can receive the normalized and cleaned data from the normalization and cleaning element 218 and perform prediction analysis thereon. The output from the prediction analysis engine 210 can be provided to a risk pricing model 212 that can predict a price that matches the risk profile provided by the prediction analysis engine 210. At least a portion of the normalized and cleaned data can be used to share information with the user, for example, via an analysis dashboard. Further, a trigger can be provided to the risk pricing model from a trigger catalog 214. The information within the risk pricing model 212 can be fed back to the prediction analysis engine 210 to improve the analysis of the data and predictions based on such analysis.

[0075] The risk insurance classifier and insurance recommender 234 can receive information from the risk pricing model 212, the user survey 232, and / or other information sources and classify and predict the insurance under analysis. The risk insurance classifier and insurance recommender 234 can use artificial intelligence and / or machine learning to assist in classification and insurance recommendations. At least a portion of the questions provided to the insurance applicant via the user survey 232 can be provided and / or proposed by the risk insurance classifier and insurance recommender 234. When the risk insurance classifier and insurance recommender 234 finishes classifying the insurance and prepares a recommendation, an insurance 258 can be prepared and recommended to the insurance applicant. The insurance applicant can accept the recommendation or select a different insurance configuration. Thereafter, the insurance contract selected by the insurance applicant is stored by a data storage structure 262, and a self-executing contract for the insurance contract is created. For example, the insurance contract selected by the insurance applicant can be stored via a distributed ledger, and a smart contract for the insurance contract can be written.

[0076] Next, the data verification and token generation components will be described in more detail. FIGS. 1-4 and FIGS. 6-9 highlight examples of data verification and token generation components, which may also be shown in other figures. Information provided by a user may need to be verified before being used for purposes of risk pricing, authentication, and insurance creation. Information related to an insurer may be analyzed by an aspect of server 110, such as a verification date and token generation component 300, to determine the likelihood that the identity of the insurer and / or other user requesting insurance is verified. The verified information related to the insurer and / or other user may be held in an insurer ID token, which may be established by an operation of server 110 that executes in a manner enabled by this disclosure. Insurer information may be verified using one or more data sources, such as a self-sovereign identity registry, a government database, a commercial database, public information, personal information, and / or other sources that may include information indicating the identity of the user. In some embodiments, users with a likelihood of verification indicating that their identity cannot be verified may be denied coverage.

[0077] In one embodiment, a self-sovereign identity associated with an insurer can be used to verify information related to the insurer. For example, information related to the insurer and / or other user can be stored in a data location, such as a distributed ledger or other data storage structure 160, that can be used to verify information related to that user without requiring that user to disclose more information than necessary about themselves. For example, the verification may ask whether the prospective insurer is within an age group of 35 years or older. Using a self-sovereign identity verification check, the verification result can return an affirmative answer without disclosing the actual age of the prospective insurer. Similar checks can also be performed for credit ratings, income, past insurance claims, and other information that may be related to risk pricing, insurability, and insurance contract recommendation conditions.

[0078] In another example, the information can be obtained from one or more data sources that may include information related to the user being verified. For example, a public database may include information related to the purchase of real estate that may be subject to risk compensation insurance, address, location, age, relationships, and other information that can be publicly shared. In another example, a government database may be used to provide information regarding marriage licenses, certificate records, assigned credentials, professional licenses, tax filings, criminal records, and / or other information that can be obtained from the government database. In a further example, the information can be provided from private data sources such that the information can be supplied from utility services, data brokers, private enterprises, and / or other data sources that access may be permitted to obtain such information. In some cases, a relationship may be established with a utility provider and / or other data source that permits access to information regarding the insurer and / or other users. In some examples, consent may be required and / or may be requested before data is obtained from connected data sources. At least a portion of the obtained data can be cached in a local database and / or other data storage that can be directly and / or communicatively connected to the server 100, such as via the computer communication network 130.

[0079] The insurer can use a digital identity wallet to hold verification information related to its users. The insurer can scan identity documents and / or credentials, such as professional licenses, identity ID cards, passports, and / or other information associated with the insurer. Requests to external sources for information that can be used to verify the identity of the insurer can be requested via an API, and the receipt of such information can be in response to such API requests. A machine learning model can be applied to assist in correlating information provided by the insurer with information obtained from external sources and can assist in verifying the authenticity of the insurer and / or the contents of the insurer's digital identity wallet.

[0080] When it is verified that the identity of the insurance policyholder is valid, a token representing the insurance policyholder can be generated. The token can be digitally stored in a distributed ledger or other data storage structure 160, from which other aspects of the system enabled by the present disclosure can obtain information provided through the token and use the information associated with the token to perform operations in a substantially automated manner.

[0081] The insurance policyholder can hold a copy of their digital insurance policyholder token on their user-remote-computing device 140 and / or another device. A copy of the insurance policyholder token can further be stored in a distributed ledger or other data storage structure 160, providing a substantially immutable record of the information associated with the token. The validity of the token and / or the data represented by the token may be verified by one or more nodes, and the nodes may exchange computing resources and / or other verification resources for the issuance of derivatives such as tradable and / or other marketable tokens that can be exchanged by the node operators for financial gain. In some embodiments, one or more tokens may be traded on a market platform, which will be described in more detail below.

[0082] After insurance is selected by the insurance policyholder and / or other user and the information related to that user is verified, a smart contract can be written to establish the terms of the insurance contract, the triggers related to the insurance contract, and the insurance payments related to the insurance contract. Additional information such as the insurance policyholder digital ID token, past risk data, price setting data, payment data, substantially real-time risk data, additional trigger definitions, local identification numbers that can be used by the server to identify the user, and / or other information that can affect the establishment and execution of the smart contract related to the insurance contract may be included in the smart contract.

[0083] In one embodiment, the smart contract may be substantially automated in its creation and execution. For example, the server 110 can use the information provided in at least a portion of the above-described operations to create an insurance contract and associate it with the insured. This insurance contract may be written to a distributed ledger or other data storage structure 160 to manage the smart contract or other self-executing contract. The conditions of the smart contract or other self-executing contract can be verified and validated through the operation of nodes associated with the distributed ledger or other data storage structure 160 and thus can be substantially immutable. The triggers associated with the insurance contract may be included by the self-executing contract, such that upon detection of such a trigger, the smart contract is executed substantially automatically to provide the insured with a payment insurance benefit.

[0084] The insured can bind themselves to the smart contract and thus to the insurance contract managed by the smart contract by accepting and / or signing the smart contract or other self-executing contract. For example, the insured can sign using a private key associated with the insured's digital ID token. In another example, the insured may use biometric information to verify the signature and acceptance of the smart contract or other self-executing contract. Examples of biometric information can include fingerprints, retinal scans, face detection, voice detection, and / or other indications of biometric match with the insured.

[0085] Next, referring to FIG. 3, exemplary data verification and token generation components will be described without limitation. Identification information regarding the insurance provider and / or other users can be requested from the ID database 326 via the API 350. The response to the API request can be provided by the ID database 326 via the API 350. Additionally, ID input 336 entered by the user, such as what can be received by the user who completes the survey, can be provided via the API 350. The information provided by the ID input 336 entered by the user can be associated with the identity of the insurance provider and / or other users via the ID token 342.

[0086] The information obtained via the API 350 may be used to generate and / or supplement the self-executing contract 366, which may be written to a data storage structure 362, such as, but not limited to, a distributed ledger. The node 368 can verify and validate the information included by the self-executing contract 366 and / or the distributed ledger or other data storage structure 362. For example, the node 368 can receive information from the distributed ledger or other data storage structure 362, execute calculations to verify the data, and report the validation to the distributed ledger or other data storage structure 362. When the node 368 detects a change in the data stored by the distributed ledger or other data storage structure 362 indicating a trigger, the node 368 can indicate to the self-executing contract 366 that an insurance claim has occurred and that the payable insurance benefit should be paid. The insurance information 358 can be provided to the self-executing contract 366 such that it can be generated in the operations described with the insurance recommendation component. The output from the self-executing contract 366, such as an insurance benefit payment event, can be associated with the insurance provider ID token 342, and such events may be written to the distributed ledger or other data storage structure 362.

[0087] Next, the payment component will be described in more detail. Figures 1, 4, 7, and 10, 11 highlight examples of the payment component, which may also be shown in other figures. The payment component 400 can monitor substantially real-time risk data provided by a substantially real-time database and / or other sources to determine whether a trigger has occurred and thus whether payment is required according to the insurance contract. When a trigger that requires payment is detected, a smart contract or other self-executing contract associated with the insurance contract can be substantially automatically executed, and funds for payment can be provided to the insured according to the conditions of the insurance contract. Records of insurance payments may be maintained by at least a portion of the server 110, which can be used for future pricing and / or training of machine learning models.

[0088] In one embodiment, the payment component 400 can refer to real-time risk data that can be obtained from a substantially real-time database. The real-time data can include the current operating status of the utility, the prevalence of infectious diseases in the community, current weather phenomena, ongoing disruptions to transportation and / or event admissions, and / or other information related to triggers associated with the insurance contract. The payment component 400 of the server 110 enabled by the present disclosure can perform an analysis on the real-time risk data, and this analysis can include operating a machine learning model to improve the prediction of the match between the occurring triggers and the payment events associated with the insurance contract. The information used to detect the occurrence of a trigger can be identified, anonymized, or otherwise modified to protect the identity and privacy of the insured.

[0089] The partnership can be entered into to access data from private or proprietary databases, such as databases provided by utility service providers and other such databases, as would be understood by one of ordinary skill in the art after having the benefit of the present disclosure. Information related to the trigger can be stored in a distributed ledger or other data storage structure 160 that can be used to determine whether a trigger event has occurred that requires the execution of a smart contract and the payment of funds from an insurance contract. In this example, the information included by the distributed ledger or other data storage structure 160 can be verified by nodes associated with the distributed ledger or other data storage structure 160, among others.

[0090] If it is determined that the trigger has occurred, the payment component 400 of the server 110 can align at least a portion of the substantially real-time data with a smart contract associated with the insurance contract. This alignment between the occurrence of the trigger and the smart contract or other self-executing contract may be assisted by the operation of a machine learning model. Thereafter, the smart contract or other self-executing contract can be executed to initiate an insurance payment process to provide funds to the policyholder in response to the occurrence of the trigger event. The payment can be processed directly through the server 110, by use of a third-party payment processor, by connection to a processor accessible via an API connection 150, by issuance of a derivative such as a marketable token and / or cryptocurrency, by funding of a digital wallet, by distribution to a charity or other recipient designated by the policyholder, and / or by other payment distribution techniques that would be understood by one of ordinary skill in the art after having the benefit of the present disclosure.

[0091] Here, with reference to FIG. 4, an exemplary payment component will be described without limitation. The payment component may interact with a self-executing contract 466, such as a smart contract, to detect conditions indicating a payment event, detect a trigger, and assist in the payment of payment funds to an insurer and / or other designated recipient. The self-executing contract 466 can receive information that can be used to determine whether the self-executing contract 466 should be executed, and a smart contract can be used for this. For example, the self-executing contract 466 can receive information related to the insurer or user ID token 442, information included by the data storage structure 462 that can be provided by the distributed ledger, payment conditions 472 for indicating which portion of the funds should be paid to the insurer and / or other recipient, and information related to the insurance 458. Those skilled in the art will understand that additional information sources can be provided to the self-executing contract 466 without limitation. The information considered by the self-executing contract 466 can be verified by the node 468. At execution time, the self-executing contract 466 may cooperate with the payment system 470 to process the payment of the insurance payment to the insurer and / or other recipient. The payment system 470 can facilitate the payment of the insurance payment 474 to the insurer and / or other recipient.

[0092] Next, the mode of the incentive token will be described in more detail. FIGS. 1, 5, and FIGS. 10 and 11 highlight examples of the mode of the incentive token and can also be shown in other figures. Verification of information held by the distributed ledger or other data storage structure 160 can be assisted by the operation of nodes for analyzing and verifying the additions and changes made to the distributed ledger or other data storage structure 160. Nodes can be attracted to the platform along with their computing resources by the deployment of incentive tokens and / or other incentives that would be understood by those skilled in the art. An exemplary incentive token can include a type of cryptocurrency distributed to the operator of the node in exchange for resources for verifying and validating the information included by the distributed ledger or other data storage structure 160. In some embodiments, the distribution of the incentive token can be managed and executed using a smart contract or other self-executing contract. In some embodiments, the token can be used as proof of insurance purchase and can be distributed to the wallet of the insurance policyholder. The incentive token can further be used in some examples to allocate at least a portion of the insurance payout related to the insurance as a recipient payout to recipients such as charities and other organizations.

[0093] Next, the market component will be described in more detail. FIGS. 1, 5, and FIG. 10 highlight examples of the market component and may also be shown in other figures. The market component 180 can provide a platform for insurance policyholders, users, nodes, and / or other parties to purchase, sell, trade, or otherwise transact tokens related to the systems enabled by the present disclosure and the methods of their operation. The tokens can be associated with individual insurances (insurance contracts), buckets of insurances (insurance contracts), payment predictions, risks, and other processable aspects related to insurance policyholders, insurance contracts, or other aspects of insurable risks.

[0094] An insurance contract holder and tokens related to the insurance contract can include de-identified and anonymized information such that the insurance contract holder cannot be identified by such an insurance contract holder and / or by trading tokens related to such an insurance contract. Information related to token ownership and transactions can be stored in a distributed ledger or other data storage structure 160. Tokens can be minted, distributed, processed, purchased, sold, or otherwise transacted in units of whole tokens, fractional tokens, decimal tokens, divisible tokens, and / or other allocations of token amounts that may be available in the market. Such transactions can be verified by nodes associated with the distributed ledger or other data storage structure 160, and the tokens can be provided to operators of such nodes in exchange for computational resources and other efforts to verify the content of the distributed ledger.

[0095] Referring now to FIG. 5, exemplary incentivization and market components will be described without limitation. An asset tokenization platform 580 can generate derivatives such as tradable and / or marketable tokens that can be associated with an insurance contract, an insurance contract holder, a risk, and / or other aspects related to an insurance product or a risk indemnification product. The asset tokenization platform 580 can generate cryptographic tokens 576 that can be stored in an insurance contract holder wallet 578. The cryptographic tokens 576 can be verified using self-executing contracts 566 such as smart contracts, data storage structures 562 that can be recorded in a distributed ledger, and / or nodes 568 that can communicate with other information sources consistent with the scope and spirit of the present disclosure. Examples of self-executing contracts 566, data storage structures 562, and nodes 568 are described in more detail throughout the present disclosure.

[0096] The cryptographic tokens 576 held in the insurer wallet 578 can be distributed to the insurer-directed benefit distribution 590, which may specify the insurer, the recipient, or other parties that would be apparent to one of ordinary skill in the art after receiving the benefits of this disclosure. The benefit distribution can include a portion of the benefits obtained from the premiums generated when the user purchases insurance using a method or system enabled by this disclosure. In this example, when benefits are obtained, a portion of those benefits can optionally be paid to one or more insurers and / or recipients designated by the insurer. The contents of the insurer wallet 578 may be directed to the cryptocurrency exchange 584. The node 568 can communicate with the cryptocurrency exchange 584 to receive and verify the information held by the cryptocurrency exchange 584.

[0097] The content provided to the cryptocurrency exchange 584 can be traded via the market 582 and viewed and / or traded by the trader 586. In at least one embodiment, the trader 586 can also trade directly through the cryptocurrency exchange 584. The market 582 may further receive buckets 556 of insurance (insurance contracts) or other risk pools, which may be tradable with the trader 586 via the cryptocurrency exchange 584. The buckets 556 of insurance (insurance contracts) or other risk pools can be defined using content from the risk pricing model 512, which can be defined via the predictive analytics engine 510 described in other examples throughout this disclosure. In some embodiments, insurers and / or insurance contracts may be grouped into cohorts, which may be at least partially included in one or more of the buckets 556 of insurance (insurance contracts) or other risk pools. Users, third parties, traders 586, and others can interact with the market 582 to trade tokens from the insurer wallet 578 via the cryptocurrency exchange 584, buckets 556 of insurance (insurance contracts) or other risk pools, and / or other financial products compatible with the market 582.

[0098] In some embodiments, insurance contract buckets may be classified by level of riskiness. Market-based payments may be based on execution of a smart contract, non-execution of a smart contract, expiration of an insurance contract, occurrence of a risk event, non-occurrence of a risk event, detection of a trigger, non-detection of a trigger, and / or other variables that would be understood by one of ordinary skill in the art after obtaining the benefits of this disclosure. Market participation may include positions taken by traders and / or other participants that are time-limited with respect to whether market conditions are met. In some embodiments, financial products may be offered through the market that enable market participants to bet on results, conditions, triggers, risks, time frames, and / or other metrics that may be measured via the methods and systems enabled by this disclosure.

[0099] Next, the social incentive component will be described in more detail. FIGS. 1 and 6 highlight an example of the social incentive component 190, which may also be shown in other figures. A social incentive may be provided to an insurer to provide at least a portion of the insurance payout to a designated recipient. In another embodiment, the social incentive component 190 may provide a profit distribution that pays a portion of the profit obtained from the insurance premiums generated to one or more insurers and / or recipients designated by the insurer. In one example, the recipient may include a charity or other charitable organization. In another example, the designated recipient may include a dependent family member, child, family, or other person designated to receive a portion of the insurance payout as a recipient payout. One of ordinary skill in the art will understand additional types of recipients that may be intended to receive at least a portion of the insurance payout as a social incentive, which are intended to be included within the scope and spirit of this disclosure. The inclusion of a social incentive may be written to a distributed ledger or other data storage structure 160 by the social incentive component 190, which may be associated with the insurance and / or smart contract of the insurer.

[0100] When social incentives are included and a trigger to initiate an insurance payment from an insurance contract is detected, the self-executing contract can be executed to distribute at least a portion of the paid insurance benefits to a designated recipient. The policyholder can specify a portion of the paid insurance benefits received by the recipient at the time of formation of the insurance contract, at the time of creation of the self-executing contract, after the formation of the insurance contract by amendment of the self-executing contract, or at other times consistent with the scope and spirit of this disclosure. If a portion of the paid insurance benefits is paid to the recipient, the remainder of the paid insurance benefits can be designated for payment to the policyholder. In some embodiments, when the paid insurance benefits are initiated, multiple recipients may be designated to receive a portion of the paid insurance benefits. In some embodiments, a portion of the profit can be substantially automatically distributed as a dividend of the profit to a third party and / or the policyholder. If the policyholder chooses to allocate a portion of the profit from the insurance premium paid to a selected third party and an appropriate profitability threshold is met by the system operator, the proceeds of the amount designated as a dividend of the profit can be automatically paid to the selected third party in accordance with the insurance contract conditions that may be defined by the self-executing contract. The surplus undistributed profit or the profit for which the policyholder did not choose a dividend can be retained without making a dividend payment.

[0101] In at least one embodiment, at least a portion of the methods and systems realized by the present disclosure may be provided through an intermediary party. In this embodiment, the form of the interface that can be displayed on the user computer device may include the branding provided by the intermediary party. Examples of intermediary parties can include, but are not limited to, licensees, contractors, subcontractors, traditional insurance providers, "white label" providers, and other parties that will become apparent to those skilled in the art after obtaining the benefits of the present disclosure. In some arrangements, at least a portion of the server and / or database is remotely operated and managed by the administrator of the platform. In other arrangements, at least a portion of the server on which the method can be operated may be installed locally at the location of the intermediary party. Those skilled in the art will understand additional arrangement configurations that are consistent with the scope and spirit of the present disclosure, but these are intended to be included in the present disclosure without limitation.

[0102] In one embodiment, an insurance policyholder and / or other user can view, monitor, and interact with their insurance account through a dashboard accessible via the user computer device. Insurance-related information can be provided to the insurance policyholder and / or other user, which may vary based on the type of compensation. For example, information related to interrupted utilities can include, but is not limited to, insurance number, city, county, state, utility provider, service status, start date, end date, number of times tracked, number of stops, duration, reason for stop, and / or other information. Those skilled in the art will understand additional information related to other types of compensation that are accessible to the insurance policyholder and / or other user via the dashboard after receiving the benefits of the present disclosure. The information accessible via the dashboard may further be used for analysis, for example, by being included in a feedback loop. Status reports, status maps, account details, special offers, social contributions, other reporting metrics, support options, help documents, payment details, and / or other information may be provided to the insurance policyholder and / or other user via the dashboard, for example.

[0103] In some embodiments, insurance claims may be optionally self-reported by the policyholder. In these embodiments, self-reporting may be provided to enable the review of insurance claims for events not detected by a trigger. If a sufficient number of self-reported incidents are received, supplemental measures may be initiated. For example, without limitation, multiple households in a common zip code may self-report a utility power outage. When a sufficient number of self-reported incidents are received, an adjuster and / or investigator may determine whether a risk event occurred despite the trigger not being detected, determine a loss based on the risk event, determine a correlation between the actual utility power outage and the reporting of such an outage, and / or may be assigned to facilitate the accurate payment of insurance benefit funds if a qualifying event occurred.

[0104] Referring now to FIG. 6, and not by way of limitation, an exemplary computerized device will be described. The various aspects and functions described in accordance with the present disclosure may be implemented as hardware or software on one or more exemplary computerized devices 600 or other computerized devices. There are many examples of currently used exemplary computerized devices 600 that may be suitable for implementing the various aspects of the present disclosure. Some examples include, among others, network appliances, personal computers, workstations, mainframes, network clients, servers, media servers, application servers, database servers, and web servers. Other examples of exemplary computerized devices 600 may include mobile computing devices, cellular phones, smartphones, tablets, video game devices, personal digital assistants, network devices, such as handheld scanners, magnetic stripe readers, barcode scanners, and commercial involved devices such as POS devices and systems and their related exemplary computerized devices 600. Further, aspects in accordance with the present disclosure may be disposed on a single exemplary computerized device 600 or may be distributed among one or more exemplary computerized devices 600 connected to one or more communication networks.

[0105] For example, various aspects and functions may be distributed among one or more exemplary computerized devices 600 configured to provide services to one or more client computers or to perform overall tasks as part of a distributed system. Further, aspects may be implemented on a client-server system or a multi-layer system that includes components distributed among one or more server systems that perform various functions. Thus, the present disclosure is not limited to execution on a particular system or group of systems. Further, aspects may be implemented in software, hardware, firmware, or any combination thereof. Thus, aspects in accordance with the present disclosure may be implemented in ways, acts, systems, system elements, and components that use various hardware and software configurations, and the present disclosure is not limited to a particular distributed architecture, network, or communication protocol.

[0106] FIG. 6 is a block diagram of an exemplary computerized device 600 in which various aspects and functions in accordance with the present disclosure may be practiced. The exemplary computerized device 600 may include one or more exemplary computerized devices 600. The exemplary computerized devices 600 included by the exemplary computerized device may be interconnected by a communication network 608 and may exchange data via the communication network 608. Data may be communicated via the exemplary computerized devices using wireless and / or wired network connections.

[0107] Network 608 can include any communication network through which exemplary computerized device 600 can exchange data. To exchange data via network 608, the system and / or components of exemplary computerized device 600 and network 608 may use various methods, protocols, and standards including, but not limited to, Ethernet®, Wi-Fi®, Bluetooth®, TCP / IP, UDP, HTTP, FTP, SNMP, SMS, MMS, SS7, JSON, XML, REST, SOAP, RMI, DCOM, and / or web services. To ensure that data transfer is secure, the system and / or modules of exemplary computerized device 600 can transfer data via network 608 using various security means including TSL, SSL, or VPN among other security technologies. Exemplary computerized device 600 may include any number of exemplary computerized devices 600 and / or components, which may be networked using virtually any medium and communication protocol or combination of protocols.

[0108] Various aspects and functions in accordance with the present disclosure may be implemented as dedicated hardware or software executed in one or more exemplary computerized devices 600, including the exemplary computerized device 600 shown in FIG. 6. As shown, the exemplary computerized device 600 may include a processor 610, a memory 612, a bus 614 or other internal communication system, an input / output (I / O) interface 616, a storage system 618, and / or a network communication device 620. Additional devices 622 may be selectively connected to the computerized device via the bus 614. The processor 610 can include one or more microprocessors or other types of controllers and can execute a series of instructions that result in processed data. The processor 610 may be a commercially available processor such as an ARM, x86, Intel Core, Intel Pentium, Motorola PowerPC, SGI MIPS, Sun UltraSPARC, or Hewlett-Packard PA-RISC processor, but any type of processor or controller may be used since many other processors and controllers are available. As shown, the processor 610 may be connected by the bus 614 to other system elements including the memory 612.

[0109] The exemplary computerized device 600 may also include a network communication device 620. The network communication device 620 may receive data from other components of the computerized device so as to communicate with a server 632, a database 634, a smartphone 636, and / or another computerized device 638 via a network 608. The communication of data may optionally be performed wirelessly. More specifically, without limitation, the network communication device 620 may communicate and relay information from one or more components of the exemplary computerized device 600, or from other devices and / or components connected to the computerized device 600, to additional connected devices 632, 634, 636, and / or 638. The connected devices are intended to include, without limitation, data servers, additional computerized devices, mobile computing devices, smartphones, tablet computers, and other electronic devices capable of digital communication with another device. In one example, the exemplary computerized device 600 may be used as a server for analyzing and communicating data between connected devices.

[0110] The exemplary computerized device 600 can communicate with one or more connected devices via a communication network 608. The computerized device 600 can communicate via the network 608 by using its network communication device 620. More specifically, the network communication device 620 of the computerized device 600 can communicate with the network communication device or network controller of a connected device. The network 608 can be, for example, the Internet. As another example, the network 608 can be a WLAN. However, those skilled in the art will understand additional networks included within the scope of the present disclosure, such as intranets, local area networks, wide area networks, peer-to-peer networks, and various other network types. Further, the exemplary computerized device 600 and / or the connected devices 632, 634, 636, and / or 638 can communicate on the network 608 via wired, wireless, or other connections without limitation.

[0111] The memory 612 can be used to store programs and / or data during the operation of the exemplary computerized device 600. Thus, the memory 612 can be a relatively high-performance, volatile, random-access memory such as dynamic random access memory (DRAM) or static memory (SRAM). However, the memory 612 can include any device for storing data, such as a disk drive or other non-volatile storage device. Various embodiments in accordance with the present disclosure can organize the memory 612 into a specified, and in some cases unique, structure to perform aspects and functions of the present disclosure.

[0112] The components of the exemplary computerized device 600 can be coupled by an interconnect element such as a bus 614. The bus 614 can include one or more physical buses (e.g., a bus between components integrated within the same machine), but can include any communication coupling between system elements including special or standard computing bus technologies such as USB, Thunderbolt, SATA, FireWire, IDE, SCSI, PCI, and InfiniBand. Thus, the bus 614 can enable the exchange of communication (e.g., data and instructions) between the system components of the exemplary computerized device 600.

[0113] The exemplary computerized device 600 can also include one or more interface devices 616 such as input devices, output devices, and combination input / output devices. The interface device 616 can receive input or provide output. More specifically, the output device can render information for external presentation. The input device can receive information from an external source. Examples of interface devices include, among others, a keyboard, barcode scanner, mouse device, trackball, magnetic stripe reader, microphone, touch screen, printing device, display screen, speaker, network interface card, and the like. The interface device 616 enables the exemplary computerized device 600 to exchange and communicate information with external entities such as users and other systems.

[0114] The storage system 618 may include a computer-readable and writable non-volatile storage medium on which instructions defining a program executed by a processor may be stored. The storage system 618 may also include information recorded on or in the medium, and this information may be processed by the program. More specifically, the information may be stored in one or more data structures specifically configured to save storage areas or improve data exchange performance. The instructions may be permanently stored as encoded bits or signals, and the instructions may cause the processor to execute any of the functions described by the encoded bits or signals. The medium may be, for example, an optical disk, a magnetic disk, or a flash memory. In operation, the processor 610 or some other controller may read data from the non-volatile recording medium into another memory, such as the memory 612, that makes access to the information by the processor faster than the storage medium included in the storage system 618. The memory may be located in the storage system 618 or in the memory 612. The processor 610 may manipulate the data in the memory 612 and, after the processing is complete, copy the data to the medium associated with the storage system 618. Various components may manage the data movement between the medium and the integrated circuit memory elements, and this is not intended to limit the present disclosure. Further, the present disclosure is not limited to a particular memory system or storage system.

[0115] The above exemplary computerized device is illustratively shown as one type of exemplary computerized device on which various aspects and functions according to the present disclosure can be implemented. However, aspects of the present disclosure are not limited to being implemented on an exemplary computerized device 600 as shown in FIG. 6. Various aspects and functions according to the present disclosure may be implemented on one or more computers having components other than those shown in FIG. 6. For example, the exemplary computerized device 600 may include specially programmed application-specific hardware, such as an application-specific integrated circuit (ASIC) adapted to perform certain operations disclosed in this embodiment. On the other hand, another embodiment may use Windows, Linux, Unix, Android, iOS, MAC OS X, or other operating systems on the aforementioned processors, and / or dedicated computing devices that execute their own hardware and operating systems to perform essentially the same functions.

[0116] The exemplary computerized device 600 may include an operating system that manages at least some of the hardware elements included in the exemplary computerized device 600. A processor or controller, such as processor 610, can execute the operating system, and the operating system may be, among other things, an operating system, one of the aforementioned operating systems, one of many Linux-based operating system distributions, a UNIX operating system, or another operating system that would be apparent to those skilled in the art. Many other operating systems may be used, and the embodiments are not limited to a particular operating system.

[0117] A processor and an operating system can cooperate to define a computing platform on which application programs in high-level programming languages are described. These component applications can be executable code, intermediate code (e.g., C# or Java bytecode), or interpreter code that communicates via a communication network (e.g., the Internet) using a communication protocol (e.g., TCP / IP). Similarly, aspects according to the present disclosure may be implemented using object-oriented programming languages such as Java, C, C++, C#, Python, PHP, Visual Basic.NET, JavaScript, Perl, Ruby, Delphi / Object Pascal, Visual Basic, Objective-C, Swift, MATLAB, PL / SQL, OpenEdge ABL, R, Fortran, or other languages that will be apparent to those skilled in the art. Other object-oriented programming languages can also be used. Alternatively, assembly language, procedural language, script language, or logic programming language can also be used.

[0118] Furthermore, various aspects and functions according to the present disclosure may be implemented in a non-programming environment (e.g., HTML5, HTML, XML, CSS, JavaScript, or a document created in another format that renders aspects of a graphical user interface or performs other functions when displayed in a browser program window). Additionally, various embodiments in accordance with the present disclosure may be implemented as programmed elements, non-programmed elements, or any combination thereof. For example, a web page can be implemented using HTML, and a data object called from within the web page can be described in C++. Thus, the present disclosure is not limited to a particular programming language and any suitable programming language can be used.

[0119] Exemplary computerized devices included within embodiments may perform functions outside the scope of the present disclosure. For example, aspects of the system may be implemented using existing commercial products such as SQL Server available from Microsoft in Redmond, Washington, database management systems such as Oracle Database or MySQL available from Oracle in Austin, Texas, or integration software such as WebSphere middleware available from IBM in Armonk, New York.

[0120]

Industrial Applicability

[0121] In operation, a method for evaluating, managing, and paying insurance claims related to parametric risk compensation may be provided using a distributed ledger to reduce and / or eliminate human operation and / or management. One skilled in the art will understand that the following methods are provided to illustrate one embodiment of the present disclosure and should not be construed as limiting the present disclosure to only these methods or aspects. One skilled in the art will understand additional methods within the scope and spirit of the present disclosure for performing the operations provided by the following examples after benefiting from the present disclosure. Such additional methods are intended to be included by the present disclosure.

[0122] Next, with reference to flowchart 700 of FIG. 7, an exemplary method regarding the overview of evaluation, management, operation, insurance payment, and other operations will be described without limitation. Starting from block 702, the operation may begin with identifying risks for consideration of insurance risk compensation (block 704). A trigger may be defined and associated with the identified risks (block 706). Then, the operation may analyze the risks and triggers to determine insurance to recommend to the insurer (block 708). Thereafter, the insurer can confirm the selection of an insurance contract (block 710). Optionally, the insurer can select an insurance contract other than the insurance contract recommended in block 708, without limitation.

[0123] Once an insurance contract is selected, the operation can write a self-executing contract such as a smart contract for that insurance contract (block 720). The triggers defined in the self-executing contract can be monitored to determine whether an insurance payment event should occur (block 730). Thereafter, at block 740, it can be determined whether a trigger event has occurred. If it is determined at block 740 that the trigger event has not occurred, the operation can return to block 730 and continue monitoring the trigger. If it is determined at block 740 that the trigger event has occurred, the operation proceeds to block 742 and can make a payment of the insurance payment amount. Thereafter, the operation can end at block 750.

[0124] Next, with reference to the flowchart 800 of FIG. 8, an exemplary method for insurance recommendation and generation operations will be described without limitation. Starting from block 802, the operation can begin by obtaining historical data of risk events (block 804) and obtaining substantially real-time data of risk events (block 806). The operations of block 804 and block 806 can be performed in substantially any order and / or simultaneously without limitation. Insurance recommendations can utilize both the historical database and the real-time database to collect risk pricing data, and then the risk pricing data is recorded in a distributed ledger and / or a cloud platform. When data is obtained for a risk event, the obtained data set can be stored on a data storage structure such as provided by a distributed ledger (block 810).

[0125] Next, the data set can be normalized (block 820) and can be cleaned (block 822). The operations of block 820 and block 822 can be executed in substantially any order and / or simultaneously without limitation. In some embodiments using a distributed ledger, nodes can monitor the distributed ledger to ensure data immutability while recording the origin of the data. Once normalized and cleaned, the data set can be used to generate a schema (block 824). Then, the schema can be used to generate a risk pricing model, for example, via a predictive analytics engine (block 830).

[0126] Next, the operation can receive user input regarding the compensation needs for an insurance contract that protects against risk events (block 840). The user input can be compared to a risk pricing model (block 842). At this step of the operation, machine learning can be used to predict an insurance contract that matches the information provided by the user input and the risk pricing model. For example, an AI-driven predictive analytics engine can generate a risk pricing model using the result schema. Along with continuous input from historical and real-time databases, the risk pricing model allows the predictive analytics engine to continuously learn and refine how to assess and price risks. The risk pricing model can utilize a trigger catalog to determine when the conditions for making an insurance payment are met.

[0127] Next, insurance can be recommended to the user (block 850). The user can select insurance, which can be the recommended insurance and / or another insurance selected by the user (block 852). The user can add additional insurance conditions, compensation types, and other insurance parameters when selecting the insurance. The selected insurance (insurance contract) can then be recorded on the chain (block 860). A smart contract or other self-executing contract may be established for the insurance contract (block 862). The operation can then end at block 870.

[0128] Next, with reference to flowchart 900 of FIG. 9, an exemplary method for verification and token generation, without limitation, will be described. Starting from block 902, the operation can begin by receiving user identification information that may be provided by a user interacting with a survey and / or other input functionality (block 904). The operation can then connect to a database via an API and verify authentication information and other identification information associated with the user (block 910). For example, the API may be used to obtain data from an ID database, which may include records such as DMV records, bank records, credit reports, and / or other records that would be understood by one of ordinary skill in the art after benefiting from the present disclosure. Next, the information provided by the user can be compared with the information obtained from the ID database (block 912). The server can cross-reference the data received from the ID database with user identification information such as age, date of birth, social security number, and / or other information provided by the policyholder.

[0129] Next, at block 920, it can be determined whether there is a sufficient correlation between the information provided by the user and the information included in the ID database to verify the user. If at block 920 it is determined that the relationship between the data provided by the user and the information obtained from the ID database is insufficient to confirm the user's identity, user identification may be rejected (block 924). If rejected, the operation can return to block 904 to receive new identification information and / or supplementary identification information. Optionally, an instruction specifying the additional information requested may be provided to the user. Alternatively, if rejected, the operation may end at block 960.

[0130] In block 920, if sufficient correlation is determined to exist, user identification can be accepted (block 922). Thereafter, a token indicating the verified identification can be created (block 926). The verified user identification token can then be associated with an insurance contract (block 928). The token and the insurance contract can then be associated in the form of a smart contract (block 930). The integrity of the self-executing contract and the data recording structure (e.g., smart contract and distributed ledger) in which the self-executing contract is recorded can be verified and maintained using nodes (block 940). A copy of the token may be provided to the user (block 950). Thereafter, the operation can end at block 960.

[0131] Referring now to flowchart 1000 of FIG. 10, and not by way of limitation, an exemplary method for exemplary insurance payment operations will be described. Starting at block 1002, the operation can be initiated by calling parameters of a self-executing contract such as a smart contract (block 1004). Next, at block 1006, it can be determined whether a trigger has been detected. If it is determined at block 1006 that no trigger has been detected, the operation can continue to monitor the self-executing contract for detection of a trigger. If it is determined at block 1006 that a trigger has been detected, the self-executing contract can be executed (block 1010).

[0132] When the self-executing contract is executed, an insurance payment can be determined (block 1012). Then, the insurance payment may be distributed as defined by the self-executing contract (block 1014). Next, at block 1020, it may be determined whether a social incentive is selected. If it is determined at block 1020 that no social incentive is selected, the entire paid insurance amount can be directed to the insurance policyholder (block 1026). If it is determined at block 1020 that a social incentive is selected, a portion of the paid insurance amount can be distributed to the recipient of the social incentive (block 1022). In an example where multiple social incentives are selected, each recipient of the social incentive can receive a portion of the paid insurance amount as specified at block 1022. The remainder of the paid insurance amount can be distributed to the insurance policyholder (block 1024). After either operation of block 1026 or 1024, the operation can end at block 1030.

[0133] Next, with reference to flowchart 1100 of FIG. 11, an example method for an alternative configuration of social incentives will be described. This example can be used to replace, supplement, or otherwise be used in conjunction with the example described above with FIG. 10. Starting from block 1102, an exemplary method can begin by calling parameters of a self-executing contract such as a smart contract (block 1104). Then, at block 1106, it can be determined whether a profitability threshold is met. In one example, the profitability threshold can be met when sufficient profit is obtained for the operation of a system or method enabled by the present disclosure.

[0134] In block 1106, if it is determined that the profitability threshold is not met, the operation can retain the profit, if any, for the purposes defined by the company (block 1126). For example, a company operating a method or system enabled by the present disclosure may reinvest the profit in the company, pay at least a portion of the profit into the company's capital, donate a portion of the profit, or otherwise direct the profit as the company deems appropriate. Similarly, if it is determined that sufficient profit has not been obtained, the operation can choose not to distribute dividends.

[0135] In block 1106, if it is determined that the profitability threshold is met, the operation can continue to block 1120 and determine whether a social incentive has been selected by the insurer. In block 1120, if it is determined that no social incentive has been selected by the insurer, the operation can continue to block 1126 and retain the profit for the purposes directed by the company. In block 1126, if it is determined that the insurer has specified a social incentive for receiving at least a portion of the profit distribution, the selected amount of the profit can be paid as a profit distribution to the designated recipient (block 1122). The recipient can include charities, family members, the insurer, and / or other parties. If a recipient is designated, a portion of the profit can be paid substantially automatically to a third party or the insurer. The remainder of the profit not paid as a profit distribution may be retained by the company operating the method or system enabled by the present disclosure for distribution as the company deems appropriate (block 1124). After the operation of block 1126 or block 1124, the operation can end at block 1130.

[0136] While not limiting, exemplary token incentives and exemplary methods for market operation are described. The operation can begin by leveraging an asset tokenization platform to create cryptographic utility tokens. These cryptographic tokens can be protected and monitored by third - party nodes that monitor and protect the distributed ledger and / or smart contracts recorded on the distributed ledger. The nodes can receive at least a portion of the tokens as a reward for protecting and monitoring the distributed ledger and / or smart contracts.

[0137] The nodes can also facilitate the transfer of tokens to the insurer's wallet so that the insurer can indicate how it wishes to allocate benefits to social incentives. Similar to the insurer, third - party nodes can choose to trade the received utility tokens on a third - party cryptocurrency exchange. Traders can also participate in the trading of tokens and other assets by acquiring tokens through a third - party exchange.

[0138] Furthermore, nodes, insurers, and traders can conduct derivative transactions using the tokens. Buckets of insurance contracts classified by risk level can be created via a predictive analytics engine and / or a risk - pricing model. In one example, buckets of insurance contracts are tradable as derivatives. In another example, financial products based on insurance contracts, tokens, buckets of insurance contracts, risks, or other metrics related to insurance contracts can be listed on a public exchange.

[0139] Although various aspects have been described in the above disclosure, the description of the disclosure is intended to illustrate and not limit the scope of the invention. The invention is defined by the appended claims and not by the examples and embodiments provided in the above disclosure. Those skilled in the art will understand further aspects of the invention that can be realized in alternative embodiments after benefiting from the above disclosure. Other aspects, advantages, embodiments, and modifications are included in the following claims.

Claims

1. A method for managing parametric risk indemnity insurance, operable on a server storing user information related to a user in an electronic computer database, comprising: a) obtaining a data set via a computer communication network operably connected to the server via a network connection, said data set including risk information related to compensable risks; b) analyzing said data set to model the probability of an insurance claim related to said risk and determining a pre-risk price of said risk based on at least said probability of said insurance claim and the cost of said insurance claim, thereby pricing said insurance claim related to said risk; c) defining said trigger related to said risk that determines when a payment insurance claim related to said insurance claim to which a trigger is applied is paid, said trigger being storable in a trigger catalog; d) recommending said insurance for said risk, including: i. displaying a survey related to said risk for said requested insurance on a user remote computing device; ii. comparing the survey result of said survey with said risk information to determine whether said risk is compensable; iii. for said compensable risk, adjusting said pre-risk price to determine an insurance risk price and recommending said insurance at said insurance risk price; e) establishing said insurance, including: i. receiving a selection of said insurance by said user via said computer communication network; ii. recording said insurance in a data storage structure for said insurance selected by said user and writing a self-executing contract to define said trigger that causes an insurance claim for said insurance; f) monitoring the occurrence of said trigger defined by said self-executing contract, and when the occurrence of said trigger is detected: i. substantially automatically executing said self-executing contract; ii. substantially automatically paying funds for said payment insurance claim defined by said self-executing contract to said user; iii. recording said payment in said data storage structure. ​ ​ By executing, paying the said insurance payment; A method including.

2. The method according to claim 1, wherein the said dataset includes a historical dataset and a substantially real-time dataset.

3. The step (a) further includes i. Normalizing at least a part of the said dataset to facilitate comparative analysis of the said risk information included in the normalized said dataset; ii. Cleaning the said dataset and generating a schema to assist in the analysis of the said dataset. The method according to claim 1, including.

4. The step (b) further includes Generating a data model using the said schema and the said dataset via a machine learning model and / or a predictive analysis engine. The said dataset includes a historical dataset and a substantially real-time dataset. The method according to claim 3, wherein the said data model includes a risk pricing model.

5. (g) Verifying the said data model generated by the said machine learning model and / or the said predictive analysis engine, and using nodes to verify at least the said insurance and the said self-executing contract recorded in the said data storage structure. The method according to claim 4, further including.

6. (h) Generating an incentivized token associated with the said insurance and recorded in the said data storage structure. The method according to claim 5, further including.

7. Obtaining verification information about the said user via a computer communication network. Using a trained machine learning model to compare the said user information provided by the said user with the said verification information to determine the likelihood of verifying the said user. The method according to claim 1, further including.

8. The said data storage structure includes a distributed ledger. The said self-executing contract includes a smart contract. At least the said insurance and the said smart contract are recorded in the said distributed ledger and are made immutable. The method according to claim 1.

9. (i) Further including providing a transaction of the said insurance and / or a derivative related to the said insurance bucket via the market. The said insurance bucket is represented by a utility token tradable through the market. The activity of the traded utility token is recorded in the data storage structure. The method according to claim 1.

10. (j) When selected by the user as a social incentive, selectively providing a recipient payout from at least a portion of the payment insurance premium, i. When executing the self-executing contract of the payment insurance premium for which the recipient payout is selected, instructing at least a portion of the payment insurance premium as the recipient payout; ii. Instructing at least a portion of the remaining portion of the payment insurance premium for payment to the user; The method according to claim 1, further comprising:

11. A system for managing parametric risk compensation insurance, a server that stores user information regarding a user in an electronic computer database, a network connection from the server to a computer communication network, and the server (a) obtaining a dataset including risk information regarding compensable risks via the computer communication network; (b) analyzing the dataset via the server, modeling the likelihood of an insurance claim related to the risk, and determining a pre-risk price of the risk by determining at least the likelihood of the insurance claim and the cost of the insurance claim, thereby pricing the insurance claim related to the risk; (c) defining a trigger related to the risk to determine when a payment insurance premium related to the insurance claim to which the trigger is applied is paid; (d) recommending the insurance for the risk, i. displaying a survey regarding the risk for the requested insurance on a user remote computing device; ii. comparing the survey results of the survey with the risk information to determine whether the risk is compensable; iii. for the compensable risk, adjusting the pre-risk price to determine an insurance risk price and recommending the insurance at the insurance risk price; including; (e) establishing the insurance, i. receiving a selection of the insurance by the user via the computer communication network; ii. Recording the insurance selected by the user in a distributed ledger and writing a smart contract that defines the trigger that causes the insurance claim for the insurance. Further including (f) Monitoring the occurrence of the trigger defined by the smart contract, and when the occurrence of the trigger is detected, i. Automatically and actually executing the smart contract; ii. Substantially automatically paying the funds for the insurance payment benefit defined by the smart contract to the user; iii. Recording the payment in the distributed ledger. By executing the above, paying the insurance payment benefit. A system configured to execute an instruction to execute.

12. The system according to claim 11, wherein the dataset includes a historical dataset and a substantially real-time dataset.

13. At least a part of the dataset is normalized to facilitate comparative analysis of the risk information included in the normalized dataset, Clean the dataset and generate a schema to assist in the analysis of the dataset. The system according to claim 11.

14. Further including a machine learning model and / or a predictive analysis engine that generates a data model using the schema and the dataset, The dataset includes a historical dataset and a substantially real-time dataset, The data model includes a risk pricing model. The system according to claim 13.

15. A node for verifying the data model generated by the machine learning model and / or the predictive analysis engine and verifying at least the insurance and the smart contract recorded in the distributed ledger. The system according to claim 14, further including.

16. An incentive token is generated and associated with the insurance recorded in the distributed ledger. The system according to claim 15.

17. A trigger catalog stored in an electronic computer database and accessible by the server to record the trigger. The system according to claim 11, further including.

18. At least the insurance and the smart contract are recorded in the distributed ledger and are made immutable. The system according to claim 11.

19. further comprising a market component that provides transactions of the insurance and / or derivatives related to the buckets of the insurance, the buckets of the insurance are represented by utility tokens that are tradable via the market component, the activities of the traded utility tokens are recorded in a distributed ledger, The system according to claim 11.

20. further comprising an incentive component that selectively provides profit distributions from at least a portion of the profits, the user selectively designates at least a portion of the profit distribution as a recipient distribution, and the remaining portion of the profit distribution is either paid to the user or retained by the operator of the system, The system according to claim 11.

Images