Machine Learning Technologies for Efficiently Obtaining Insurance Coverage

FIELD OF THE DISCLOSURE

The present disclosure generally relates to insurance and, more specifically, to systems and methods for obtaining and/or maintaining insurance coverage.

BACKGROUND

Individuals who seek insurance coverage and are sensitive to pricing and product features (e.g., coverage types and/or limits, deductibles, etc.), or “frequent shoppers,” often expend considerable time and effort in finding insurance providers that best meet their needs. Conventionally, a frequent shopper finds an insurance provider by way of an agent/broker, an aggregator, a comparison web site, general web browsing, etc. Once the frequent shopper obtains an insurance policy from the desired provider, the frequent shopper is typically tied to that provider, and to the rate and product features of the policy offered by the provider, until and unless he or she proactively shops around for a new provider offering a policy with a better rate and/or product features. For example, a frequent shopper might decide to look into the offerings of other insurance providers when the frequent shopper's current policy is up for renewal. Thus, a frequent shopper typically must either spend time and effort looking for a better-priced insurance offering on a recurring basis (e.g., once every six months or annually), or simply renew his or her current policy regardless of whether that policy provides the best rate and/or product features. Conventional agency-based insurance models may not suffice to meet a frequent shopper's needs, due to the perceived additional cost associated with having an agent.

SUMMARY

The present embodiments may, inter alia, automatically provide frequent shoppers with insurance policies that offer superior rates and/or product features on a continuing basis (e.g., across multiple policy terms), thereby reducing or eliminating the time and/or effort that frequent shoppers must spend researching the offerings of different insurance providers, as well as providing frequent shoppers with insurance policies that have lower cost and/or are more reflective of a risk score, characteristics, and/or preferences of the frequent shopper as they change over time. The terms “frequent shopper,” “consumer,” and “customer” are utilized interchangeably herein, and generally refer to a person who is an insured party or a potential insured party, regardless of how frequently that individual in fact would like to shop for insurance coverage or has shopped for insurance coverage in the past. A frequent shopper may be represented by himself or herself, or may be represented by an agent (e.g., by a spouse, a person who has power of attorney for the frequent shopper, an administrative assistant, etc.).

An intermediary entity may act on behalf of frequent shoppers and/or their agents (i.e., with the consent of the frequent shoppers and/or agents) to find policy rates and/or other features that best meet the frequent shoppers' insurance requirements and/or preferences. Based upon an analysis of individual frequent shopper characteristics and/or insurance preferences, each individual frequent shopper may be grouped with other insurance frequent shoppers that have the same or similar characteristics and/or insurance preferences. These “affinity groupings” (or “affinity groups”) may be based upon demographic information for the frequent shoppers (e.g., gender, birth date, etc.), information about property of the frequent shoppers (e.g., a make, model and year of an automobile, etc.), claim and/or accident history of the frequent shoppers, risk (or lack thereof) characteristics of the frequent shoppers, insurance claim expectations of the frequent shoppers, insurance company ratings, the content and/or availability of telematics data obtained from vehicles and/or mobile devices of the frequent shoppers, driving behaviors of the frequent shoppers, etc.

The right to provide insurance coverage for the affinity groupings (either on a per-member basis or to each affinity group as a whole) may be offered for sale to various insurance providers, such as through an online auction. In some embodiments, other entities may also participate in the online auction. For example, reinsurers and/or entities that manage investment funds (e.g., hedge fund companies seeking arbitrage opportunities) may participate in the online auction, e.g., if those entities have agreements with insurance providers are licensed to write insurance and can legally service claims, etc., for the members of the affinity group.

Once a winning bid is accepted, any existing insurance policies of the frequent shoppers affiliated with the auctioned group may (or may not) be updated to reflect new insurance policy terms or parameters (e.g., premiums, rates, etc.), discounts, refunds, etc. In some cases, new insurance policies may be provided to one or more frequent shoppers (such as when a frequent shopper is an insurance applicant, or when an existing insurance policy is canceled and a new policy is issued in its stead). The affinity groups may be updated (and/or new affinity groups may be created) over time as new or more recent frequent shopper characteristic data and/or preference information is collected and/or updated. The insurance policies associated with the updated (or new) affinity groups may then be re-auctioned (or auctioned).

Additionally or alternatively, insurance providers may mitigate the risks associated with insurance policies that are already in effect (or will soon be in effect), by grouping/segmenting those policies and auctioning the opportunity to reinsure those policy groups to other entities (e.g., reinsurers). The grouping for these auctions may correspond to the affinity groups discussed above (e.g., with a particular group of policies that is being auctioned consisting of the policies of all members of a particular affinity group), or may be an independent/subsequent grouping of the insurance policies, for example.

Various machine learning technologies described herein may increase the efficiency of any or all of the grouping and/or auctioning techniques discussed above, in some embodiments. For example, machine learning models may be used to evaluate risks (e.g., determine risk scores/classifications and/or infer risk-related characteristics) associated with different frequent shoppers for a particular type of insurance (e.g., risks of vehicular accidents and/or theft for auto insurance), prior to segmenting those frequent shoppers into different affinity groups based upon those risks. Machine learning may also be used to define and/or update/refine criteria for different affinity groups, e.g., by using regression models to determine which groupings of frequent shoppers have historically attracted more interest (e.g., more frequent and/or higher bids) from insurance providers, and/or have historically had more stable group membership, etc.

Machine learning techniques may also, or instead, be used to set up an auction, and/or to facilitate the auction itself. For example, machine learning models may help determine which insurance providers to invite to participate in an auction, by predicting which providers are more likely to be interested in (e.g., more likely to submit bids for) providing insurance coverage to a particular affinity group, and/or may determine a suitable starting bid (e.g., “reserve”) amount, etc.

Many or all facets of the auction process, and/or other procedures prior to and/or after the auction process, may be automated. For example, communications with auction participants (e.g., insurance providers and/or reinsurers, etc.), and/or communications with consumers that occur before, during, and/or after the auction process, may be automated. For example, notifying insurance providers and/or reinsurers regarding an upcoming auction, communicating bid amounts among providers and/or reinsurers during an auction, notifying auction winners, corresponding with consumers regarding insurance provider placements, billings, sending insurance cards, etc., and/or other communications may be automated. In some embodiments, records associated with consumers, insurance providers (and/or reinsurers or other auction participants), affinity groups, and/or auctions may be securely stored utilizing blockchain systems and/or techniques.

In one aspect, a computer-implemented method comprises: (1) dividing, by one or more processors, a plurality of consumers into multiple affinity groups based upon one or more characteristics and one or more preferences of the plurality of consumers, at least in part by analyzing the one or more characteristics and/or the one or more preferences of the plurality of consumers using a machine learning model; (2) auctioning, by the one or more processors and via a communications network, an opportunity to provide insurance for one or more of the multiple affinity groups; (3) receiving, by the one or more processors and via the communications network, one or more bids for purchase and/or offers of insurance for the one or more of the multiple affinity groups; (4) accepting, by the one or more processors, a winning bid of the one or more bids; and/or (5) causing, by the one or more processors, individual insurance policies or a group insurance policy to be provided to or updated for consumers associated with a particular affinity group corresponding to the winning bid, thereby providing lower cost insurance and/or insurance that is more reflective of actual risk, or lack thereof, to the consumers associated with the particular affinity group.

In another aspect, a system comprises a persistent memory storing a consumer profile database, a communication interface configured to communicate with remote devices via a communications network, one or more processors, and/or one or more non-transitory, computer-readable media storing instructions. The instructions, when executed by the one or more processors, cause the system to: (1) divide a plurality of consumers into multiple affinity groups based upon one or more characteristics and one or more preferences of the plurality of consumers, at least in part by analyzing the one or more characteristics and/or the one or more preferences of the plurality of consumers using a machine learning model; (2) auction, via the communication interface and the communications network, an opportunity to provide insurance for one or more of the multiple affinity groups; (3) receive, via the communication interface and the communications network, one or more bids for purchase and/or offers of insurance for the one or more of the multiple affinity groups; (4) accept a winning bid of the one or more bids; and/or (5) cause individual insurance policies or a group insurance policy to be provided to or updated for consumers associated with a particular affinity group corresponding to the winning bid, thereby providing lower cost insurance and/or insurance that is more reflective of actual risk, or lack thereof, to the consumers associated with the particular affinity group.

Advantages will become more apparent to those skilled in the art from the following description of the preferred embodiments which have been shown and described by way of illustration. As will be realized, the present embodiments may be capable of other and different embodiments, and their details are capable of modification in various respects. Accordingly, the drawings and description are to be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The Figures described below depict various aspects of the system and methods disclosed therein. It should be understood that each Figure depicts one embodiment of a particular aspect of the disclosed system and methods, and that each of the Figures is intended to accord with a possible embodiment thereof. Further, wherever possible, the following description refers to the reference numerals included in the following Figures, in which features depicted in multiple Figures are designated with consistent reference numerals.

There are shown in the drawings arrangements which are presently discussed, it being understood, however, that the present embodiments are not limited to the precise arrangements and instrumentalities shown, wherein:

FIG. 1 depicts an exemplary environment including components associated with obtaining and/or maintaining insurance coverage, according to one embodiment;

FIG. 2 depicts an exemplary computer system in which the techniques described herein may be implemented, according to one embodiment;

FIG. 3 depicts an exemplary computer-implemented method of auctioning groups or bundles of insurance policies;

FIG. 4 depicts an exemplary computer-implemented method of auctioning groups or bundles of usage-based insurance (UBI) policies;

FIG. 5 depicts an exemplary computer-implemented method of auctioning groups or bundles of autonomous vehicle insurance policies;

FIG. 6 depicts an exemplary computer-implemented method of auctioning groups or bundles of insurance policies;

FIG. 7 depicts an exemplary computer-implemented of auctioning groups of bundles of insurance policies;

FIG. 8A depicts an exemplary blockchain environment in which the blockchain techniques described herein may be implemented, according to one embodiment;

FIG. 8B illustrates an exemplary flow diagram in which pluralities of transactions are compiled into blocks;

FIG. 8C depicts an exemplary computer-implemented method for auctioning insurance policies using a blockchain environment, according to one embodiment;

FIG. 9 depicts an exemplary computer-implemented method for auctioning insurance policies to entities that include at least one reinsurer, according to one embodiment;

FIG. 10 depicts an exemplary environment including components associated with obtaining reinsurance, according to one embodiment;

FIG. 11 depicts an exemplary computer-implemented method for auctioning an opportunity to reinsure at least a portion of liabilities associated with one or more insurance policy groups, according to one embodiment;

FIGS. 12A and 12B depict the training and run-time operation, respectively, of a neural network that analyzes characteristics and/or preferences of a consumer to facilitate assignment of the consumer to an affinity group, according to one embodiment; and

FIG. 13 depicts an exemplary computer-implemented method for auctioning insurance policies based upon affinity groups that are formed using machine learning, according to one embodiment.

The Figures depict preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the systems and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DETAILED DESCRIPTION
I. Exemplary Automatic Procurement and Maintenance of Insurance Coverage

The present embodiments relate to, inter alia, obtaining and/or maintaining insurance coverage with insurance policies having advantageous rates and/or product features, or reinsuring liabilities associated with existing insurance policies according to advantageous terms. The insurance policies may be policies for any type of insurance, such as automobile or other vehicle insurance, home or condominium insurance, personal property insurance or life insurance, health insurance, pet insurance, burial insurance, for example.

In some embodiments, an intermediary entity may act on behalf of consumers/frequent shoppers to find policy rates and/or other features that best meet the consumers' insurance requirements and/or preferences. For example, for individuals or end-consumers (e.g., persons or people), each individual or end-consumer may access an application form (e.g., an on-line form) and enter information relevant to the availability and/or pricing of the consumer's desired insurance policy, such as demographic information (e.g., gender, birth date, etc.), information about the consumer's property (e.g., a make, model and year of an automobile, etc.), claim and/or accident history of the consumer, and so on. In one embodiment, based upon the entered information, the individual or end-consumer may be grouped together with one or more other end-consumers in an “affinity group.” The affinity group may be defined by any suitable criterion or criteria, such as insurance provider requirements and/or classifications, behavioral and/or attitudinal segmentation, member requirements and/or preferences, etc. To provide just a few more specific examples, the affinity group may be defined by the occupation of the group members, risk characteristics of the group members (e.g., as is typically determined during the underwriting process), insurance claim expectations of the group members (e.g., based upon past claim history and/or risk characteristics), insurance company ratings required or preferred by the group members (e.g., AAA), the content and/or availability of telematics data obtained from vehicles of the group members, the minimum or maximum length of time that the group members wish to remain with a single insurance company or be “shopped around” with a new auction, etc. An affinity group may be established any time that two or more members are identified as meeting the group requirements, or may be established only when some higher threshold number of members (e.g., 100 members, 1,000 members, etc.) has been met, for example. In some implementations, an affinity group may be pre-defined (at least in part, or solely) by individuals' or end-consumers' memberships in (or affiliations with) an organization, such as a professional organization or association, a fraternity or sorority, a service or volunteer organization, a business or company, etc. That is, the affinity group may be pre-defined by a third party.

In some embodiments, the intermediary entity (e.g., any of the processors or computing systems of the intermediary entity discussed herein) may define the affinity groups (e.g., determine criteria/requirements for membership in each affinity group) by analyzing historical data. For example, the intermediary entity may analyze historical data indicative of consumer characteristics and/or preferences for different affinity groups that were formed in the past, as well as bidding activity that occurred for those affinity groups (e.g., bidding amounts and/or frequencies), and thereby identify which affinity groups (and correspondingly, which affinity group requirements/criteria) resulted in the most interest from bidders (e.g., insurance providers). As a more specific example, such an analysis may determine that relatively high/frequent bidding occurred for (1) affinity groups that included only a narrow range of risk scores (regardless of whether those scores were “good” or “bad”), and (2) affinity groups for which members revealed a preference of staying with the same insurance carrier/provider for at least one year. In this scenario, the intermediary entity may define affinity groups according to two criteria: (1) all members must be within the same risk score range of a predetermined set of relatively narrow score ranges, and (2) all members must exhibit the same preference with respect to desiring to stay with the same insurance provider for “less than one year” or “at least one year.” Machine learning techniques (e.g., regression techniques) may be used to define or refine affinity group membership criteria, as discussed in further detail below.

In some embodiments, the intermediary entity may act on behalf of a consumer that is not a person, individual, or end-consumer, but instead is an organization, company, business, or other entity that provides a product and/or service to individuals or end-consumers and that wishes to procure insurance to cover its products, services, and/or assets associated therewith. As such, the consumer may be a third-party that desires to procure insurance for a group of products, services, and/or assets associated therewith, rather than procure insurance for a group of people or end-consumers.

For example, a car rental company may wish to procure insurance for a fleet of rental cars, or an autonomous vehicle manufacturer may wish to procure insurance for a fleet of autonomous vehicles. Other examples of consumers that are not individuals or end-consumers may include owners of multi-tenant buildings whose units are leased to end-consumers (e.g., university housing, apartment complexes, etc.), a car sharing service or other service that provides fractional use of assets and/or services to various end-consumers, a provider of time-shares or other assets that are fractionally-owned by end-consumers, and the like.

In these embodiments, an affinity group may be pre-defined by the third-party (e.g., by the business, company, organization, entity, etc.), and affinity group members may comprise the products, services, and/or assets associated therewith corresponding to the defined affinity group. For example, a car rental company may pre-define a set of a particular type of rental car (e.g., economy, mini, premium, etc.) as an affinity group, a time-share provider may pre-define a set of condominiums in a particular location as an affinity group, or an autonomous vehicle manufacturer may pre-define a set of autonomous vehicles having certain autonomous control features and/or limitations, etc. as an affinity group.

For affinity groups that are pre-defined (e.g., based upon end-consumer membership or affiliation, and/or based upon sets of assets and/or services), a universal insurance application may be provided to each member of the pre-defined affinity group, and/or for each asset or service (e.g., for each object of insurance) for which coverage is desired. The universal application may request similar information for all members or objects of the pre-defined affinity group, and in some cases, at least some portions of the universal application may utilize common data for each member or object of the pre-defined affinity group. For example, a common desired term length, maximum deductible, and/or coverage amount may be pre-defined in the universal application for all members/assets/services. If desired, value of other insurance application fields may vary across members of the affinity group, for example, age, driving record, home address, etc.

Once an affinity group has been established, the intermediary entity may present information about the affinity group members to a number of insurance providers/carriers, along with a request for insurance coverage quotes, that is, the intermediary entity may offer an opportunity to provide insurance for the affinity group members. For example, the intermediary entity may hold an auction within a particular time period or window of time. During the auction, the participating insurance providers may be permitted to bid on providing insurance for the affinity group. The insurance provider that “wins” by bidding the lowest price/rate (given the profile of the affinity group members), or more generally, in some embodiments, by bidding to provide a policy that aligns most closely with the requirements and/or preferences of the group members, may be chosen to provide the insurance to the members of the affinity group for a specified time period or term (e.g., six months).

In some embodiments, the winning insurance provider may issue insurance policies that have at least some terms in common for each member or object of the affinity group. For example, each member of an affinity group based upon a professional organization may be issued an insurance policy having the same term length, deductible amount, maximum medical coverage amount, etc. In another example, each autonomous vehicle included in an affinity group may be covered by a same per-vehicle liability limit or a same amount of collision coverage. Depending on the embodiment, the insurance provider may provide individual coverage/policies to each affinity group member, or may provide joint/group coverage to all members under a single policy.

At any rate, during the term of the insurance policies that have been issued to end-consumers or individuals based upon the auction, the winning insurance provider may directly handle claims and other inquiries from the members of the affinity group (e.g., on-line and/or via a dedicated call center), and the members of the affinity group may have their checking accounts, credit cards, and/or other fund sources automatically debited (e.g., periodically) by the winning insurance provider in order to pay for the insurance coverage. Similarly, during the term of one or more insurance policies that have issued to cover a group of assets or services, the insured party (e.g., the organization or entity that owns or provides the covered group of assets or services on behalf of which the intermediary has procured insurance) may provide automatic payments to the winning insurance provider to pay for the insurance coverage.

In some embodiments, one or more other types of entities, other than insurance carriers/providers, can also (or instead) participate in the auction. For example, a reinsurance provider/company (“reinsurer”) and/or a financial/investment entity (e.g., hedge fund management company) may participate directly in the auction, e.g., after forming an agreement with an insurance carrier that is licensed to write insurance and can legally service claims, etc., for the affinity group members.

In some embodiments, the intermediary entity may, prior to the conclusion of each of one or more policy terms for the affinity group members, automatically conduct another auction for the affinity group. In this manner, the affinity group members may continually receive the most competitively priced insurance coverage (and/or the insurance with the best product features), with little or no additional effort by the group members. Some of the benefits and/or pricing discounts earned by group members, such as loyalty or accident-free discounts, may become a part of the profile of the affinity group, and may be priced into the future costs of the affinity group's insurance coverage. If a member of the affinity group has a driving violation or accident, the member may be moved to a different affinity group to which the member better aligns (e.g., to an affinity group with more similar risk characteristics and/or insurance claim expectations, etc.) for future auctions. Additionally or alternatively, a particular member of the affinity group may choose to opt-out upon the expiration of the policy term. The intermediary entity may conduct insurance coverage auctions for a number of different affinity groups. The intermediary entity may form new groups, rearrange existing groups, and/or shop groups to insurance providers on a periodic (e.g., daily) basis, or on any other suitable basis.

In some embodiments, the intermediary entity may instead (or additionally) auction insurance policies for consumers on an individual basis. For example, the intermediary entity may use a consumer profile (e.g., containing information that was entered in an on-line or other application form, claim information, telematics data, etc.) to automatically seek out an insurance company providing a policy that best meets the pricing and/or product feature requirements and/or preferences of the consumer. The intermediary entity may automatically perform this process when the consumer first obtains a policy and/or each time that the consumer's current policy is up for renewal. In these embodiments, the intermediary entity may seek the best insurance provider/policy each term (e.g., each six months) without conducting auctions. For example, the intermediary entity may instead request a single quote from each of multiple insurance providers each time that a current policy term is drawing to a close, and select the provider with the “best” (e.g., lowest price) quote for the next term without entertaining a second round of bids.

The intermediary entity may obtain revenue in various different ways according to different embodiments. For example, the insurance provider that offers or submits a winning bid in an auction might pay the intermediary entity a flat administrative fee, and/or a commission that includes a percentage of the insurance premium(s) for the affinity group. Alternatively, or additionally, each member of the affinity group might pay the intermediary entity an annual membership fee.

In addition to, or instead of, auctioning the opportunity to provide insurance policies to affinity groups, auctions may be conducted for the opportunity to reinsure at least a portion of liabilities associated with such policies. For example, a winning provider (or the intermediary entity, via a contractual agreement with the winning provider) may auction the opportunity to reinsure at least a portion of the liabilities associated with the insurance policies of the members of a particular affinity group, either before or after those policies are put into effect.

By using one or more of the techniques described above, consumers may be able to obtain insurance coverage at the most competitive price available, on a continuing basis and without the hassles of shopping for insurance on their own. Moreover, participating insurance providers may be able to attract larger groups of consumers, including those who otherwise may not have considered those providers for their insurance needs. In embodiments where reinsurance for existing policies is auctioned, insurance providers may be able to mitigate some of the risks associated with their policies on relatively advantageous terms. For their part, participating reinsurers may gain access to more reinsurance transaction opportunities.

II. Exemplary Environment for Automatically Obtaining and Maintaining Insurance Coverage

FIG. 1 depicts an example environment 10 including components associated with obtaining and/or maintaining insurance coverage, according to one embodiment. As illustrated in FIG. 1, the environment 10 may include M computing devices 12-1 through 12-M associated with M respective frequent shoppers (e.g., thousands of consumers, millions of consumers, etc.). Each of the computing devices 12-1 through 12-M may be any suitable type of computing device having wired and/or wireless communication capabilities, such as a personal computer, tablet, phablet, smartphone, etc.

The environment 10 may also include a computing system 14 associated with an intermediary entity. The computing system 14 may include one or more servers of the intermediary entity, or may include a plurality of networked computing devices that have an appearance of a single, logical computing device or system, e.g., a group of cloud computing devices. The computing system 14 may be communicatively coupled to computing devices 12-1 through 12-M via a network (not shown in FIG. 1). The network may be a single communication network, or may include multiple communication networks of one or more types (e.g., one or more wired and/or wireless local area networks (LANs), and/or one or more wired and/or wireless wide area networks (WANs) such as the Internet), for example.

It is noted that while the computing system 14 and the environment 10 are discussed above with reference to individuals or end-consumers who desire to procure insurance, the techniques and features of the computing system 14 and the environment 10 may easily be applied to consumers that are not individuals or end-consumers who desire to procure insurance, but instead are organizations, companies, or other entities that desire to procure insurance for a pre-defined group of individuals or end-consumers, and/or that desire to procure insurance for a pre-defined group of assets or services that are to be provided to individuals or end-consumers (e.g., as previously discussed). For example, computing devices 12-1 through 12-M may include individual or end-consumers, and/or may include consumers that are organizations, companies, or other entities, e.g., as discussed above. Indeed, any of the methods, systems, features, and/or techniques discussed herein may apply equally to consumers who are individuals or end-consumers, and to consumers that are organizations, companies, or other entities.

At any rate, the environment 10 may also include computing systems 16-1 through 16-4 where, in this example scenario, computing systems 16-1 and 16-2 are associated with respective insurance providers and computing systems 16-3 and 16-4 are associated with respective reinsurance providers. The reinsurers may be reinsurance companies that have agreements in place with an entity that is licensed to write insurance and can legally service insurance claims (e.g., similar to the providers associated with computing systems 16-1 and 16-2), for example. In other embodiments and/or scenarios, computing systems 16 may include computing systems associated with more or fewer insurance providers (e.g., no insurance providers, five insurance providers, etc.), computing systems associated with more or fewer reinsurers (e.g., no reinsurers, five reinsurers, etc.), and/or computing systems associated with one or more other entity types (e.g., investment fund management companies seeking arbitrage opportunities, etc., which may also have agreements with insurance providers to enable participation in the auction).

Each of the computing systems 16-1 through 16-4 may include one or more servers or computing devices of the respective insurance provider or reinsurer, and may be communicatively coupled to computing system 14 via a network (not shown in FIG. 1). The network may be a single communication network, or may include multiple communication networks of one or more types (e.g., one or more wired and/or wireless LANs, and/or one or more wired and/or wireless WANs such as the Internet), for example. Each of the insurance providers associated with computing systems 16-1 and 16-2 may be a company providing a particular type or types of insurance, such as automobile or other vehicle insurance, home or condominium insurance, personal property insurance and/or life insurance, for example. Similarly, the reinsurers associated with computing systems 16-3 and 16-4 may be companies that reinsure policies for a particular type or types of insurance. Alternatively, the reinsurers may not be restricted to reinsuring particular insurance types.

The computing system 14 may include various units, including a frequent shopper profiling unit 20, a frequent shopper grouping unit 22, a policy procurement unit 24 and a notification unit 26. Each of some or all of the units 20, 22, 24 and 26 may be (or may include) a respective set of one or more computing devices or processors that executes software instructions to perform the corresponding functions described herein. Alternatively, each of some or all of the units 20, 22, 24 and 26 may be or include a respective component of software that is stored on one or more computer-readable media (e.g., a random access memory (RAM) and/or read-only memory (ROM) of the computing system 14) and executed by one or more processors of the computing system 14 to perform the corresponding functions described herein. Further, one or more of the units may be combined into a single unit, or may be omitted. In various different embodiments, for example, the computing system 14 does not include frequent shopper grouping unit 22 and/or notification unit 26.

Generally, in one embodiment, frequent shopper profiling unit 20 collects information regarding the consumers operating computing devices 12-1 through 12-M, and stores the collected information in a frequent shopper profile database 30 that includes a separate profile for each shopper/consumer. The frequent shopper profile database 30 may be any suitable type of persistent memory. Frequent shopper profiling unit 20 may obtain the information in any of one or more ways. For example, frequent shopper profiling unit 20 may obtain demographic information (e.g., gender, birth date) and information about consumers' properties (e.g., makes, models and years of automobiles, etc.) via on-line forms (e.g., insurance applications and/or reviews) filled out by the consumers using computing devices 12-1 through 12-M. The frequent shopper profiling unit 20 may provide the on-line forms as one or more web pages (e.g., HTML files, JavaServer Pages files, etc.) stored in a memory of the computing system 14, and the consumers may use web browser applications executing on the computing devices 12-1 through 12-M to access the web page(s), for example. Via the on-line forms, or via other suitable means, frequent shopper profiling unit 20 may also collect insurance preferences and/or requirements of the various consumers. For example, each consumer may enter his or her preferred or required coverage types, coverage limits, deductibles, insurance provider ratings (e.g., AAA), and/or any other preference or requirement relating to insurance. A consumer may indicate that he or she prefers to have a policy through an insurance company that offers live insurance agents, for example, that he or she prefers to shop for new insurance on a particular time basis (e.g., every six months or annually), and/or that he or she prefers to maintain a policy with a single insurance company for at least some threshold time (e.g., at least one year, or indefinitely) in order to avoid hassles such as new insurance cards and passwords, etc. In an alternative embodiment and/or scenario, some or all of the consumers provide information via physical application forms, and some or all of the computing devices 12-1 through 12-M may be omitted in the example environment 10. Generally, the frequent shopper profiling unit 20 may store the individual preferences of a particular customer consumer (or indications thereof) in a respective consumer profile of the frequent shopper profile database 30.

Further, frequent shopper profiling unit 20 may collect other information that is also to be stored in frequent shopper profile database 30. For a consumer already having an insurance policy with an insurance provider (e.g., one of the insurance providers associated with computing systems 16-1 or 16-2), for example, frequent shopper profiling unit 20 may receive or obtain information from the consumer's insurance account and/or policy. For example, claims information from that provider (e.g., number and/or dates of past claims, past claim payouts made to or on behalf of the consumer, etc.) may be obtained. Alternatively, or additionally, frequent shopper profiling unit 20 may receive telematics data indicative of a consumer's driving performance (e.g., acceleration data, braking data, cornering data, etc.). Generally, the frequent shopper profiling unit 20 may store individual characteristics of a particular customer or consumer (or indications thereof) in a respective customer profile within the frequent shopper profile database 30. Individual customer characteristics may include, for example, age, account status (for customers who have insurance policies that are in force), marital status, education level, occupation, finances or income, driving history, accident history, vehicle type, home type, geographical location, risk score, driving behavior, and/or other individual customer characteristics. Frequent shopper grouping unit 22 may utilize at least some of the consumer information stored in frequent shopper profile database 30 to form one or more affinity groups, and store indications of which of the consumers belong to which affinity groups in an affinity group database 32. The affinity group database 32 may be any suitable type of persistent memory (e.g., the same memory storing frequent shopper profile database 30). Frequent shopper grouping unit 22 may place the consumers into the affinity group(s) based upon the criteria of the groups, which may reflect consumer preferences and/or requirements, insurance provider requirements and/or classifications, and/or behavioral and/or attitudinal segmentation of consumers (e.g., as determined using telematics data indicating driving performance/behaviors), for example.

Policy procurement unit 24 may conduct an automated auction in order to obtain insurance policies for the members of each of the one or more affinity groups. For a given affinity group, policy procurement unit 24 may send information defining the group membership criteria, and/or information about the individual members (e.g., profile information stored in frequent shopper profile database 30), to each of the computing systems 16-1 through 16-4, along with a request for insurance premium quotes. After analyzing the information, one or more of the insurance providers and/or reinsurers (and/or other entities) may decide to bid on the provision of insurance to the affinity group, and policy procurement unit 24 may receive the bid(s) from the respective ones of computing systems 16-1 through 16-4. Policy procurement unit 24 may send each received bid to all others of the computing systems 16-1 through 16-4, and bidding may continue in an iterative fashion until auction termination criteria have been met (e.g., until a predetermined amount of time elapses, or until a predetermined amount of time since the last bid elapses, etc.). The insurance provider or reinsurer (or other entity) having the best bid (e.g., lowest price and/or best non-price features) at the time the auction terminates may be granted the ability to provide insurance policies to the members of the affinity group (e.g., directly, if an insurance provider, or through a licensed/authorized insurance provider, if a reinsurer or other entity).

The intermediary entity may be authorized to enter a binding contract for the policy/policies on behalf of the consumers, or may require some confirmation or election by the members of the affinity group. If a contract is automatically established via the agency of the intermediary entity, notification unit 26 may cause the members of the affinity group to be informed of the new insurance provider and the new policy (e.g., by email, letter, etc.). If consumer confirmation or election is required, notification unit 26 may instead cause the members of the affinity group to be sent an indication of the best offer or offers and the corresponding providers, along with a request for confirmation or election. Policy procurement unit 24 may then form the contract with the winning insurance provider after the confirmation or election, for example, or cause notification unit 26 to transmit a notification or other data (directly or indirectly) to the winning insurance provider to cause the winning provider to form the contract.

In some embodiments, policy procurement unit 24 may also be responsible for renewing existing insurance policies, or switching to a new provider and policy if a better rate and/or other policy features can be found. For example, policy procurement unit 24 may store policy term data for all procured policies in a term schedule database 34 (which may be any suitable type of persistent memory, such as the memory storing frequent shopper profile database 30 and/or affinity group database 32), and may access term schedule database 34 to detect when policy terms are nearing their end (e.g., one month before expiration, or one week before expiration, etc.). When policy terms are nearing their end for the members of an affinity group, policy procurement unit 24 may conduct a new auction among the insurance providers and/or other entities (possibly including more, fewer and/or different entities than had participated in the previous auction), and a new winner may be identified. If the winning provider (or a provider associated with the winning entity) is the same as the current provider, the policies may simply be renewed. Again, notification unit 26 may cause the members of the affinity group to be notified of the renewal (or to be notified of the switch to a new provider), or may first request confirmation or an election from the members. In some embodiments, the affinity group may be reviewed and/or adjusted (e.g., members added and/or removed) by frequent shopper grouping unit 22 prior to each auction, to help ensure that the affinity group criteria continue to be met by all of its members.

In some embodiments and/or scenarios, all members of a single affinity group are provided with policies that have identical start and stop dates. In other embodiments and/or scenarios, at least some of the members may be provided with policies having different start and/or stop dates (e.g., based upon requested start and/or stop dates stored in the consumer profile database 30, etc.). In still other embodiments, all members of a single affinity group are covered under a single, group policy.

In some embodiments, frequent shopper grouping unit 22 is omitted, and the computing system 14 only attempts to obtain insurance coverage for consumers on an individual basis. In one such embodiment, policy procurement unit 24 may obtain the best rate for each consumer not by conducting an auction, but rather by automatically requesting a single quote from each of the insurance providers, and taking the best quote (e.g., the lowest premium, and/or a quote with other features best matching the consumer's preferences and/or requirements). Similar to the auction embodiments described above, policy procurement unit 24 may detect when a renewal time is approaching, and automatically request a new round of quotes from the insurance providers at that time to determine whether to renew the consumer's current policy or to initiate a new policy with a new provider. Notification unit 26 may simply notify the consumer of the policy and provider for each upcoming term, or may first request confirmation or election of a particular policy/provider.

III. Exemplary Computer System for Automatically Obtaining and/or Maintaining Insurance Coverage

FIG. 2 depicts an example computer system 300 in which the techniques described herein may be implemented, according to one embodiment. In one embodiment, the computer system 300 may be included in the system 10 of FIG. 1. For example, any one or more of the units 20-26 may comprise one or more instances of the computer system 300, or the intermediary entity 14 may comprise one or more instances of the computer system 300. The computer system 300 of FIG. 2 includes a computing device in the form of a computer 310. Components of the computer 310 may include, but are not limited to, a processing unit 320, a system memory 330, and a system bus 321 that couples various system components including the system memory 330 to the processing unit 320. The system bus 321 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, or a local bus, and may use any suitable bus architecture. By way of example, and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus (also known as Mezzanine bus).

Computer 310 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computer 310 and includes both volatile and nonvolatile media, and both removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes tangible, volatile and nonvolatile, removable and non-removable media implemented in any method or technology for non-transitory storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, FLASH memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 310. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared and other wireless media. Combinations of any of the above are also included within the scope of computer-readable media.

The system memory 330 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 331 and random access memory (RAM) 332. A basic input/output system 333 (BIOS), containing the basic routines that help to transfer information between elements within computer 310, such as during start-up, is typically stored in ROM 331. RAM 332 typically contains data and/or program modules that are immediately accessible to, and/or presently being operated on, by processing unit 320. By way of example, and not limitation, FIG. 2 illustrates operating system 334, application programs 335, other program modules 336, and program data 337.

The computer 310 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 2 illustrates a hard disk drive 341 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 351 that reads from or writes to a removable, nonvolatile magnetic disk 352, and an optical disk drive 355 that reads from or writes to a removable, nonvolatile optical disk 356 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 341 may be connected to the system bus 321 through a non-removable memory interface such as interface 340, and magnetic disk drive 351 and optical disk drive 355 may be connected to the system bus 321 by a removable memory interface, such as interface 350.

The drives and their associated computer storage media discussed above and illustrated in FIG. 2 provide storage of computer-readable instructions, data structures, program modules and other data for the computer 310. In FIG. 2, for example, hard disk drive 341 is illustrated as storing operating system 344, application programs 345, other program modules 346, and program data 347. Note that these components can either be the same as or different from operating system 334, application programs 335, other program modules 336, and program data 337. Operating system 344, application programs 345, other program modules 346, and program data 347 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 310 through input devices such as cursor control device 361 (e.g., a mouse, trackball, touch pad, etc.) and keyboard 362. A monitor 391 or other type of display device is also connected to the system bus 321 via an interface, such as a video interface 390. In addition to the monitor, computers may also include other peripheral output devices such as printer 396, which may be connected through an output peripheral interface 395.

The computer 310 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 380. The remote computer 380 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 310, although only a memory storage device 381 has been illustrated in FIG. 2. The logical connections depicted in FIG. 2 include a local area network (LAN) 371 and a wide area network (WAN) 373, but may also include other networks. Such networking environments are commonplace in hospitals, offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 310 is connected to the LAN 371 through a network interface or adapter 370. When used in a WAN networking environment, the computer 310 typically includes a modem 372 or other means for establishing communications over the WAN 373, such as the Internet. The modem 372, which may be internal or external, may be connected to the system bus 321 via the input interface 360, or other appropriate mechanism. The communications connections 370, 372, which allow the device to communicate with other devices, are an example of communication media, as discussed above. In a networked environment, program modules depicted relative to the computer 310, or portions thereof, may be stored in the remote memory storage device 381. By way of example, and not limitation, FIG. 2 illustrates remote application programs 385 as residing on memory device 381.

In some configurations, the computer 310 may be included in a plurality of networked computers or computing devices that have the logical appearance as a single, integral computing node, e.g., a cloud computing system. For example, the application programs 345, other program modules 346 and/or program data 337 may be stored in and executed by the logical, single computing node.

The techniques for automatically obtaining and/or maintaining insurance coverage (and/or for obtaining reinsurance) described herein may be implemented in part or in their entirety within a computer system such as the computer system 300 illustrated in FIG. 2. The computer 310 may be a server or computing device of an intermediary entity (e.g., within the computing system 14 of FIG. 1), and the remote computer 380 may be a server or computing device of an insurance provider or reinsurer (e.g., within one of the computing systems 16-1 through 16-4 of FIG. 1), for example. In some such embodiments, the LAN 371 may be omitted (e.g., communications may between computer 310 and computer 380 may only occur via WAN 373). Application programs 335 and 345 may include programs that implement the frequent shopper profiling unit 20, frequent shopper grouping unit 22, policy procurement unit 24 and/or notification unit 26 of FIG. 1, for example. Frequent shopper profile database 30, affinity group database 32 and/or term schedule database 34 may be stored on hard disk drive 341, magnetic disk 352 or optical disk 356, for example.

In operation, the computer 310 may receive demographic, property, preference and/or other information from consumer computing devices (not shown in FIG. 2), form affinity groups based upon that information, provide the remote computer 380 (and one or more other, similar computers of other insurance providers) at least some of the consumer information along with a request for bids, and receive bids from the remote computer 380 (and/or from one or more other, similar computers of other insurance providers). The computer 310 may then determine the winning bid and notify the consumers in the affinity group by sending messages (e.g., emails) to the appropriate consumer computing devices, for example.

IV. Exemplary Computer-Implemented Method

FIG. 3 illustrates an exemplary computer-implemented method, e.g., for auctioning groups of insurance policies 400 or providing insurance to groups of frequent shoppers (e.g., consumers or customers). In one embodiment, at least a portion of the method 400 may be performed by the system 10 of FIG. 1 and/or by the computer system 300 of FIG. 2. The method 400 may include, via one or more processors, computing devices, or servers: analyzing a set of insurance frequent shoppers by their individual characteristics and/or insurance policy preferences 402; dividing and/or classifying the set of insurance frequent shoppers into affinity groups based upon the frequent shoppers' individual characteristics and/or preferences 404; auctioning or offering for sale the opportunity to provide insurance to one or more affinity groups 406; receiving and comparing one or more bids 408; accepting one or more winning bids 409; notifying frequent shoppers of new insurance policies and/or changes to existing insurance policies, premiums, discounts, etc. 410; automatically detecting driving events or other events that may impact a risk score and/or a profile of one or more frequent shoppers associated with a particular affinity group 412; updating the frequent shopper(s)′ risk score(s) and/or profile(s) 414; and/or updating the particular affinity group with which the frequent shopper(s) is/are associated, and/or moving the frequent shopper(s) to be associated with another affinity group 416. After a number of frequent shoppers have been moved to new or different affinity groups, another auction of the new or updated affinity groups may be held 406, and the process may continue 408, 409, 410, 412, 414, 416, etc. The method may include additional, fewer, or alternate actions, including those discussed elsewhere herein.

The method 400 may include (e.g., via one or more processors, computing devices, or servers) analyzing insurance frequent shoppers by their individual characteristics and/or insurance policy preferences 402. In one embodiment, frequent shopper characteristics and/or insurance policy preferences (or indications thereof) may be stored in the frequent shopper profile database 30, so that each customer profile stored therein includes indications of individual customer characteristics and/or preferences of the respective customer. The analysis of frequent shoppers may include analysis of frequent shoppers' insurance policy preferences, such as by insurance coverages, deductibles, and/or limits typically desired or requested by individual customers. For instance, a group of customers may prefer a $500 deductible for homeowner's and/or automobile insurance. Another group of customers may prefer a $1,000 deductible for homeowner's and/or automobile insurance. As another example, groups of customer may prefer to have: $300,000 (or other amounts) of liability coverage for various insurance policies; certain types of coverages and/or insurance; certain levels of deductibles; $250,000, $500,000, or other amounts of coverage for health or life insurance; etc. Additionally or alternatively, the analysis of frequent shoppers may include analysis of other preferences, such as a particular characteristic of an insurance company (e.g., rating, web presence, proximity of local agent office, whether usage-based insurance (UBI) and/or autonomous vehicle (AV) insurance is offered, claim experience, whether multi-line discounts are offered, etc.) and/or claims expectations. As another example, the analysis of frequent shoppers may include analysis of preferences for how often the intermediary entity should “shop around” (e.g., conduct a new auction) for each customer. Thus, groups of similarly minded customers may be grouped together based upon similar preferences of insurance parameters and/or terms.

Additionally or alternatively, frequent shoppers may be grouped together in affinity groups based upon similar customer characteristics. Characteristics that may be analyzed by the one or more processors may include customer risk, risk scores, age, account status (e.g., when a customer is presently insured), marital status, finances or income, education level, occupation, driving history, accident history, geographical location, risk score, vehicle type, home type, and/or other individual characteristics of customers. Also, in some embodiments, telematics data associated with a customer's driving behavior may be analyzed for use in classifying or grouping customers/drivers. One or more processors may access a database and/or customer profiles that are stored in one or more memory units (local and/or remote memory units) to analyze the customer characteristics and/or customer insurance policy preferences, for example.

The method 400 may include (e.g., via the one or more processors, computing devices or servers), dividing, grouping, and/or classifying frequent shoppers into affinity groups 404. For example, one or more insurance customers, insurance applications, insurance customer accounts, and/or insurance policies may be grouped together or segmented into an affinity group, also referred to interchangeably (with respect to the method 400) as an insurance policy group, an insurance customer group, or an insurance group. Based upon the analysis of customers mentioned above (such as computer analysis of customer characteristics, customer insurance policy preferences, and/or telematics data), the frequent shoppers may be divided into affinity groups of frequent shoppers having similar characteristics and/or preferences. For instance, one affinity group of automobile insurance customers may be defined or characterized as (1) low risk drivers or drivers with a risk score within a given range; (2) owners of a certain type of vehicle or vehicles; (3) living within a particular geographical location (e.g., a given state, city, or zip code); (4) having one or more deductible preferences; (5) having one or more coverage preferences; (6) having one or more common characteristics (age, education, marital status, occupation, etc.); (7) having similar driving or accident histories, and/or lack of vehicle accidents; and/or (8) other common factors.

In one embodiment, insurance customer or policy groups may additionally or alternatively be defined by behavioral and attitudinal segmentation and/or customer criteria, such as occupation, risk characteristics, insurance claims expectations, insurance company ratings, and/or telematics data gathered from or associated with customer vehicles or customer driving behavior. Other customer or policy groups or segments may be defined, including those discussed elsewhere herein.

In one embodiment, an indication of each insurance policy group, an indication of the one or more consumers associated with each insurance policy group, and/or an indication of the one or more preferences and/or characteristics that corresponded to the formation of each insurance policy group may be stored. For example, the frequent shopper grouping unit 22 may store one or more of said indications in the affinity group database 32.

The method 400 may include (e.g., via the one or more processors, computing devices or servers), auctioning or offering for sale the opportunity to provide insurance for one or more of the affinity groups 406. Each affinity group of insurance customers having common characteristics and/or insurance policy preferences may be presented to potential bidders (e.g., to at least some of the entities associated with computing systems 16-1 to 16-4) via an electronic or online auction. For instance, the one or more processors, computing devices or servers may cause a particular affinity group associated with a given group of insurance customers (characterized by customer characteristics, insurance policy preferences, and/or telematics data, for instance) to be presented and/or offered for sale on remote display screens (such as via the internet or a secure communications network) of at least some of the computing systems 16-1 to 16-4. Additionally or alternatively, an indication of the particular insurance group, the given group of insurance customers associated therewith, and/or an indication of the one or more individual preferences and/or characteristics based upon which the group was formed may be provided to the computing systems 16-1 to 16-4, and the computing systems 16-1 to 16-4 may generate their respective bids based upon this information.

The method 400 may include (e.g., via the one or more processors, computing devices or servers), receiving and/or comparing one or more bids 408. Bidders for the various groups of similarly situated and/or like-minded frequent shoppers (such as grouped by low or medium risk drivers, insureds with the same preferences for deductibles or coverages, insureds having similar driving behaviors (as evidenced by telematics data), etc.) may submit their bids via remote computers. The bids may be received by a processor or server associated with the entity running the auction via wireless or wired communication and/or data transmission.

The method 400 may include, via the one or more processors, accepting a respective bid for purchase and/or offer for sale for one or more of the affinity groups 409. For example, an accepted or winning bid may be determined based upon one or more criteria, such as cost, overall match to affinity group members (e.g., based upon customer characteristics, insurance policy preferences, and/or telematics data, for instance), and/or other criteria. In one embodiment, the accepted or winning bid may be determined based upon a prioritization of the one or more criteria. In some cases, upon acceptance of a winning bid, the method 400 may include updating existing insurance policies, rates, premiums, discounts, etc. and/or providing new insurance policies to consumers associated with the affinity group based upon the winning bid. The updates to existing insurance policies and/or the establishment of new insurance policies may provide lower cost insurance to the respective insureds, e.g., to at least some of the consumers associated with the affinity group. Further, the updates to the existing insurance policies and/or the establishment of the new insurance policies may be more reflective of the actual risk (or lack thereof) to at least some respective insureds than were their previous insurance policies (if any). Still further, the updates to the existing insurance policies and/or the establishment of the new insurance policies may be more reflective of the updated or changed preferences and/or the characteristics of at least some of the individual insurance customers associated with the affinity group.

The method 400 may include, via the one or more processors, computing devices or servers, notifying frequent shoppers of new insurance policies, premiums, rates, discounts, etc. 410. As previously discussed, after a winning bid has been determined or selected 409, new insurance policies, rates, premiums, discounts, etc. may be determined or updated. New insurance policies and associated information may be communicated to the insureds that may be impacted by the auction, such as notified of reduced premiums and/or increased discounts (such as increased discounts for low risk driving behavior).

The method 400 may include, via the one or more processors, computing devices or servers, automatically detecting driving events or other events that may impact a risk associated with a frequent shopper 412, e.g., risk-impacting events. Over time, risk associated with each frequent shopper may change. For example, a customer may engage in low risk behavior, and/or may not be involved with automobile accidents, and/or may not report any insurance claims. On the hand, another customer may be involved in a high number of automobile accidents and/or otherwise engage in risky driving behavior. As a result, risk associated with various customers (or risk scores) may be lowered or increased over time based upon data analysis by one or more processors, such as by a processor associated with an insurance provider and with the permission of the insured. For instance, insureds engaging in low-risk behavior may desire for their information to be analyzed by an insurance provider to achieve a discount on various insurance products. The data may be gathered by one or more processors, such as gathered from a customer profile and/or from third party sources, such as a DMV (Department of Motor Vehicles). Additionally or alternatively, the data may be telematics data that is gathered by a mobile device (e.g., smart phone) and/or a conventional telematics device that plugs into an electrical or computer system of a vehicle, or otherwise physically connects to a vehicle.

The method 400 may include, via the one or more processors, computing devices or servers, updating the frequent shopper's risk score and/or profile 414. Based upon the data gathered and/or collected by one or more processors, each frequent shopper's profile, risk profile, and/or risk score may be updated to reflect low or high-risk behavior. Additionally or alternatively, a frequent shopper's profile may reflect more recent or changed customer preferences for various insurance policy coverages, deductibles, limits, etc. The frequent shopper profile may also be updated to reflect more recent or current customer preferences for various types of insurance or insurance products that the frequent shopper may be interested in, such as life or health insurance, or renters versus home insurance. The frequent shopper profile may be updated to reflect changed customer characteristics, e.g., changes in driving behaviors, address, income, age, etc. As another example, a frequent shopper's risk score or profile for automobile insurance may be updated based upon a number of miles driven (e.g., as determined based upon vehicle telematics data), a lack of accidents for a given period of time, receiving one or more moving violations, and/or involvement in one or more vehicle accidents. The cause of the vehicle accidents may also be factored into the risk score and/or frequent shopper profile.

The method 400 may include, via the one or more processors and based upon the updated frequent shopper risk score and/or profile, updating the affinity group and/or moving the frequent shopper to a new affinity group 416. For instance, based upon a frequent shopper's updated profile and/or risk score, an individual frequent shopper may be moved to or associated with, via one or more processors, a new or different affinity group. Additionally or alternatively, based upon a frequent shopper's most recent preferences for insurance policy coverages, deductibles, or limits, and/or types of insurance products, an individual frequent shopper may be moved or re-assigned to, by the one or more processors, a new or different affinity group.

The method 400 may include, via the one or more processors, computing devices or servers, after a number of frequent shoppers have been moved to new or different risk-based groups, having or holding another auction of the new or updated groups 406, and then the process may continue (according to one or more additional iterations of the blocks shown in FIG. 3). For instance, after a number of frequent shoppers have been moved to a new or different affinity group based upon their changed personal characteristics (education, marital status, age, driving record or history, etc.) and/or changed insurance policy preferences (new interest in life or health insurance, new interest in home owners insurance, changed policy deductibles or coverages, interest in using telematics devices and/or gathering telematics data, etc.), a new electronic or online auction of the new or revised/updated group of insurance policies associated with those frequent shoppers for which personal characteristics and/or insurance policies have changed may be held, such as under the direction of one or more processors. The auction may, or may not, result in the members of the affinity group switching to a new insurance provider.

Depending on the embodiment and/or scenario, the intermediary entity may hold new auctions for a particular affinity group according to a set schedule (e.g., every six months), based upon changes to the constituency of the affinity group (e.g., as described above), or based upon a consumer preference associated with the affinity group.

V. Exemplary Method of Auctioning Insurance Policies

In one aspect, a computer-implemented method of auctioning groups of insurance policies via an electronic or communications network may be provided. The method may include: (1) analyzing, via one or more processors, multiple insurance applications, accounts, and/or policies for individual insurance policy preferences and/or individual characteristics of multiple customers or consumers; (2) dividing or segmenting, via the one or more processors, the multiple customers or consumers into various insurance groups, groupings, or segments based upon the individual insurance policy preferences and/or characteristics; (3) auctioning, via the one or more processors, such as via one or more electronic or communications networks, the opportunity to provide insurance for one or more of the various insurance groups or segments; (4) receiving, via the one or more processors, bids for purchase and/or offers of insurance for one or more of the various insurance groups; (5) accepting, via the one or more processors, one of the bids for purchase and/or offers; and/or (6) updating, via the one or more processors, existing insurance policies and/or establishing new insurance policies for at least some of the insureds associated with an insurance policy group corresponding to the accepted bid, thereby providing lower cost insurance and/or insurance more reflective of actual risk, or lack thereof, to the at least some of the insureds. The method may include additional, fewer, or alternate actions, including those discussed elsewhere herein.

For instance, the individual insurance policy preferences may include individual consumer preferences for insurance policy coverages, deductibles, limits, term lengths, and/or other insurance parameters; and the insurance groups or segments each may be associated with automobile, life, health, renters, home, pet, and/or burial insurance. The individual insurance policy preferences may include individual consumer preferences for claims expectations, telematics use, and/or insurance company ratings, in one embodiment.

The individual consumer characteristics may relate to a consumer's age, account and/or policy status, marital status, education, occupation, finances or income, driving history, accident history, vehicle type, home type, geographical location (state or city), risk, risk scores, and/or other individual characteristics. Additionally or alternatively, the consumer characteristics may relate to individual driving behavior that is based upon computer analysis of telematics data. The telematics data may be associated with an individual driver or insured, and/or may be gathered or collected from a mobile device or conventional telematics device that plugs into or otherwise is communicatively connected to an electrical or computer system of a vehicle associated with the individual driver or insured.

The method may further include detecting an event, or lack thereof, that impacts a risk or risk score of an insured, such as by accessing a third party or government database over a communication network and/or by analyzing telematics data corresponding to the insured. The risk score may be stored, for example, in a consumer profile of the insured. The method may also include (i) updating the consumer profile and/or the risk score of an insured based upon the detected event; (ii) updating the insurance policy group or grouping to which the insured belongs or reassigning the insured to another insurance policy group based upon the updated consumer profile or risk score, and/or (iii) offering for auction the opportunity to provide insurance for the updated or another insurance group.

VI. Exemplary Systems for Auctioning Insurance Policies

In one aspect, a system, e.g., for auctioning insurance policies, may be provided. The system may include one or more persistent memories storing a consumer profile database including a plurality of consumer profiles; one or more communication interfaces to communicate with remote devices via one or more networks; and one or more processors. The system may also include one or more non-transitory, computer-readable or computer-executable media storing instructions thereon. The instructions, when executed by the one or more processors, may cause the system to analyze stored consumer profiles of multiple insurance consumers to discover or determine consumer insurance policy preferences and/or consumer characteristics. For example, the consumer insurance policy preferences may include individual consumer preferences for insurance policy coverages, insurance policy deductibles, insurance policy limits, claims expectations, telematics use, insurance parameters, and/or insurance company ratings; and the multiple insurance consumers (and their respective applications, accounts, and/or policies) may be associated with automobile, life, health, renters, home, pet, and/or burial insurance. Additionally or alternatively, the consumer characteristics may relate to or be indicative of consumer age, account status, marital status, education, occupation, finances or income, driving history, accident history, vehicle type, home type, location (e.g., state or city), risk, risk scores, and/or other factors. For example, the consumer characteristics may relate to or be indicative of individual driving behavior that is based upon computer analysis of telematics data, where the telematics data may be associated with a particular driver or insured, and the telematics data may be gathered or collected from mobile device or conventional telematics device that plugs into or is otherwise communicatively connected to an electrical or computer system of a vehicle corresponding to the particular driver or insured.

Further, the instructions, when executed by the one or more processors, may cause the system to divide or segment the multiple insurance consumers into various insurance policy groups or groupings based upon the individual/consumer insurance policy preferences and/or individual/consumer characteristics; auction (such as via an electronic or communications network using the one or more communication interfaces) the opportunity to provide insurance to consumers included in one or more of the various insurance policy groups or groupings; receive bids for purchase and/or offers for insurance for one or more of the various insurance policy groups or groupings; accept one of the bids for purchase and/or offers for insurance; and/or update insurance policies for at least some of the insureds associated with a particular insurance policy group corresponding to the accepted bid, and/or establish new insurance policies for at least some of the insureds associated with the particular insurance policy group, thereby providing lower cost insurance and/or insurance that is more reflective of actual risk, or lack thereof, to one or more insureds associated with the particular insurance policy group.

In one embodiment, the system may include further instructions stored on the computer-readable or computer-executable media that, when executed by the one or more processors, may cause the system to detect an event (or lack thereof) that impacts a risk score of a particular insured, for example, by accessing a third party or government database over a communication network, and/or by analyzing telematics data. In some cases, the further instructions, when executed, may cause the system to update the risk score of the particular insured and/or update a consumer profile of the particular insured in which the risk score is stored, e.g., based upon the detected event or lack thereof; update, based upon the updated consumer profile or risk score for the particular insured, the insurance policy group or grouping to which the particular insured belongs; and/or offer for auction the opportunity to provide insurance for the insurance policy group or grouping that includes a particular insured with the updated consumer profile or risk score. The system may include additional, fewer, or alternate elements or components, including those discussed elsewhere herein.

In another aspect, a system (e.g., for auctioning insurance policies) may be provided. The system may include one or more persistent memories or data storage devices storing a consumer profile database including a plurality of consumer profiles, and one or more communication interfaces to communicate with remote devices via one or more networks.

The system may include a consumer grouping unit configured to group or segment consumer profiles that are stored in the consumer profile database and that correspond to multiple insurance consumers, applications, accounts, and/or policies. The grouping or segmenting performed by the consumer grouping unit may be based upon insurance policy preferences and/or consumer characteristics of individual consumers, and one or more insurance policy groups or segments may be formed. For example, the insurance policy preferences may include individual consumer preferences for insurance policy coverages, insurance policy deductibles, insurance policy limits, claims expectations, telematics use, and/or insurance company ratings. The multiple insurance consumers, applications, accounts, and/or policies may be associated with the vehicle, life, health, renters, home, pet, and/or burial insurance. Additionally or alternatively, the consumer characteristics may relate to or may be indicative of consumer age, account or policy status, marital status, education, occupation, finances or income, driving history, accident history, vehicle type, home type, location (e.g., state or city), risk, risk scores, and/or other factors. For example, the consumer characteristics may relate to or may be indicative of individual driving behavior that is based upon computer analysis of telematics data. The telematics data may be associated with an individual driver or insured, and/or may be gathered or collected from a mobile device or conventional telematics device that is plugged into or otherwise communicatively connected to an electronics or computer system of a vehicle corresponding to the individual driver or insured.

The system may include a policy procurement unit that is configured to auction or offer for sale (e.g., by using the one or more communication interfaces and one or more electronic or communications networks) an opportunity to provide insurance for consumers associated with a particular insurance policy group, and/or to cause information about the insurance policy preferences and/or consumer characteristics associated with the consumers associated with the particular insurance policy group to be remotely displayed on one or more computer screens for view by potential bidders (e.g., by using the one or more communication interfaces and one or more electronic or communications networks). The policy procurement unit may further be configured to receive bids for purchase and/or offers of insurance for the particular insurance policy group, accept one of the bids for purchase and/or offers of insurance for particular the insurance policy group, and/or update existing insurance policies and/or establish new insurance policies for insureds associated with the particular insurance policy group, thereby facilitating providing lower cost insurance to at least some of the insureds, and/or providing insurance to at least some of the insureds that is more reflective of (i) actual risk (or lack thereof) of the insureds, (ii) the current insurance policy preferences of the insurance, and/or (iii) the current consumer characteristics of the insurance.

In some embodiments, the system may be further configured to detect an event (or lack thereof) that may impact a risk score of a particular insured, for example, by accessing a third party or government database over communications network, and/or by analyzing telematics data. Additionally, the system (e.g., the consumer grouping unit and/or other suitable unit) may be configured to (i) update a consumer profile or a risk score of the particular insured based upon the detected event (or lack thereof), and/or (ii) update the insurance policy group or grouping to which the particular insured belongs, where the updating of the insurance policy group or grouping is based upon the updated consumer profile or risk score for the particular insured. Additionally or alternatively, the policy procurement unit (and/or other suitable unit) may be further configured to offer for auction the opportunity to provide insurance for members of the insurance policy group or grouping that includes the particular insured with the updated consumer profile or risk score. The system may include additional, fewer, or alternate elements or components, including those discussed elsewhere herein.

VII. Exemplary Usage-Based Insurance

FIG. 4 illustrates an exemplary computer-implemented method for auctioning groups of insurance policies 500 or providing insurance to groups of similarly situated consumers or customers. In one embodiment, at least a portion of the method 500 may be performed by the system 10 of FIG. 1 and/or by the computer system 300 of FIG. 2. The method 500 may include, via one or more processors, computing devices, or servers: analyzing a set of insurance customers by their individual characteristics, telematics data, and/or insurance policy preferences 502; dividing and/or classifying the set of insurance customers into UBI (Usage-Based Insurance, such as pay-by-mile or pay-by-time) groups or segments based upon the customers' individual UBI characteristics and/or preferences 504; auctioning or offering for sale the opportunity to provide insurance to one or more UBI groups 506; receiving and comparing one or more UBI bids 508; accepting one or more winning UBI bids 510; and/or notifying insurance customers of new UBI policies and/or changes to existing UBI policies, premiums, discounts, coverages, deductibles, limits, conditions, terms, etc. 512.

The method 500 may further include automatically detecting driving events or other events that may impact a risk score and/or a customer profile of a customer associated with a particular UBI group or segment 514, which may include analysis of telematics or driving behavior data (cornering, braking, speed, and/or acceleration telematics data) associated with the customer or the customer's vehicle; updating the customer's risk score or UBI profile 516; and/or updating the particular UBI group or segment with which the customer and/or vehicle is associated, and/or moving the customer and/or vehicle to be associated with another UBI group or segment 518. After a number of customers and/or vehicles have been moved to new or different UBI-related groups or segments, another auction of the new or updated groups may be held 506, the process may continue 508, 510, 512, 514, 516, 518, etc. The method may include additional, fewer, or alternate actions, including those discussed elsewhere herein.

In one aspect, a computer-implemented method for providing UBI (Usage-Based Insurance) may be provided. The method may include (1) analyzing or electronically searching, via one or more processors, multiple insurance applications, accounts, and/or policies for at least one UBI (Usage-Based Insurance) preference or characteristic of multiple individuals and/or consumers corresponding to the multiple insurance applications, accounts, and/or policies; (2) dividing or segmenting, via the one or more processors, the multiple individuals and/or consumers into multiple UBI policy groups or segments based upon the at least one UBI preference or characteristic of the multiple individuals and/or consumers; (3) auctioning, via the one or more processors and by using an electronic or communications network, an opportunity to provide UBI for one or more of the multiple UBI policy groups or segments; (4) receiving, via the one or more processors and the electronic or communications network, one or more bids for purchase and/or offers of UBI for the one or more of the multiple UBI policy groups or segments; (5) accepting, via the one or more processors, one of the bids for purchase and/or UBI offers; and/or (6) updating or providing, via the one or more processors, UBI policies for insureds associated with a particular UBI policy group or segment corresponding to the accepted bid, thereby providing lower cost insurance and/or UBI that is more reflective of actual risk, or lack thereof, to the insureds associated with the particular UBI policy group or segment. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

For instance, the at least one UBI preference of the multiple individuals and/or consumers may include preferences for at least one of insurance policy coverage, types of coverages, premiums, discounts, deductibles, limits, conditions, or other terms; and the particular UBI policy group or segment may be associated with automobile UBI. The at least one UBI preference of the multiple individuals and/or consumers may include preferences for pay-by-mile auto insurance; and the particular UBI policy group or segment may be associated with automobile UBI. Additionally or alternatively, the at least one UBI preference of the multiple individuals and/or consumers may include preferences for pay-by-time (or pay by period of time) auto insurance; and the particular UBI policy group or segment may be associated with automobile UBI. The at least one UBI preference of the multiple individuals and/or consumers may include preferences for at least one of claims expectations, telematics use, or insurance company ratings.

The at least one UBI characteristic of the multiple individuals and/or consumers may relate to, or be indicative of, at least one of consumer age, status, marital status, education, occupation, finances or income, driving history, accident history, vehicle type, home type, geographic location, risk, risk scores, or another individual characteristic.

The at least one UBI characteristic of the multiple individuals and/or consumers may relate to, or be indicative of, individual driving behavior that is based upon computer analysis of telematics data; and the telematics data associated with a particular driver, insured, or vehicle may be gathered or collected from a mobile device or from a conventional telematics device that physically connects with a vehicle corresponding to the particular driver, insured, or vehicle.

In another aspect, a computer system configured for providing UBI may be provided. The system may include one or more communication interfaces configured to communicate with remote devices via one or more electronic or communications networks; one or more processors; and one or more non-transitory, computer-readable media storing instructions that, when executed by the one or more processors, cause the system to: (1) analyze consumer profiles that are included in the consumer profile database and that correspond to multiple insurance consumers for at least one UBI (usage-based insurance) preference or characteristic of the multiple insurance consumers; (2) divide or segment the multiple UBI consumers into multiple UBI policy groups or groupings based upon the at least one UBI preference or characteristic of the multiple insurance consumers; (3) auction, via the one or more electronic or communications network and by using the one or more communication interfaces, an opportunity to provide UBI for one or more of the multiple UBI policy groups or groupings; (4) receive, at the one or more communication interfaces, one or more bids for purchase and/or offers for UBI for the one or more of the multiple UBI policy groups or groupings; (5) accept one of the bids for purchase and/or offers for UBI for the one or more of the multiple UBI policy groups or groupings; and/or (6) update existing UBI policies or provide new UBI policies for insureds associated with a particular UBI policy group or grouping corresponding to the accepted bid, thereby providing lower cost insurance and/or UBI that is more reflective of actual risk, or lack thereof, to the insureds associated with the particular insurance policy group or grouping. The computer system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

VIII. Exemplary Autonomous Vehicle Embodiments

FIG. 5 illustrates an exemplary computer-implemented method for auctioning groups of insurance policies 600 or providing insurance to similarly situated groups of consumers or autonomous vehicles (AV). In one embodiment, at least a portion of the method 600 may be performed by the system 10 of FIG. 1 and/or by the computer system 300 of FIG. 2. The method 600 may include, via one or more processors, computing devices, or servers: analyzing a set of insurance customers, or autonomous vehicles (AVs) or semi-autonomous vehicles, by their individual characteristics and/or insurance policy preferences 602. For instance, autonomous vehicles or customers may be grouped by autonomous or semi-autonomous features or technologies, telematics data, and/or policy preferences, including UBI preferences.

The method 600 may include dividing and/or classifying the set of insurance customers and/or autonomous vehicles into groups or segments based upon the customers' individual characteristics and/or preferences (including preferences for AV, AV features, and/or UBI), and/or the autonomous vehicles features or characteristics 604; auctioning or offering for sale the opportunity to provide insurance to one or more autonomous vehicle-related groups 606 (e.g., groups of autonomous vehicles, and/or groups of customers that own, or use, autonomous vehicles); receiving and comparing one or more bids 608 for insurance covering multiple autonomous vehicles; accepting one or more winning bids 610; and/or notifying insurance customers and/or autonomous vehicles of new AV insurance policies and/or changes to existing AV insurance policies, coverages, premiums, discounts, deductibles, etc. 612; automatically detecting driving events or other events that may impact a risk score and/or a customer profile of a customer and/or vehicle associated with a particular insurance group or segment 614 (which may include analysis of telematics data associated with a customer or an autonomous vehicle); updating the customer's or vehicle's risk score or AV-related profile 616; and/or updating the particular insurance group or segment with which the customer and/or vehicle is associated, and/or moving the customer and/or vehicle to be associated with another group or segment 618.

After a number of customers and/or autonomous vehicles have been moved to new or different AV-related groups or segments, another auction of the new or updated AV groups may be held 606, the process may continue 608, 610, 612, 614, 616, 618, etc. The method may include additional, fewer, or alternate actions, including those discussed elsewhere herein.

In one aspect, a computer-implemented method for providing auto insurance covering multiple autonomous vehicles may be provided. The method may include (1) analyzing, via one or more processors, multiple insurance applications, accounts, and/or policies for at least one Autonomous Vehicle (AV) preference or characteristic of multiple individuals and/or autonomous vehicles corresponding to the multiple insurance applications, accounts, and/or policies; (2) dividing or segmenting, via the one or more processors, the multiple individuals and/or autonomous vehicles into multiple AV (Autonomous Vehicle) policy groups or segments based upon the at least one AV preference or characteristic of the multiple individuals and/or autonomous vehicles; (3) auctioning, via the one or more processors and by using an electronic or communications network, an opportunity to provide autonomous vehicle insurance for one or more of the multiple AV policy groups or segments; (4) receiving, via the one or more processors and the electronic or communications network, one or more bids for purchase and/or offers of autonomous vehicle insurance for the one or more of the multiple AV policy groups or segments; (5) accepting, via the one or more processors, one of the bids for purchase and/or autonomous vehicle insurance offers; and/or (6) updating or providing, via the one or more processors, autonomous vehicle insurance policies for insureds and/or autonomous vehicles associated with a particular AV policy group or segment corresponding to the accepted bid, thereby providing lower cost insurance and/or autonomous vehicle insurance that is more reflective of actual risk, or lack thereof, to the insureds (and/or for the vehicles) associated with the particular AV policy group or segment.

The at least one AV preference of the multiple individuals and/or autonomous vehicles may include preferences for at least one of insurance policy coverage, types of coverages, premiums, discounts, deductibles, conditions, limits, or other terms; and the particular AV policy group or segment may be associated with AV auto insurance. Additionally or alternatively, the at least one AV preference of the multiple individuals and/or autonomous vehicles may include preferences for pay-by-mile auto insurance; and/or the particular AV policy group or segment may be associated with AV auto insurance.

The at least one AV preference of the multiple individuals and/or autonomous vehicles may include preferences for autonomous or semi-autonomous features or technologies, including one or more of: vehicle self-braking, self-driving, lane centering, cruise control, collision avoidance, and blind spot monitoring; and/or the particular AV policy group or segment is associated with AV automobile insurance. The at least one AV preference of the multiple individuals and/or autonomous vehicles include preferences for at least one of claims expectations, telematics use, or insurance company or provider ratings. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

In another aspect, a computer system configured for providing auto insurance covering multiple autonomous vehicles may be provided. The method system may include a persistent memory storing a consumer profile database; one or more communication interfaces configured to communicate with remote devices via one or more electronic or communications networks; one or more processors; and/or one or more non-transitory, computer-readable media storing instructions that, when executed by the one or more processors, cause the system to: (1) analyze consumer or autonomous vehicle profiles that are included in the consumer profile database and that correspond to multiple insurance consumers and/or autonomous vehicles for at least one AV preference or characteristic of the multiple insurance consumers; (2) divide or segment the multiple insurance consumers into multiple AV policy groups or groupings based upon the at least one AV preference or characteristic of the multiple insurance consumers; (3) auction, via the one or more electronic or communications network and by using the one or more communication interfaces, an opportunity to provide AV insurance for one or more of the multiple AV policy groups or groupings; (4) receive, at the one or more communication interfaces, one or more bids for purchase and/or offers for AV insurance for the one or more of the multiple AV policy groups or groupings; (5) accept one of the bids for purchase and/or offers for AV insurance for the one or more of the multiple AV policy groups or groupings; and/or (6) update existing AV insurance policies or provide new AV insurance policies for insureds and/or autonomous vehicles associated with a particular AV policy group or grouping corresponding to the accepted bid, thereby providing lower cost insurance and/or AV insurance that is more reflective of actual risk, or lack thereof, to the insureds associated with the particular AV insurance policy group or grouping. The system may include additional, less, or alternate functionality, including that discussed elsewhere herein.

While FIG. 5 has been discussed with reference to AVs, it is understood that similar methods may be used with respect to other types of vehicles, such as vertical-takeoff-and-landing (eVTOL) vehicles, air taxis, and/or personal air vehicles (PAVs), for example. For instance, such vehicles (or their owners) may be grouped by features or technologies, telematics data, and/or policy preferences, including the availability of certain coverage types for such vehicles. Some affinity groups may be specific to consumers who are seeking coverage for such vehicles, for example.

IX. Exemplary Auction Embodiments

FIG. 6 depicts an exemplary computer-implemented method of auctioning groups or bundles of insurance policies 700. The method 700 may include, via one or more processors associated with an insurance provider or other entity, determining consumer demand for auto insurance 702; collecting consumer data 704, such as with consumer permission or affirmative consent; forming one or more affinity groups based upon consumer profiles 706 and/or the data collected; holding one or more auctions of affinity groups with multiple insurance carriers or providers, such as via wireless communication or data transmission over one or more radio links or communication networks 708; identifying a winning bid or winning bids for each affinity group 710; and/or receiving payment from consumers at the original entity organizing or running the electronic auction and/or at the multiple insurance carriers 712. The electronic auctions may be periodically repeated, such as every 6 or 12 months. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.

For instance, consumers may go online to complete an auto insurance “like” application hosted by an entity (“Company”) that organizes an electronic insurance auction for blocks of similarly situated customers or vehicles. Based upon the contents of the application, individuals (or even vehicles) may be segmented into groups, such as in groups of similarly situated individuals, or vehicles. These groups may be defined by any of the following criteria: behavioral and attitudinal segmentation; demographics; geography (such as by state or city of residence); occupation; risk characteristics; claims and claims expectations; insurance company ratings (AAA); telematics data; insurance status; driving record; homeowner status; vehicle count; driver gender; existing carrier; preference for an agent or direct relationship (or other sales/relationship preference); pay as you drive insurance (or other UBI); telematics based insurance (e.g., device type); zip code; day time or time-of-day usage; autonomous car insurance; autonomous vehicle features or technologies; vehicle safety features; vehicle make and model; vehicle age; types of insurance coverage, limits, premiums, rates, discounts, conditions, or terms; and/or other criteria, including those discussed elsewhere herein.

Based upon these segmentation criteria, once a group of consumers reaches a certain membership or size, the auctioneer entity or Company may consider the group like an affinity group. Recognizing there are hundreds of ways to segment consumers based upon the above criteria, it may be likely that the Company may have hundreds of affinity groups that they may be accountable for securing auto insurance coverage for.

Within a given period of time or window of time, Company may present the affinity group to a number of auto insurance companies for auto insurance coverage through an auction like process. At this point, Company may hold an auction where the auto insurance carriers will be permitted to bid on providing auto insurance to the affinity group.

The auto insurance carrier that bids to provide auto insurance to the affinity group for the lowest amount of money, based upon the requirements, profile or specifications of the affinity group, that auto insurance carrier will receive the contract to provide auto insurance to the affinity group (its members) for a set period of time or a specific term (e.g., six months or a year). During this period of time, the members of the affinity group may have their checking accounts or credit cards debited periodically, by either Company or the auto insurance carrier that provides the auto insurance, for the payment of their auto insurance coverage. Additionally or alternatively, alternate means of electronic fund transfers may be utilized.

Prior to the conclusion of the auto insurance policy's term or length, Company may automatically conduct another auction for the affinity group to ensure its members are always receiving the most competitively priced auto insurance coverage. In other words, the consumer or affinity group member may never have to shop for auto insurance again as Company may take on this responsibility for the consumer.

Some of the benefits or pricing discounts the members of the affinity group earn, such as loyalty or accident free discounts, may become a part of the profile of the group and be priced into the future cost of the affinity group's auto insurance. Likewise, if a member or vehicle of the affinity group is involved in a driving violation or accident, this may result in the member or vehicle being moved to another affinity group (which this member aligns to better). Depending on demand for this service, Company could form and shop affinity groups on a daily/periodic basis. Further, as blockchain technologies or techniques become more readily available or feasible, Company may employ one or more blockchains to issue, maintain, and update insurance policies, as well as conduct, and record the results of, electronic auctions for blocks of similarly situated insureds or vehicles.

FIG. 7 depicts an exemplary computer-implemented method of auctioning groups or bundles of insurance policies 800. The method 800 may include, via one or more processors associated with an insurance provider or other entity, receiving a plurality of completed applications for auto insurance from a set of consumers (e.g., customers or potential customers) 802; forming one or more affinity groups within the set of consumers based upon the plurality of completed applications, e.g., based upon “look-a-like” applications or similar characteristics between various applications 805; holding a respective auction for each of the formed affinity groups with multiple insurance carriers or providers, such as via wireless communication or data transmission over one or more radio links or communication networks 808; for each affinity group auction, accepting a winning bid from a respective insurance carrier or provider 810; notifying each consumer included in each affinity group of the respective, winning insurance carrier or provider 812; and collecting a respective commission or fee from each winning insurance carrier or provider 815. The electronic auctions may be repeated 818, e.g., upon the expiration of one or more insurance policies associated with each affinity group. In one embodiment of repeating an electronic auction 818, the method 800 may proceed to holding one or more subsequent electronic auctions for one or more of the formed affinity groups 808, etc. In some embodiments of repeating an electronic auction 818, the method 800 may proceed to receiving a subsequent set of completed or updated applications from a subsequent set of consumers 802, where the subsequent set of consumers may at least partially overlap with the previous set of consumers; forming one or more subsequent affinity groups based upon the applications of the subsequent set of consumers 805, which may include re-forming one or more of the previously-formed affinity groups; holding a respective auction for each of the subsequently-formed affinity groups 808, etc. The method 800 may include additional, less, or alternate actions, including those discussed elsewhere herein.

For example, consumers may go online to complete an auto insurance-like application hosted by an entity (“Company”), where the auto insurance-like applications requests information or data similar to the information or data that is typically required for auto insurance applications. The Company may organize an electronic insurance auction for blocks or groups of similarly situated customers or vehicles, e.g., blocks or groups of look-a-likes, and the completed applications may be received by the Company. Contents, information, or data included in the received applications may be collected and analyzed, and based upon the analysis, various affinity groups may be formed from individuals (or even vehicles) associated with the received applications, such as groups of similarly situated individuals, or vehicles. These affinity groups may be defined by any of the following criteria: behavioral and attitudinal segmentation; demographics; geography (such as by state or city of residence); occupation; risk characteristics; claims and claims expectations; insurance company ratings (AAA); telematics data; insurance status; driving record; homeowner status; vehicle count; driver gender; existing carrier; preference for an agent or direct relationship (or other sales/relationship preference); pay as you drive insurance (or other UBI); telematics based insurance (e.g., device type); zip code; day time or time-of-day usage; autonomous car insurance; autonomous vehicle features or technologies; vehicle safety features; vehicle make and model; vehicle age; types of insurance coverage, limits, premiums, rates, discounts, conditions, or terms; and/or other criteria, including those discussed elsewhere herein. Recognizing there are hundreds of ways to group consumers based upon the above criteria, it may be likely that the Company may have hundreds of affinity groups for which the Company may be accountable for securing auto insurance coverage.

The Company may present each formed affinity group to a number of auto insurance providers, carriers, or companies for auto insurance coverage through an auction-like process. At this point, for each affinity group, Company may hold an auction where the auto insurance carriers will be permitted to bid on providing auto insurance to the affinity group (its members). Different affinity groups may be presented to different sets of auto insurance companies for auction, if desired.

For each affinity group auction, the auto insurance carrier that bids to provide auto insurance to the affinity group for the lowest amount of money, based upon the requirements, profile, or specifications of the affinity group, may receive or may be awarded the contract to provide auto insurance to the affinity group (its members) for a set period of time or a specific term (e.g., six months or a year). During this period of time, the members of the affinity group may have their checking accounts or credit cards debited periodically, by either Company or the auto insurance carrier that provides the auto insurance, for the payment of the premiums for their auto insurance coverage. Additionally or alternatively, alternate means of electronic fund transfers may be utilized.

Moreover, for each affinity group auction, the Company may collect a respective commission or fee from the auto insurance carrier that receives or is awarded the contract, e.g., from the winning auto insurance carrier. For example, an amount of a commission or fee for a particular auction may be electronically (and, in some scenarios, automatically) transferred from the winning insurance carrier or provider to the Company. In one embodiment, the amount of the commission or fee may be determined based upon the affinity group's premium, e.g., as a percentage of the affinity group's premium. In one embodiment, the amount of the commission or fee may be a flat administrative fee. Additionally, in some embodiments, each member of each affinity group may pay the Company a fee corresponding to the procurement of insurance for the member. For example, each member of each affinity group may pay the Company an annual or periodically assessed membership fee. The payment of the membership fee may be implemented via electronic funds transfer, for instance.

Prior to the conclusion of an auto insurance policy's term or length, e.g., upon or shortly before the expiration of the auto insurance policy, the Company may automatically conduct another auction for the affinity group, e.g., to ensure its members are always receiving the most competitively priced auto insurance coverage. The electronic auctions may be repeated, e.g., upon the expiration of one or more insurance policies associated with the affinity groups. In other words, a consumer or affinity group member may never have to shop for auto insurance again as Company may take on this responsibility for the consumer.

In some embodiments, prior to the conclusion of one or more auto insurance policies' term or length, e.g., upon or shortly before the expiration of one or more auto insurance policies, the Company may automatically form or re-form at least some of the affinity groups. For example, the Company may automatically form or re-form at least some of the affinity groups based upon a subsequent set of completed or updated applications from a subsequent set of consumers 802. In some scenarios, the subsequent set of consumers may at least partially overlap with the previous set of consumers from which the affinity groups were formed. A respective auction for each of the subsequently-formed affinity groups may be held (e.g., based upon the same criteria as the previously-formed affinity groups or based upon different criteria), and a corresponding contract may be awarded to each of the winning insurance companies or providers. The Company may collect respective commissions or fees from each of the winning insurance companies or providers, and insurance policies may be automatically enacted by the winning insurance companies or providers for members of the subsequently-formed affinity groups.

Some of the benefits or pricing discounts the members of an affinity group earn, such as loyalty or accident free discounts, may become a criteria based upon which subsequent affinity groups are formed or re-formed. Likewise, if a member or vehicle of the affinity group is involved in a driving violation or accident, this may result in the member or vehicle being moved to another affinity group (which this member aligns to better) during subsequent forming or re-forming of affinity groups. Depending on demand for this service, Company could form, re-form, and auction affinity groups on a daily/periodic basis in addition to alternatively to forming, re-forming, and auctioning affinity groups upon expiration of one or more insurance policies. Further, as blockchain technologies or techniques become more readily available or feasible, Company may employ one or more blockchains to issue, maintain, and update insurance policies, as well as form or re-form affinity groups; conduct, and record the results of, electronic auctions for affinity groups; and collect respective commissions or fees from winning insurance companies or providers.

The benefit to the members of each affinity group for such an arrangement may include the ability to buy auto insurance at the most competitive price available. In addition, participation in this program should take the “hassle” out of ever having to shop for auto insurance again, as this service may repeatedly do it automatically for its members, such as every six months. On the other hand, the benefit to the participating auto insurance carriers for such an arrangement may be the ability to attract large groups of consumers who may not have otherwise shopped/considered their company for auto insurance.

X. Exemplary Blockchain Environment for Automatically Obtaining and/or Maintaining Insurance Coverage

FIG. 8A depicts an exemplary blockchain environment 830 including components associated with obtaining and/or maintaining insurance coverage, according to one embodiment. It is noted that although FIG. 8A depicts certain entities, components, and devices, it should be appreciated that additional or alternate entities and components are envisioned. Generally speaking, though, the blockchain environment 830 may be configured and arranged to support and maintain a distributed ledger via which auctions of opportunities to provide insurance policies (e.g., to one or more affinity groups), or to reinsure liabilities associated with existing insurance policies, may be conducted. As previously discussed, an affinity group may comprise a set of group members. The set of affinity group members may include a group of individuals or end-consumers, each of whom desires to procure insurance, in some implementations. In other implementations, the set of affinity group members may include a group of products and/or services (e.g., fractionally-used products or services, fractionally-owned products or services, etc.) that are provided by a company, business, or other organization, where the company, business, or other organization desires to procure insurance for its products and/or services. A “distributed ledger” may be a transactional record that is maintained at each node of a peer to peer network. Commonly, the distributed ledger is comprised of groupings of transactions bundled together or compiled into a “block.” When a change to the distributed ledger is made (e.g., when a new transaction and/or block is created), each node must form a consensus as to how the change is integrated into the distributed ledger. Upon arriving at consensus, the agreed upon change may be pushed out or distributed to each node so that each node maintains an identical copy of the updated distributed ledger. Any change that does not achieve a consensus is ignored. Accordingly, unlike a traditional, centralized ledger, a single party cannot unilaterally alter the distributed ledger.

In an application of distributed ledgers, each new block may be cryptographically linked to the previous block in order to form a “blockchain.” More particularly, to create a new block, each transaction within a block may be assigned a hash value (i.e., an output of a cryptographic hash function, such as SHA-2 or MD5). These hash values may then be combined together utilizing cryptographic techniques (e.g., a Merkle Tree) to generate a hash value representative of the entire new block. This hash value may then be combined with the hash value of the previous block to form a hash value included in the header of the new block, thereby cryptographically linking the new block to the blockchain. To this end, the precise value utilized in the header of the new block is dependent on the hash value for each transaction in the new block, as well as the hash value for each transaction in every prior block.

According to aspects, the hash value generated for the new block may be used as an input to a cryptographic puzzle that manipulates a nonce value. When a solution to the cryptographic puzzle is found, the solving node publishes the solution and the other nodes then verify that the solution is the correct solution. Because the solution also depends on the particular hash values for each transaction within the blockchain, if the solving node attempted to modify any transaction, the solution would not be verified by the other nodes. More particularly, if a single node attempts to modify a prior transaction within the blockchain, a cascade of different hash values are generated for each tier of the cryptographic combination technique. This results in the header for one or more blocks being different than the corresponding header(s) in every other node that did not make the exact same modification. As a result, the solution generated by the modifying node would not solve the cryptographic puzzle presented to any node without the identical modification. Thus, the version of the new block generated by the modifying node is readily recognized as including an improper modification and is rejected by the consensus. This inability to modify past transactions lead to blockchains being generally described as trusted, secure, and/or immutable.

As illustrated in FIG. 8A, the blockchain environment 830 associated with obtaining and/or maintaining insurance coverage may include a distributed ledger 832. The distributed ledger 832 may be maintained via a network of nodes, which may include one or more computing devices or networks 835a-835n associated with respective bidding entities, and/or may include an enforcement server 840. The nodes 835a-835n, 840 may have access to the distributed ledger 832 and/or may generate data included in the distributed ledger 832. As described above, in some embodiments, the distributed ledger 832 may not be changed without first forming or arriving at a consensus on the change. Accordingly, as depicted by FIG. 8A, the distributed ledger 832 may be considered separate from any individual node 835a-835n, 840, even though the individual nodes 835a-835n, 840 may store local copies of the distributed ledger 832. Generally speaking, the nodes 835a-835n, 840 may be interconnected via one or more networks 842, which may include one or more public networks (such as the Internet), and/or one or more private networks (such as private networks managed by bidding entities). The one or more networks 842 may utilize any suitable wired or wireless communications standard or technology (e.g., GSM, CDMA, TDMA, WCDMA, LTE, EDGE, OFDM, GPRS, EV-DO, UWB, IEEE 802 including Ethernet, WiMAX, and/or others).

According to certain aspects, the enforcement server 840 may be configured to compile new blocks to add to a blockchain and to administer one or more auctions of opportunities to provide insurance, e.g., to provide insurance for respective members of one or more affinity groups, and/or to administer or to cause the administration of one or more insurance policies corresponding to winning bids of auctions. Although FIG. 8A illustrates a single enforcement server 840, it should be appreciated that in some embodiments, the enforcement server 840 may be a plurality of interconnected servers, for example, in a cloud computing environment. Moreover, while the discussion below relates primarily to the auctioning of opportunities to provide insurance to insurance providers, the blockchain environment 830 may instead (or also) be used to generate and store records associated with auctioning to other entities that are associated with insurance providers (e.g., reinsurers, investment fund managers, etc.), and/or auctioning of opportunities to reinsure liabilities associated with existing insurance policies (e.g., as discussed further below with reference to FIG. 11).

In one aspect, the enforcement server 840 may compile or combine a plurality of transactions received from the plurality of bidding entities 835a-835n into a new block. After the new block is compiled, the enforcement server 840 may transmit the new block to the plurality of bidding entities 835a-835n and/or to one or more dedicated validation entities 838 to generate a solution to incorporate the block into blockchain and/or to form or arrive at a consensus on the solution. For example, if a particular block includes transactions corresponding to the bidding actions (e.g., bids or no-bids) submitted by more than one of the bidding entities 835a-835n for a particular round of bidding of a particular auction, the solution may indicate the highest submitted bid amount for the particular round, and the blockchain may include blocks corresponding to multiple rounds of bidding of the particular auction. It is noted that although FIG. 8A illustrates that the dedicated validation entities 838 as being separate from the enforcement server 840, it should be appreciated that the enforcement server 840 may itself include a module dedicated to generating a solution to the cryptographic puzzle and/or forming a consensus on the solution (e.g., one or more validation entities 838 that are integral with the enforcement server 840).

In another aspect, the enforcement server 840 may analyze an auction database 850 to determine whether any transactions compiled into a new block are associated with an auction that is presently being conducted. For example, a particular bidding entity 835b may provide, within the new block, multiple indications of bids or no-bids (e.g., of bidding actions) corresponding to respective multiple open auctions. To this end, the enforcement server 840 may extract, from the new block, one or more transactions identifying the particular bidding entity 835b and its indication(s) of respective bidding actions (e.g., bids or no-bids) for one or more auctions, and may update auction data or records stored in the auction database 850 with the bidding actions submitted by the particular bidding entity 835b.

Generally speaking, the indications of bids/no-bids and/or other auction information associated with the distributed ledger 832 may be stored in the auction database 850. For example, the auction database 850 may store information regarding the state of one or more open or in-progress auctions; respective submitted bidding actions; winning entities; statuses, terms, and other information corresponding to insurance policies that have been enacted based upon completed auctions; and the like. Although FIG. 8A depicts the auction database 850 as a part of the enforcement sever 840, in some embodiments, the auction database 850 may be maintained within the distributed ledger 832.

To support these and other aspects, the enforcement sever 840 may include a blockchain manager 845. The blockchain manager 845 may be a software program, engine, unit, and/or a module that is executed by one or more processors interconnected with the enforcement server 840. That is, the blockchain manager 845 may include a set of computer-executable instructions that is stored on one or more tangible, non-transitory computer-readable storage media or memories included in or accessible to the enforcement server 840.

In one embodiment, the blockchain manager 845 may compile a plurality of auction actions (e.g., bids or no bids) into a block, update the distributed ledger 832 to include a block, route auction data to one or more bidding entity computing systems or devices 835a-835n, and/or automatically determine a winning bid and award the respective opportunity to provide insurance to the entity that submitted the winning bid. In some embodiments, the blockchain manager 845 may provide authentication and/or authorization of bidding entities 835a-835n, and may secure auction data that is shared between bidding entities 835a-835n. Further, the blockchain manager 845 may provide the secure transfer or transmission of affinity group data (e.g., data that is descriptive of affinity group members, as a group and/or individually) to the winning bidding entity so that the winning bidding entity may generate and provide insurance policies for the affinity group. For example, the blockchain manager 845 may provide, to the winning bidding entity, contact information for one or more consumers associated with the affinity group, and/or other characteristics of particular affinity group members which may adjust premiums and/or other terms of respective insurance policies on a per-member basis (e.g., driving record, good student discount, total number of miles driven, age of primary driver, etc.). Additionally, the blockchain manager 845 may (e.g., in cooperation with the computing system of the winning bidding entity) update statuses, terms, claim data, payments, and other information corresponding to the enacted insurance policies for the affinity group.

According to certain aspects, an operator of the enforcement server 840 may interact with a management interface 848 to control aspects of the distributed ledger 832 and/or set control parameters associated with the blockchain manager 845. For example, a time period for which blocks are generated may be set via the management interface 848, a timing for pushing distributed ledger updates to the nodes may be set via the management interface 848, or a criteria for determining a winning bid may be set via the management interface 848.

According to certain aspects, one or more public devices 852 may access at least some of the data stored at the enforcement server 840 via a public interface 855. The public interface 855 may be a read-only interface that prevents the one or more public devices 852 from writing transactions to the distributed ledger 832. To this end, the one or more public devices 852 may be used, for example, to view data maintained within the distributed ledger 832, to view the status of one or more auctions associated with the distributed ledger 832, compile statistics regarding data maintained in the distributed ledger 832, and so on. For example, computing devices associated with bidding entities 835a-835n may access portions of the data stored at the enforcement server 840 via the public interface 855.

Turning now to FIG. 8B, illustrated is an exemplary flow diagram 870 associated with compiling a plurality of transactions into blocks. In one embodiment, the flow diagram 870 may be executed in the blockchain environment 830 of FIG. 8A. As illustrated, each transaction xi may include several components. A first component may include an identification of a bidding entity 872. The bidding entity may be, for example, an insurance company, insurance provider, an insurance broker, etc. Another component of each transaction xi may be a transaction information component 875 associated with a timestamp 878. The transaction information component 875 may include an indication of a bid or bid amount that is put forth by the bidding entity 872 for a particular auctions, or an indication that the bidding entity 872 is not putting forth a bid for the particular auction. In some aspects, the bidding entity's identification 875 and the timestamp 878 may be viewed as a transaction header, whereas the transaction information 875 may be viewed as the transaction payload.

According to illustrated embodiments, a plurality of transactions may be compiled into a block. In one example scenario, a plurality of transactions generated by a plurality of bidding entities 880a-y may be compiled into a block 882a. For example, each of the plurality of computing devices or systems respectively corresponding to various bidding entities 880a-880y may transmit bids to an enforcement server (such as the enforcement server 840 as described with respect to FIG. 8A) for compilation into the block 882a. As such, in this example, each block 882a may correspond to one round of bidding, and/or a block 882a may correspond to the respective maximum bids (if any) of the bidding entities 880a-880y.

In another example, a particular bidding entity 880z compiles a plurality of transactions generated at the particular bidding entity 880z into a block 882b that only includes transactions associated with the particular bidding entity 880z. For instance, the various transactions included in the block 882b may respectively correspond to respective bids and/or respective no-bids of a plurality of auctions in which the bidding entity 880z is participating, and/or the block 882b may include respective indications of respective, maximum bid amounts for auctions in which the particular bidding entity 880z is participating. In this example, the particular bidding entity 880z may transmit, to the enforcement server 840, the generated block 882b for distribution to a plurality of validation entities 838 that attempt to solve a cryptographic puzzle based upon the header of the generated block 882b and/or form a consensus on one or more solutions corresponding to one or more auctions. The exemplary flow diagram 870 may include additional, fewer, or alternate actions, including those discussed elsewhere herein.

FIG. 8C includes a flow diagram of an exemplary computer-implemented method 900 of auctioning insurance policies using a blockchain environment. The method 900 may be executed within the blockchain environment 830 of FIG. 8A, and/or the method 900 may operate in conjunction with one or more portions of the flow diagram 870 of FIG. 8B. For example, at least a portion of the method 900 may be performed by the enforcement server 840. In some embodiments, at least a portion of the method 900 may be performed by the system 10 of FIG. 1 and/or by the computer system 300 of FIG. 2. Further, the method 900 may operate in conjunction with one or more portions of any one or more of the methods discussed with respect to FIGS. 3-7. The method 900 may include additional, less, or alternate actions, including those discussed elsewhere herein, although for clarity of discussion, and not for limitation purposes, the method 900 is discussed herein with simultaneous reference to FIGS. 1, 2, 8A, and 8C.

At a block 902, the method 900 may include generating a notification of an auction for an opportunity to provide insurance for an affinity group, determining a plurality of bidding entities. For example, an enforcement server 840 may generate the notification of an auction corresponding to an affinity group. At a block 905, the method 900 may include transmitting the notification of the auction corresponding to the affinity group to the plurality of bidding entities. The plurality of bidding entities may include one or more insurance providers, insurance brokers, insurance carriers, etc. (such as providers 16-1 to 16-N), and in one embodiment, the method 900 may include determining the plurality of bidding entities based upon one or more characteristics of the affinity group and/or one or more characteristics of the insurance providers, insurance brokers, insurance carriers, etc. The notification of the auction corresponding to the affinity group may be transmitted, for example, via one or more network interfaces of the enforcement server 840 and by using an electronic or communications network 842 to one or more computing devices and systems corresponding to the plurality of bidding entities (e.g., references 16-1 to 16-N).

In one example, the affinity group may comprise a group of persons each of who respectively desire to obtain insurance, such as auto insurance. In another example, the affinity group may exclude people or persons, and instead may comprise one or more products, services, and/or assets that may be provided for fractional-use and/or for fractional-ownership, and that are to be insured, such as a group of autonomous vehicles, a shared vehicle, etc. In one embodiment (not shown), the method 900 includes forming the affinity group based upon collected end-consumer data and/or based upon data that has been entered into insurance applications. In another embodiment, the affinity group is pre-defined by a third-party, such as a party that desires to procure insurance for a group of persons, products, services, and/or assets.

At a block 908, the method 900 may include receiving a plurality of bidding actions that have been submitted by at least some of the plurality of bidding entities in response to the notification of the auction of the opportunity to provide insurance for the affinity group. The plurality of bidding actions may include a respective bidding action submitted by each bidding entity, where the respective bidding action indicates, for example, a bid amount (e.g., a monetary bid amount) or a no-bid. The plurality of bidding actions may be received via the one or more network interfaces and by using an electronic or communications network, in one embodiment.

At a block 910, the method 900 may include determining or generating a plurality of transactions based upon the plurality of bidding actions. For example, the blockchain manager 845 may determine or generate the plurality of transactions based upon the plurality of bidding actions. Each transaction may include an indication of a specific bidding entity (e.g., an identification, identifier, or ID of the bidding entity), an indication of a particular auction, an indication of a bidding action for the particular auction, and a timestamp or other indication of a time at which the bidding action was generated. In some embodiments, a single transaction may include indications of multiple bidding actions (e.g., for a same auction and/or for different auctions) and their respective timestamps. In some embodiments, a single transaction may include indications of multiple bidding entities and their respective bidding actions and timestamps. Other embodiments of determining or generating transactions may be possible.

At a block 912, the method 900 may include compiling or bundling the plurality of transactions corresponding to the plurality of bidding actions into a block of transactions, e.g., into a transaction block, e.g., a transaction block 872. In one embodiment, the blockchain manager 848 of the enforcement server 840 may compile or bundle the plurality of transactions into a block of transactions. As previously discussed, in some implementations, each transaction within a transaction block may be assigned a hash value, and the plurality of transaction hash values may be combined to generate a hash value for the transaction block. A maximum number of transactions which may be included in a block may be pre-defined, e.g., via the management interface 848 of the enforcement server 840. Additionally or alternatively, a periodicity of generation of transaction blocks, a time period for which transaction blocks are generated, and/or an elapsed time interval between the generation of subsequent transaction blocks may be defined, e.g., via the management interface 848 of the enforcement server 840. The newly created block of transactions may be stored in the auction database 850, in one embodiment.

In one embodiment (not shown), the method 900 may include chaining or linking the newly generated block of transactions to a blockchain that comprises one or more previously generated transaction blocks. In these embodiments, the plurality of block hash values may be combined to generate a hash value for the entire blockchain. The blockchain including the newly-linked transaction block may be maintained or stored in the auction database 850, for example.

At a block 915, the method 900 may include distributing the block of transactions to one or more validation entities (e.g., one or more validation entities 838) to form a consensus on a solution for the newly generated transaction block, where the solution may include a highest bid for the newly generated transaction block. In one exemplary implementation, at least one of the one or more validation entities 838 may be included in the enforcement server 840, and/or at least one of the one or more validation entities 838 may be accessed via the network(s) 842.

As previously discussed, the one or more validation entities 838 may solve the cryptographic puzzle associated with the block of transactions (e.g., by utilizing the hash values associated with the transactions and with the block), and/or may form a consensus on a solution for the block. In embodiments in which the newly generated transaction block is chained or linked to a blockchain, the one or more validation entities may solve the cryptographic puzzle associated with the newly generated block by utilizing the hash values associated with the transactions, the block, and the blockchain, and/or may form a consensus on a solution for the blockchain. The solution may comprise, for example, a highest bid included in the transaction block for the auction corresponding to the affinity group. The highest bid included in the transaction block may be the highest bid of a particular round of bidding or the highest bid of multiple rounds of bidding, for example.

At a block 918, the method 900 may include updating a plurality of copies of a distributed ledger (e.g., the distributed ledger 832) with the newly generated transaction block having the solution determined by consensus. In one embodiment, upon reaching consensus on the newly generated transaction block (block 915), the plurality of copies of a distributed ledger may be updated by pushing or transmitting the newly generated transaction block to all nodes (e.g., the nodes 835) at which copies of the distributed ledger 832 are stored, and each node may chain or link the newly created transaction block to an existing blockchain stored at the node (if any). For example, the transaction block may be pushed out to each of the respective computing devices or systems of the plurality of bidding entities 16-1 to 16-N, e.g., to each node, so that the respective computing devices or systems of the plurality of bidding entities may each maintain an identical copy of the updated distributed ledger 832.

At a block 920, the method 900 may include identifying, based upon the updated distributed ledger, a winning bid for the auction corresponding to the affinity group. For example, identifying the winning bid for the auction corresponding to the affinity group based upon the updated distributed ledger may comprise reaching consensus on a solution for the entire blockchain, including the newly linked transaction block, by the one or more validation entities 838. Identifying the winning bid for the auction may be based upon the expiration of a time period or interval, a completion of a number of elapsed bidding rounds, a minimum number and/or a maximum number of received bids, and/or any other desired or suitable criteria. In one embodiment, the blocks 908-918 may be repeated multiple times prior to the identification of the winning bid for the auction corresponding to the affinity group. In some scenarios, the block 920 may be integral with the blocks 912-918, for example, during a final round of bidding for the auction corresponding to the affinity group.

At a block 922, the method 900 may include providing, to the particular bidding entity data that submitted the winning bid, data that is descriptive of group members of the affinity group for use by the particular bidding entity in generating one or more insurance policies for the affinity group, thereby providing lower cost insurance and/or insurance that is more reflective of actual risk, or lack thereof, to a set of consumers associated with the particular affinity group. For example, data that is common for all group members of the affinity group may be provided to the winning bidding entity, and/or data that is different between at least two group members of the affinity group may be provided to the winning bidding entity. In one embodiment, providing the descriptive data of the group members may include securing the descriptive data and transmitting the secured descriptive data to the winning bidding entity.

XI. Affinity Group Auctions for Reinsurance

As noted above, in some embodiments and/or scenarios, reinsurers may participate in affinity group auctions (e.g., as shown in FIG. 1 for computing systems 16-3 and 16-4), with or without participating insurance providers. FIG. 9 depicts an exemplary computer-implemented method 1000 for auctioning insurance policies to various entities, including at least one reinsurer, according to one embodiment. The method 1000 may be implemented by one or more processors of the intermediary entity 14 of FIG. 1, for example.

At block 1002, the method 1000 may include dividing a plurality of consumers into multiple affinity groups, based at least upon one or more characteristics and one or more preferences of the consumers. The consumer characteristics may include, for example, age, marital status, occupation, finances or income, account status, driving history, accident history, vehicle type, home type, geographic location, risk score, and/or one or more other suitable characteristics. In some embodiments, the consumer characteristics include at least one characteristic indicative of the consumer's individual driving behavior, and the method 1000 may include determining risk scores for the consumers based upon vehicle telematics data associated with the consumers. The preferences may include, for example, preferred coverage types, premiums, discounts, deductibles, limits, multi-line discount availability, insurance company rating, insurance company claims experience, UBI availability, AV, eVTOL, air taxi, or PAV coverage availability, and/or one or more other suitable preferences. In some embodiments, the preferences include a desired amount of time to remain with a single insurance provider (e.g., six months, no more than one year, at least one year, indefinitely, etc.). Block 1002 may be similar to block 404 of the method 400, for example.

At block 1004, an opportunity to provide insurance for one or more of the multiple affinity groups is auctioned, via a communications network (e.g., a single network or multiple coupled networks) to a plurality of entities that includes at least one reinsurance provider. In some embodiments where block 1002 includes determining risk scores for the consumers (e.g., based on vehicle telematics data), block 1004 includes providing the risk scores to the entities participating in the auction (e.g., before the auction begins) via the communications network.

In some embodiments and/or scenarios, all of the participating entities are reinsurance providers. Alternatively, the participating entities may also include one or more insurance providers and/or other types of entities (e.g., investment management companies seeking arbitrage opportunities based upon an independent assessment of risk). In some cases, each reinsurer (and any other non-carrier/provider) participating in the auction has a pre-existing contract/arrangement with an insurance provider that is licensed/authorized to write insurance, service claims, handle customer correspondence/billing, etc., for any insurance policies resulting from (or updated based upon results of) the auction. For example, a particular reinsurer may have an agreement whereby, if the reinsurer “wins” the auction, a particular insurance provider will provide the insurance policies for all members of the affinity group and provide some specific percentage (e.g., 20%, 50%, 100%, etc.) of proceeds to the reinsurer, and the reinsurer will immediately reinsure some specific percentage (e.g., 20%, 50%, 100%, etc.) of liabilities associated with those insurance policies. The insurance provider may be liable in the event that the reinsurer defaults, however. Block 1004 may be similar to block 406 of the method 400, for example.

At block 1006, one or more bids for purchase and/or offers of insurance for the one or more of the multiple affinity groups are received via the communications network, and at block 1008 a winning bid, of the bids received at block 1006, is accepted. The auction participants may form their bids based on the perceived risk associated with each affinity group, for example, and possibly also other factors (e.g., administrative costs likely to be incurred for that particular group). Depending on the embodiment, the auction participants may rely on risk evaluations from the intermediary entity (e.g., based upon a standardized risk score calculated by the intermediary entity), or may directly analyze risk based on the consumer characteristics. Blocks 1006 and 1008 may be similar to blocks 408 and 409, respectively, of the method 400, for example.

At block 1010, individual insurance policies, or a group insurance policy, is/are caused to be provided to or updated for consumers associated with a particular affinity group corresponding to the winning bid, thereby providing lower cost insurance and/or insurance that is more reflective of actual risk, or lack thereof, for the consumers associated with the particular affinity group. Block 1010 may include directly generating or initiating the policy or policies on behalf of a winning provider (or on behalf of a provider associated with a winning reinsurer or other entity), or may include transmitting certain information to that provider and/or the winning entity (e.g., personal information of members of the affinity group and/or an indication that the provider is the winning provider, etc.), for example.

The above discussion refers to the potential participation of reinsurers in affinity group auctions in order to initially obtain or renew/update insurance coverage for consumers/frequent shoppers. In some embodiments, however, separate auctions may take place that are specifically directed towards obtaining reinsurance to cover some portion of the liabilities associated with existing insurance policies, so that the provider/carrier can share its liability risk to some extent. In particular, an insurance provider (or an intermediary entity acting on the provider's behalf, etc.) may conduct an auction with multiple reinsurers to mitigate the provider's risks. In these auctions, rather than grouping consumers into affinity groups, different insurance policies may be divided into policy groups according to characteristics of the insured customers and/or their policies.

FIG. 10 depicts an exemplary environment 1020 that includes components associated with obtaining reinsurance, according to one embodiment. The environment includes a computing system 1022 of an insurance provider that provides insurance for a number of customers. In other embodiments, the computing system 1022 is the computing system of an intermediary entity acting on the provider's behalf. For example, the computing system 1022 may be the computing system 14 of FIG. 1.

The computing system 1022 may include one or more servers of the insurance provider, or may include a plurality of networked computing devices that have an appearance of a single, logical computing device or system, e.g., a group of cloud computing devices. The environment 1020 also includes computing systems 1024-1 through 1024-3 that are associated with respective reinsurance providers (“reinsurers”). In other embodiments and/or scenarios, computing systems 1024 may include computing systems associated with more or fewer reinsurers (e.g., no reinsurers, five reinsurers, etc.), and/or computing systems associated with one or more other entity types (e.g., investment fund management companies).

Each of the computing systems 1024-1 through 1024-3 may include one or more servers or computing devices of the respective reinsurer, and may be communicatively coupled to computing system 1022 via a network (not shown in FIG. 10). The network may be a single communication network, or may include multiple communication networks of one or more types (e.g., one or more wired and/or wireless LANs, and/or one or more wired and/or wireless WANs such as the Internet), for example. Each of the reinsurers associated with computing systems 1024-1 through 1024-3 may be a company that reinsures policies/liabilities for a particular type or types of insurance, such as automobile or other vehicle insurance, home or condominium insurance, personal property insurance, and/or life insurance, for example. Alternatively, some or all of the reinsurers may not be restricted to reinsuring particular types of insurance or liabilities.

The computing system 1022 may include various units, including a policy procurement unit 1030, a policy grouping unit 1034, and a reinsurance procurement unit 1036. One, some or all of the units 1030, 1034, 1036 may be (or may include) a respective set of one or more computing devices or processors that executes software instructions to perform the corresponding functions described herein. Alternatively, one, some or all of the units 1030, 1034, 1036 may be or include a respective component of software that is stored on one or more computer-readable media (e.g., a RAM and/or ROM of the computing system 1022) and executed by one or more processors of the computing system 1022 to perform the corresponding functions described herein. Further, two or more the units 1030, 1034, 1036 may be combined into a single unit.

Generally, policy procurement unit 1030 may perform various functions associated with generating or initiating insurance policies for consumers/customers (e.g., receiving consumer information via on-line application forms as discussed above). In some embodiments, policy procurement unit 1030 is similar to policy procurement unit 24 of FIG. 1 (e.g., if the insurance provider conducts its own affinity group auctions), or communicates with the intermediary entity of FIG. 1 (e.g., if the intermediary entity conducts affinity auctions on the insurance provider's behalf). In other embodiments, the insurance provider does not utilize affinity group auctions (directly or through an intermediary) to obtain insurance policies for customers. Data associated with each policy (e.g., policy numbers, personal information of policy owners and other covered individuals, property information, etc.) may be included in an insurance policy database 1032. Insurance policy database 1032 may be any suitable type of persistent memory.

Policy grouping unit 1034 may group or segment the insurance policies of database 1032 into groups that may be attractive to reinsurers, based upon characteristics of the insurance policies and/or the consumers associated with (e.g., the individuals who own and/or are covered by) those policies. For example, policy grouping unit 1034 may group together policies that have similar coverage types, limits, and/or deductibles. As another example, policy grouping unit 1034 may group together policies that cover individuals (and/or are owned by individuals) in the same age range, having the same marital status, having the same education level and/or occupation, having similar finances or income, having similar driving and/or accident histories, having similar driving behaviors (e.g., as indicated by vehicle telematics data), having similar risk scores, and so on. As yet another example, policy grouping unit 1034 may group together policies that cover the same or similar vehicle type, home type, geographic location (e.g., of consumer or of property), and so on.

Reinsurance procurement unit 1036 may conduct an automated auction in order to obtain reinsurance for the liabilities associated with the policies in each policy group. For a given policy group, reinsurance procurement unit 1036 may send information defining the group (e.g., membership criteria), and/or information about the individual policies (e.g., policy information stored in insurance policy database 1032), to each of the computing systems 1024-1 through 1024-3, along with a request for reinsurance quotes or offers.

After analyzing the information, one or more of the reinsurers may decide to bid on the reinsurance, and reinsurance procurement unit 1036 may receive the bid(s) from the respective ones of computing systems 1024-1 through 1024-3 via the communications network. Reinsurance procurement unit 1036 may send each received bid to all others of the computing systems 1024-1 through 1024-3, and bidding may continue in an iterative fashion until auction termination criteria have been met (e.g., until a predetermined amount of time elapses, or until a predetermined amount of time since the last bid elapses, etc.). The reinsurer having the best bid at the time the auction terminates may be granted the ability to reinsure at least a portion of the liabilities associated with the insurance policies in the policy group.

In some embodiments, the request (or other notice) that the reinsurance procurement unit 1036 sends to computing systems 1024-1 through 1024-3 indicates, or is otherwise associated with, a specific percentage share of liability that the winning reinsurer will take on (e.g., in exchange for that same share of profits associated with the policies that give rise to that liability). In other embodiments, the reinsurers specify a proposed percentage share of liability in their bids, and the reinsurance procurement unit 1036 considers this proposed share as well as other factors when deciding which of the current bids is better than the others.

FIG. 11 depicts an exemplary computer-implemented method 1040 for auctioning an opportunity to reinsure at least a portion of liabilities associated with one or more insurance policy groups, according to one embodiment. The method 1040 may be implemented by one or more processors of the computing system 1022 of FIG. 10, for example.

At block 1042, a plurality of insurance policies is divided into multiple policy groups, based at least upon one or more characteristics of the policies and/or consumers associated with those policies (e.g., the policy owners, and/or individuals covered by the policies). In some embodiments, the characteristics may include age, marital status, education level, occupation, finances or income, driving history, accident history, vehicle type, home type, geographic location, coverage type, and/or coverage level. Additionally or alternatively, in some embodiments, the characteristics may include at least one characteristic indicative of consumers' individual driving behaviors, and the method 1040 may include determining risk scores for the consumers based upon vehicle telematics data associated with the consumers. For example, the policy procurement unit 1030 may have determined the risk scores prior to procuring each insurance policy, and/or updated the risk scores at a later time.

At block 1044, an opportunity to reinsure at least a portion of the liabilities associated with one or more of the multiple policy groups is auctioned via the communications network. Each policy group having common characteristics (and/or associated with consumers having common characteristics) may be presented to potential bidders (e.g., to at least some of the entities associated with computing systems 1024-1 to 1024-3) via an electronic or online auction. For instance, the one or more processors, computing devices or servers may cause a particular policy group to be presented and/or offered for sale on remote display screens (such as via the internet or a secure communications network) of at least some of the computing systems 1024-1 to 1024-3. Additionally or alternatively, an indication of the particular policy group, the given group of insurance customers associated therewith, and/or an indication of the characteristics based upon which the policy group was formed, may be provided to the computing systems 1024-1 to 1024-3, and the computing systems 1024-1 to 1024-3 may automatically generate their respective bids based upon this information.

The auction participants may include reinsurance providers, and/or one or more other types of entities. For example, investment fund management companies may join the auction seeking an arbitrage opportunity, based upon their independent assessments of risk (which may differ from the insurance provider's assessment). In alternative embodiments, block 1044 includes auctioning financial instruments (e.g., bonds) that, if purchased, transfer at least some of the liability risk associated with a given policy group to the purchaser. Various financial instruments of this sort are discussed in U.S. patent application Ser. No. 15/869,685, filed on Jan. 12, 2018 and entitled “Risk Mitigation for Affinity Groupings,” the disclosure of which is hereby incorporated herein in its entirety.

At block 1046, one or more bids for purchase and/or offers of reinsurance for the one or more policy groups are received via the communications network. Bidders for the various policy groups may submit their bids via remote computers. The bids may be received by a processor or server associated with the provider running the auction via wireless or wired communication and/or data transmission.

At block 1048, a winning bid is accepted from among the one or more bids received at block 1046. For example, an accepted or winning bid may be determined based upon one or more criteria, such as the percentage of liability to be reinsured, the percentage of proceeds or profits in exchange for reinsuring the percentage of liability, a rating of the reinsurer, and/or other criteria. In one embodiment, the accepted or winning bid may be determined based upon a prioritization of the one or more criteria.

At block 1050, reinsurance is caused to be provided for insurance policies associated with a particular policy group that corresponds to the winning bid, thereby providing lower cost reinsurance and/or reinsurance that is more reflective of actual risk associated with the policies in the particular policy group. Block 1050 may include generating an acceptance of an offer in the winning bid, and/or transmitting that acceptance to the winning reinsurer's computing system, for example.

XII. Machine Learning Techniques for Affinity Group Auctions

Various aspects of the auction-related methods described herein may be augmented (e.g., made more efficient) with machine learning technologies. In some embodiments, for example, machine learning models are used to evaluate risks associated with different frequent shoppers for a particular type of insurance (e.g., risks of vehicular accidents or theft for auto insurance, risks of dwelling damage or theft for home or renter's insurance, etc.), prior to segmenting those frequent shoppers into different affinity groups based upon those risks.

In some embodiments, neural networks are used to evaluate such risks. FIGS. 12A and 12B depict the training 1100 and run-time operation 1120, respectively, of one such neural network 1102. The neural network 1102 may be a feedforward neural network, a radial basis function (RBF) neural network, or a recurrent neural network, or any other suitable type of neural network. The training 1100 and/or run-time operation 1120 may be performed by one or more processors in computing system 14 (e.g., by frequent shopper profiling unit 20), one or more processors in each of one or more of computing systems 16, one or more processors in computing system 1022, or one or more processors in each of one or more of computing systems 1024, for example.

At the training 1100 stage, training inputs 1110 and corresponding training labels 1112 are used to train the neural network 1102. In general terms, the training 1100 may comprise an iterative process of analyzing sets of the training inputs 1110 to predict or infer risk-related outputs (e.g., a particular risk score or classification), comparing each risk-related output to the corresponding label of training labels 1112, and updating weights between nodes of the neural network 1102 when the predicted or inferred risk-related output does not match the corresponding label.

The training inputs 1110 may include a number of input sets that each correspond to a different one of the training labels 1112. For example, each set of training inputs 1110 may include historical characteristics of a particular consumer, such as the consumer's age, gender, occupation, education level, geographical area of residence, vehicle type, driving behaviors, and so on (e.g., any of the frequent shopper/consumer characteristics discussed above).

Depending on the embodiment (i.e., what it is that neural network 1102 is being used to determine), the training labels 1112 may indicate real-world, risk-related outcomes for each set of training inputs 1110, or may indicate one or more risk-related characteristics of the consumers that were not specified in the training inputs 1110. In the first case, for example, each of training labels 1112 may be an indicator (e.g., binary classification) of whether the consumer was in an accident in a particular time period (e.g., the last three years), or a number of accidents in a particular time period, etc. Alternatively, each of training labels 1112 may indicate a specific risk score that was calculated for the consumer based on a particular algorithm, where the risk score is dependent on real-world, risk-related outcomes for the consumer (e.g., number of accidents, etc.). In these embodiments, neural network 1102 is trained to classify each consumer according to a particular risk-related classification system, or to predict a particular risk-related outcome.

In the second case, each of the training labels 1112 may be an indicator of a known characteristic of each consumer whose other characteristics were included in the training inputs 1110. As a relatively simple example, for each consumer reflected in the historical training data, training inputs 1110 may include the age, gender, occupation, and area of residence for the consumer, and training labels 1112 may indicate the education level of the consumer. As is well understood in actuarial science, “risk-related” characteristics encompasses a very broad set of characteristics that may be at least somewhat predictive of adverse outcomes (e.g., vehicular accidents, speeding tickets, etc.). In these embodiments, neural network 1102 is trained to infer the “missing” characteristic (i.e., the characteristic reflected in the labels 1112), or possibly multiple missing characteristics, for any given consumer.

Once trained, the neural network 1102 may be used in run-time operation 1120, by analyzing inputs 1122 indicative of sets of characteristics for consumers that are not reflected in the historical training data. As noted above, run-time operation 1120 may include classifying according to risk level or predicting risk-related outcomes, or may include inferring missing risk-related characteristics. The outputs of the neural network 1102 in run-time operation 1120 may be used by frequent shopper grouping unit 22, for example, to divide consumers into affinity groups. For example, neural network 1102 may classify or score consumers as very low risk (“1”) through very high risk (“99”), and frequent shopper grouping unit 22 may divide consumers into affinity groups based on that classification or score (and possibly also other factors, such as other consumer characteristics, and/or consumer preferences). As another example, neural network 1102 may infer a particular “missing” characteristic for each consumer based upon other, known characteristics of the consumer, and frequent shopper grouping unit 22 may divide consumers into affinity groups based on the inferred characteristic (and possibly also other factors, such as other consumer characteristics, and/or consumer preferences).

While FIGS. 12A and 12B focus on machine learning models that analyze consumer characteristics, the neural network 1102 may also, or instead, be trained to analyze consumer preferences, and to make inferences, predictions, or classifications that are not strictly risk-related. For example, training inputs 1110 may include historical consumer preferences (e.g., coverage types, coverage limits, deductibles, and whether electronic statements are preferred), and training labels 1112 may include an historical consumer preference that is missing from training inputs 1110 (e.g., how frequently the consumer switched insurance providers in the past, which is generally indicative of the consumer's preference for how long to maintain the same provider). In run-time operation 1120, frequent shopper grouping unit 22 may use the preferences output by the neural network 1102 to help divide the consumers into affinity groups (e.g., in part according to how often the consumer is likely to want to maintain the current provider).

Machine learning may also be used (e.g., by frequent shopper grouping unit 22) to define and/or refine affinity groups. For example, frequent shopper grouping unit 22 may implement a regression model to determine which groupings of consumers have historically attracted more interest (e.g., more frequent and/or higher bids) from insurance providers and/or other entities, and define the criteria for future affinity groups by selecting optimal combinations of those criteria. As another example, frequent shopper grouping unit 22 may implement a regression model to determine which groupings of consumers have historically had more stable group membership (e.g., fewer consumers exiting the affinity group in a given year, etc.), and define the criteria for future affinity groups by selecting optimal combinations of those criteria. Stable group membership may be more desirable to the intermediary entity for administrative reasons, for example, and/or may lead to more interest among bidders, for example.

Machine learning techniques may also, or instead, be used for other purposes, such as setting up an affinity group (or policy group) auction, and/or facilitating the auction itself. For example, policy procurement unit 24 may implement a machine learning model to determine which insurance providers or reinsurers to invite to participate in (or to notify of) an upcoming auction, by predicting which insurance providers or reinsurers are more likely to be interested in (e.g., more likely to submit bids for) providing insurance coverage to a particular affinity group, or are more likely to be interested in providing reinsurance for a particular policy group. As another example, policy procurement unit 24 may implement a machine learning model to determine a suitable starting bid (e.g., “reserve”) amount, by predicting an amount that will instigate the most bidding activity among the auction participants.

FIG. 13 depicts an exemplary computer-implemented method 1140 for auctioning insurance policies based upon affinity groups that are formed using machine learning, according to one embodiment. The method 1140 may be implemented by one or more processors of computing system 14 of FIG. 1, for example.

At block 1142, a plurality of consumers is divided into multiple affinity groups, at least by analyzing one or more characteristics and/or one or more preferences of the consumers, at least in part by analyzing the characteristic(s) and/or preference(s) using a machine learning model (e.g., neural network 1102). The characteristic(s) and/or preference(s) may be similar to any of those discussed above, e.g., in connection with block 1002 of the method 1000.

In some embodiments, block 1142 includes determining risk scores for the consumers by analyzing the characteristic(s) of the consumers using the machine learning model, and dividing the consumers into the multiple affinity groups based at least upon the risk scores and the preference(s) of the plurality of consumers. In other embodiments, block 1142 includes determining preference classifications for the consumers by analyzing the preference(s) of the consumers using the machine learning model, and dividing the consumers into the multiple affinity groups based at least upon the preference classifications and the characteristic(s) of the consumers.

In other embodiments, block 1142 includes determining classifications for the consumers by analyzing both the characteristic(s) and the preference(s) of the consumers using the machine learning model, and dividing the consumers into the multiple affinity groups based at least upon the classifications. In still other embodiments, block 1142 includes using the machine learning model to infer at least one additional characteristic and/or at least one additional preference for at least some of the consumers, and dividing the consumers into the multiple affinity groups based at least in part upon the at least one additional characteristic and/or the at least one additional preference.

At block 1144, an opportunity to provide insurance for one or more of the multiple affinity groups is auctioned, via a communications network (e.g., a single network or multiple coupled networks) to a plurality of entities (e.g., insurance providers, and/or possibly reinsurers, etc.). In some embodiments where block 1142 includes determining risk scores for the consumers (e.g., based on vehicle telematics data), block 1144 includes providing the risk scores to the entities participating in the auction (e.g., before the auction begins) via the communications network.

At block 1146, one or more bids are received via the communications network, and at block 1148 a winning bid is accepted from among the one or more bids received at block 1146. Blocks 1146 and 1148 may be similar to blocks 408 and 409 of FIG. 3, for example.

At block 1150, individual insurance policies, or a group insurance policy, is/are caused to be provided to or updated for consumers associated with a particular affinity group corresponding to the winning bid, thereby providing lower cost insurance and/or insurance that is more reflective of actual risk, or lack thereof, for the consumers associated with the particular affinity group. Block 1150 may be similar to block 1010 of FIG. 9, for example.

In some embodiments, the method 1140 includes one or more blocks prior to block 1142. For example, the method 1140 may include determining, by analyzing historical data indicative of (1) consumer characteristics and/or preferences for different affinity groups and (2) bidding activity for the different affinity groups, requirements for membership in each of the multiple affinity groups (e.g., using a regression model to determine affinity group criteria). As another example, if the machine learning model is a neural network, the method 1140 may include training the neural network using historical data indicative of (1) consumer characteristics and/or preferences for different consumers and (2) risk-related outcomes for the different consumers. As yet another example, the method 1140 may include receiving vehicle telematics data for the consumers, where the vehicle telematics data is indicative of one or more driving behaviors, and where the characteristic(s) of the consumers include the indicated driving behavior(s).

XIII. Additional Considerations

The following additional considerations apply to the foregoing discussion. Throughout this specification, plural instances may implement operations or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

As used herein any reference to “one embodiment” or “one embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

In addition, use of “a” or “an” is employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process of automatically obtaining and/or maintaining insurance coverage through the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Number	Date	Country
63013029	Apr 2020	US
63013032	Apr 2020	US
62503184	May 2017	US
62485725	Apr 2017	US
62471224	Mar 2017	US
62199008	Jul 2015	US
62189885	Jul 2015	US
62104596	Jan 2015	US
62060080	Oct 2014	US

	Number	Date	Country
Parent	16853691	Apr 2020	US
Child	16910687		US
Parent	15869752	Jan 2018	US
Child	16853691		US

	Number	Date	Country
Parent	14871401	Sep 2015	US
Child	15869752		US

Machine Learning Technologies for Efficiently Obtaining Insurance Coverage

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

CROSS-REFERENCE TO RELATED APPLICATIONS

Provisional Applications (9)

Continuations (2)

Continuation in Parts (1)