Patent Publication Number: US-2022215476-A1

Title: Machine Learning Technologies for Efficiently Obtaining Insurance Coverage

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation-in-part of U.S. application Ser. No. 16/853,691, filed on Apr. 20, 2020 and entitled “Blockchain Systems and Methods for Providing Insurance Coverage to Affinity Groups,” which is a continuation of U.S. application Ser. No. 15/869,752, filed on Jan. 12, 2018 and entitled “Blockchain Systems and Methods for Providing Insurance Coverage to Affinity Groups,” which is a continuation-in-part of U.S. application Ser. No. 14/871,401, filed on Sep. 30, 2015 and entitled “System and Method for Obtaining and/or a Maintaining Insurance Coverage.” U.S. application Ser. No. 14/871,401 claims priority to and the benefit of:
         U.S. Provisional Application No. 62/060,080 filed on Oct. 6, 2014 and entitled “System and Method for Obtaining and/or a Maintaining Insurance Coverage,”   U.S. Provisional Application No. 62/104,596 filed on Jan. 16, 2015 and entitled “System and Method for Obtaining and/or a Maintaining Insurance Coverage,”   U.S. Provisional Application No. 62/189,885 filed on Jul. 8, 2015 and entitled “System and Method for Obtaining and/or a Maintaining Insurance Coverage,” and   U.S. Provisional Application No. 62/199,008 filed on Jul. 30, 2015 and entitled “System and Method for Obtaining and/or a Maintaining Insurance Coverage.”
 
U.S. application Ser. No. 15/869,752 further claims priority to and the benefit of:
   U.S. Application No. 62/471,224, filed Mar. 14, 2017 and entitled “System and Method for Obtaining and/or Maintaining Insurance Coverage,”   U.S. Application No. 62/485,725, filed Apr. 14, 2017 and entitled “System and Method for Obtaining and/or Maintaining Insurance Coverage,” and   U.S. Application No. 62/503,184, filed May 8, 2017 and entitled “System and Method for Obtaining and/or Maintaining Insurance Coverage.”
 
This application also claims the benefit of U.S. Provisional Application No. 63/013,029, filed on Apr. 21, 2020 and entitled “Machine Learning Technologies for Efficiently Obtaining Insurance,” and U.S. Provisional Application No. 63/013,032, filed on Apr. 21, 2020 and entitled “Affinity Group Auctions for Reinsurers.” The disclosure of each of the  11  above-identified patent applications is hereby incorporated by reference herein in its entirety.
       

    
    
     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&#39;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&#39;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&#39; 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&#39; 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&#39;s desired insurance policy, such as demographic information (e.g., gender, birth date, etc.), information about the consumer&#39;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&#39; or end-consumers&#39; 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&#39;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&#39;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&#39; 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&#39;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&#39;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&#39;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&#39;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&#39; 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&#39; 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&#39;s and/or automobile insurance. Another group of customers may prefer a $1,000 deductible for homeowner&#39;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&#39;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&#39;s risk score and/or profile  414 . Based upon the data gathered and/or collected by one or more processors, each frequent shopper&#39;s profile, risk profile, and/or risk score may be updated to reflect low or high-risk behavior. Additionally or alternatively, a frequent shopper&#39;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&#39;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&#39;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&#39;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&#39;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&#39; 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&#39;s vehicle; updating the customer&#39;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&#39; 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&#39;s or vehicle&#39;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&#39;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&#39;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&#39;s premium, e.g., as a percentage of the affinity group&#39;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&#39;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&#39; 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  835   a - 835   n  associated with respective bidding entities, and/or may include an enforcement server  840 . The nodes  835   a - 835   n ,  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  835   a - 835   n ,  840 , even though the individual nodes  835   a - 835   n ,  840  may store local copies of the distributed ledger  832 . Generally speaking, the nodes  835   a - 835   n ,  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  835   a - 835   n  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  835   a - 835   n  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  835   a - 835   n  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  835   b  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  835   b  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  835   b.    
     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  835   a - 835   n , 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  835   a - 835   n , and may secure auction data that is shared between bidding entities  835   a - 835   n . 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  835   a - 835   n  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&#39;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  880   a - y  may be compiled into a block  882   a . For example, each of the plurality of computing devices or systems respectively corresponding to various bidding entities  880   a - 880   y  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  882   a . As such, in this example, each block  882   a  may correspond to one round of bidding, and/or a block  882   a  may correspond to the respective maximum bids (if any) of the bidding entities  880   a - 880   y.    
     In another example, a particular bidding entity  880   z  compiles a plurality of transactions generated at the particular bidding entity  880   z  into a block  882   b  that only includes transactions associated with the particular bidding entity  880   z . For instance, the various transactions included in the block  882   b  may respectively correspond to respective bids and/or respective no-bids of a plurality of auctions in which the bidding entity  880   z  is participating, and/or the block  882   b  may include respective indications of respective, maximum bid amounts for auctions in which the particular bidding entity  880   z  is participating. In this example, the particular bidding entity  880   z  may transmit, to the enforcement server  840 , the generated block  882   b  for distribution to a plurality of validation entities  838  that attempt to solve a cryptographic puzzle based upon the header of the generated block  882   b  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&#39;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&#39;s behalf, etc.) may conduct an auction with multiple reinsurers to mitigate the provider&#39;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&#39;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&#39;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&#39; 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&#39;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&#39;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&#39;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&#39;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&#39;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.