Computer System Architecture for Integrated Coverage Platform for Implementing an Adaptive Coverage Policy

A connectivity hub server detects the occurrence of a qualifying update event associated with a user and generates one or more recommended updates to the user's existing coverage based on the qualifying update event. Responsive to the user electing an adaptive coverage policy during an initial coverage binding process, the connectivity hub server periodically queries one or more third-party data sources for information associated with the user and analyzes the received information to detect the occurrence of a qualifying update event. Modules of the connectivity hub server determine one or more recommended coverage updates based on a stored mapping and implement one or more of the recommended coverage updates based on instructions from the user device.

BACKGROUND

1. Technical Field

The subject matter described generally relates to a coverage selection system, and in particular, to a system architecture including a connectivity hub with adaptive coverage features.

2. Background Information

Current computing systems used in providing coverage protection (e.g., insurance protection for goods and services) are configured so that a user seeking to bind multiple types of coverage must complete and submit multiple applications through separate processes. Each application requires large amounts of personal data about the user and requires the user to manually enter the data and/or the computing system to query third-party data sources to obtain the needed information, creating inefficiencies and increasing the likelihood of erroneous data entry. Additionally, a user's coverage needs are likely to change over time. For example, if the user whose current coverage includes a rental policy purchases a condo or single-family home, the initial coverage by which the user is bound may no longer fit the user's needs. However, current systems require the user to cancel their existing coverage and bind new coverage in a separate application process, leading to computational inefficiencies. Still further, the user may not understand how the purchase of a home or other life event impacts the user's coverage needs and may need to invest significant amounts of time in researching and/or speaking with a coverage provider about dozens of coverage options and endorsements that might not fit the user's needs, creating further inefficiencies in the coverage binding process.

SUMMARY

A connectivity hub server facilitates connections and interactions between processors associated with multiple entities participating in the purchase and sale of goods and related coverage services. In one embodiment, a customer user seeking coverage interacts, through a user client device or a dealer terminal, with a connectivity hub server and a coverage provider processor of a selected coverage provider to bind coverage for a selected coverage option. During the binding process, the user elects an adaptive coverage policy and consents to the connectivity hub server periodically querying third-party data sources to obtain information about qualifying update events associated with the user, such as the user's purchase of a home, the birth of a child, or the purchase of personal property valued at over a specified amount (e.g., a boat, a snowmobile, an RV, and the like). In other embodiments, the connectivity hub server is notified of the event through user input through the user client device. Responsive to detecting the occurrence or receiving a notification of the qualifying update event, the connectivity hub server queries a stored mapping to determine one or more proposed coverage updates to display to the user. For each qualifying update event, the mapping includes one or more recommended updates to a user's existing policy that add, remove, or change coverage. For instance, with respect to the examples discussed above, the mapping might indicate that the purchase of a boat is associated with a recommendation (e.g., via endorsement or rider) to add boat insurance (e.g., including one or more of liability, uninsured motorist, and collision/comprehensive coverage) or that the birth of a child is associated with a recommendation to add term life coverage to the user's existing policy. In one embodiment, where the qualifying update event is the purchase or other acquisition of real or personal property, the connectivity hub server instructs the user to submit one or more photos of the property and applies a risk algorithm to determine whether to provide the recommended coverage updates.

If the output of the risk algorithm indicates that the risk of providing coverage for the property is below a threshold level, the connectivity hub server provides the one or more recommended updates for display to the user through the user client device. Responsive to receiving user input comprising an instruction to implement one or more of the recommended updates, the connectivity hub server updates the existing coverage in accordance with the user input and, in some embodiments, notifies a coverage provider processor of the coverage update.

DETAILED DESCRIPTION

The Figures (FIGS.) and the following description describe certain embodiments by way of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods may be employed without departing from the principles described. Reference will now be made to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers are used in the figures to indicate similar or like functionality.

Example Networked Computing Environment

FIG. 1illustrates one embodiment of a networked computing environment100that facilitates connections between processors associated with client devices, coverage providers, dealers, and third-party data sources to adapt coverage services based on the occurrence of qualifying update events. In the embodiment shown inFIG. 1, the networked computing environment100includes a connectivity hub server105in communication through a network110with a user client device115, a dealer terminal120, one or more coverage provider processors125A-N, one or more coverage provider agent devices130A-N, one or more third party data sources135A-N, and a comparative rater platform140. In other embodiments, the networked computing environment100contains different and/or additional elements. In addition, the functions may be distributed among the elements in a different manner than described.

FIG. 1uses like reference numerals to identify like elements. A letter after a reference numeral, such as “130A,” indicates that the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter, such as “130,” refers to any or all of the elements in the figures bearing that reference numeral. For example, “130” in the text references to the reference numerals “130A” and “130N” in the figures.

The connectivity hub server105provides a platform that allows customer, dealer, and coverage provider users to interact to bind and update coverage between the customer user (referred to as a “user” herein) and a selected provider based on the occurrence of a qualifying update event. In various embodiments, the modules of the connectivity hub server105enable these interactions by analyzing user data received from the third-party data sources135to detect occurrence of a qualifying update event, querying the user client device115to confirm the occurrence of the event, receiving user input to update existing coverage based on the occurrence of the event, and instructing a coverage provider processor125A to update existing coverage for the user. Various embodiments of the connectivity hub server105are described in greater detail below, with reference toFIG. 2.

The network110comprises any combination of local area and/or wide area networks, using both wired and/or wireless communication systems. In one embodiment, the network110uses standard communications technologies and/or protocols. For example, the network110includes communication links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, code division multiple access (CDMA), digital subscriber line (DSL), etc. Examples of networking protocols used for communicating via the network110include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP). Data exchanged over the network110may be represented using any suitable format, such as hypertext markup language (HTML) or extensible markup language (XML). Those skilled in the art will recognize that encryption using other suitable techniques will be appropriate for various applications based on the nature of the network110.

The user client device115, the dealer terminal120, and the one or more coverage provider agent devices130are computing devices capable of receiving user input as well as transmitting and/or receiving data via the network110. In one embodiment, the devices115and130and the terminal120are conventional computer systems, such as a desktop or laptop computer. Alternatively, the devices115and130and the terminal120are devices having computer functionality, such as a mobile telephone, a smartphone, a set-top box, a smart home device, or another suitable device. The devices115and120and the terminal120further include an input/output (I/O) component to transfer data to, and receive data from, other entities in the networked computing environment100, and a storage unit to store, for example, coverage documents for a selected policy.

In various embodiments, the devices115and130and the terminal120connect through the network110to the connectivity hub server105and/or directly (e.g., using a peer-to-peer protocol) to one or more other devices115and130or the terminal120in the networked computing environment100. For example, in one embodiment, the user client device115connects through the network110to the connectivity hub server105to input user data and obtain information regarding available coverage options (e.g., through an application associated with the connectivity hub server105or through a web browser on the user client device115). Alternatively, the user interacts with the connectivity hub server105through the dealer terminal120.

Each coverage provider processor125is associated with one or more coverage provider agent devices130through which users interact with a selected coverage provider to bind coverage or to update existing coverage based on the occurrence of one or more qualifying update events. The coverage provider processor125receives requests from the user through the user client device115or the dealer terminal120for policy coverage options and generates rates based on user data received through the connectivity hub server105. Responsive to the user selecting an available coverage option, the coverage provider processor125A of the selected provider establishes a direct connection with the user client device115or the dealer terminal120(e.g., to bind and purchase coverage or to update existing coverage, as discussed below with respect toFIG. 2).

The environment100ofFIG. 1also includes one or more third-party data sources135A-N that store user data used by the connectivity hub server105to facilitate generating, selecting, and updating coverage options. In one embodiment, the third-party data sources135include one or more coverage providers, such as the coverage providers associated with the coverage provider processors125. Other third-party data sources135include financial institutions, mortgage providers, data analytics and risk assessment entities, credit bureaus, and public databases from which the connectivity hub server105obtains data that the user has consented to sharing for purposes of the coverage binding and updating process. Data received from the third-party data sources135is used, for example, to prefill user applications for insurance coverage, thus improving the efficiency and accuracy of the coverage selection process by reducing the amount of user data entered manually by the user or dealer. Received user data is further used, in some embodiments, by the connectivity hub server105to verify the accuracy of user data manually input through the user client device115. Still further, the modules of the connectivity hub server105analyze user data from the third-party data sources135to determine whether one or more qualifying update events has occurred and query the user through the user client device115to confirm the occurrence of the event and to determine whether an existing coverage policy should be updated accordingly.

In various embodiments, user data provided by the third-party data sources135to the connectivity hub server105includes personally identifiable information (PII) about the user. User data further includes, in various implementations, demographic data, vehicle driving record violations and incidents, vehicles/equipment currently in possession of the user and related liens and leases, current insurance coverage types and amounts and associated carrier(s), insurance claim history for a user, the user's household members and real and personal property. As discussed below with respect toFIG. 2, the modules of the connectivity hub server105analyze the user data to determine the occurrence of one or more qualifying update events, such as a financial event (e.g., the purchase of a condominium or single-family home, the purchase or other acquisition of personal property valued at over a specified amount (e.g., a boat, a snowmobile, an RV, an engagement ring, etc.), or a life event (e.g., a wedding, divorce, birth of a child, etc.).

The comparative rater platform140generates available coverage options and rates for a requesting user based on received user data. In one embodiment, the comparative rater platform140uses direct API access to one or more coverage provider processors125to obtain and aggregate coverage option and rate data. The aggregated data is stored and used to generate coverage options for a user without requiring the modules of the connectivity hub server105to query the coverage provider processors125directly. The connectivity hub server105thus queries the comparative rater platform140with a completed coverage application for a requesting user, and the comparative rater platform140returns initial coverage options and rates based on the stored coverage provider data and the received coverage application. In some embodiments, the connectivity hub server105performs risk filtering before sending the user application to the comparative rater platform. For example, in some implementations, the connectivity hub server105uses machine learning to predict, for new users, which coverage provider the user might select, how long the user might remain with the selected coverage provider, etc. Additionally, while the displayed embodiment shows the comparative rater platform140as a third-party platform connected through the network110to the connectivity hub server105, in other embodiments, the comparative rater platform is a module on the connectivity hub server105.

Example Connectivity Hub Server Subsystems

FIG. 2is a block diagram of an architecture of the connectivity hub server105. The connectivity hub server105shown inFIG. 2includes a front-end module205, an identity verification module210, a data communications module215, a coverage processing module220, a coverage management module225, a coverage communications module230, a rules engine235, a rating engine240, a user data store245, and a provider data store250. In other embodiments, the connectivity hub server105includes additional, fewer, or different components for various applications. Conventional components such as network interfaces, security functions, load balancers, failover servers, management and network operations consoles, and the like are not shown so as not to obscure the details of the system architecture.

The front-end module205facilitates communication between the connectivity hub server105and the user client device115, the dealer terminal120, the coverage provider processors125, and the third-party data sources135. In one embodiment, the third-party data sources135interact with the connectivity hub server105through the front-end module205to provide requested user data. Coverage provider processors125also interact with the connectivity hub server105through the front-end module205to provide new or updated coverage options based on the received user data. Similarly, the user client device115submits requests for coverage options and inputs user data to the connectivity hub server105through the front-end module205. For example, in one embodiment, user data input through the front-end module205includes basic user information, such as the user's name, address, date of birth, driver's license number, phone number, email address, marital status, residence type, gender; other pertinent information, such as information concerning a vehicle or other good being purchased, accidents, violations, or losses associated with the user during a specified time period; information about the user's current coverage, such as the user's current insurance company(ies), premium(s), whether the user is eligible for policy discounts; and related permissions, including permission for the connectivity hub server105to query one or more third-party data sources135to obtain additional data about the user, such as the user's current insurance score. In other embodiments, the front-end module205prompts the user to enter minimal PII, such as the user's phone number, the zip code of the user's primary residence, and/or the user's date of birth. The front-end module205transmits the received user data to the identity verification module210, which verifies the user's identity, as discussed below.

In some embodiments, the front-end module205further uses machine learning to determine which third-party data source(s)135to query to obtain additional data about the user. For example, the amount and type of data stored by each of the third-party data sources135for users of the connectivity hub server105may vary based on, e.g., whether the user is a user of the third-party data source135or whether the type of data stored by the third-party data source135is relevant to the request for coverage. In some embodiments, input to a machine learning model includes one or more items of user profile data, including the user's likelihood of purchasing coverage, how many vehicles and drivers are in the user's household, an expected closing ratio, and the like. The model outputs an indication of one or more third-party data sources135to query for additional user data.

The front-end module205further queries the user client device115to obtain user consent to sharing the collected user data with one or more third-party data sources135and one or more coverage provider processors125. For example, in one embodiment, the connectivity hub server105transmits minimal PII about the user to one or more third-party data sources135to obtain additional information about the user that may be used, for instance, to prefill a user application for insurance coverage. In another example, user data obtained from user input (via the user client device115or the dealer terminal120) and/or from third-party data sources135is transmitted to one or more coverage provider processors125, of which a subset of the coverage provider processors125return available coverage options based on the transmitted user data. Responsive to the connectivity hub server105receiving the available coverage options, the front-end module205provides the coverage options for display on the user client device115.

In embodiments in which a user's existing coverage is updated based on the occurrence of a qualifying update event, the front-end module205queries the user through the user client device115to confirm the occurrence of the event and to determine whether the user wants to update existing coverage based on the occurrence of the event. For example, responsive to the modules of the connectivity hub server105detecting, using data received from a third-party data source135, that a user whose existing coverage includes renter's insurance (with renter rates for personal property coverage) is purchasing a condominium or single-family home, the front-end module205queries the user client device115to confirm the user's purchase and to ask the user whether they want to endorse the existing policy to update the user's address, add dwelling, outbuilding, personal liability with a higher limit, medical payments, and other optional coverages typically associated with condominiums and single-family homes without starting a new policy. In another example, responsive to the modules of the connectivity hub server105determining that the user or their partner has given birth to a child, the front-end module205queries the user with a suggestion that the user endorse the user's existing policy with term life coverage. Alternatively, detection of a qualifying update event is based on user input through the user client device115(e.g., via an application associated with the connectivity hub server105or through a native web browser on the user client device115). For instance, in one example, the user provides input indicating that the user purchased an engagement ring or other valuable item of personal property, and the front-end module205queries the user client device115to suggest that the user increase existing personal property coverage. In either embodiment, responsive to receiving input from the user client device115instructing the connectivity hub server105to update the existing coverage, the front-end module205notifies the coverage management module225of the update instruction, as discussed below.

In some embodiments, in response to detecting the occurrence of a qualifying update event or receiving user input notifying the connectivity hub server105of the event occurrence, the front-end module205queries the user (e.g., through an application associated with the connectivity hub server105) to submit one or more photos associated with the event, e.g. using a camera on the user client device115. For example, if the qualifying update event is the purchase of a boat, the front-end module205instructs the user client device115to initiate the camera to allow the user to take one or more photos of the boat (e.g., from different angles). The front-end module205similarly prompts the user to provide one or more photos through the application on the user client device115if the qualifying update event is associated with the purchase or renovation of real property. Responsive to receiving the one or more photos, the front-end module205sends the photos to the rules engine235to determine whether the user's existing coverage may be updated based on the event occurrence. In this way, the user is able to avoid physical inspections typically required to bind or update coverage. The front-end module205subsequently transfers the photos to the coverage provider agent device130A associated with the selected coverage provider processor125A for a human agent to process. In embodiments in which a direct communication is established between the user client device115and the selected coverage provider processor125A, the user client device115sends the photos with the application through the front-end module205to the selected coverage provider directly to bind or update coverage.

In embodiments in which the user is seeking to bind coverage, the identity verification module210verifies the user's identity based on the user data received through the user client device115. For example, in one embodiment, a user of the dealer terminal120inputs a phone number of a user through the front-end module205. Responsive to receiving the phone number, the identity verification module210sends a message (e.g., via SMS, text, email, or the like) to the user client device115associated with the phone number. Selection of an address (e.g., HTTP, URL, or other network address) in the message connects the user client device115to the front-end module205, which prompts the user to enter one or more items of PII, such as the user's zip code of primary residence and date of birth. The identity verification module210compares the received PII with data received from one or more third-party data sources135that store information, including unique identifying information, describing the ownership and use relationships between users and associated devices and verifies the user identity based on the compared data (i.e., based on the received PII matching the client device115from which the PII was sent). For example, in one embodiment, the identity verification module210combines the PII with one or more unique network interface device address/identification numbers (e.g., a SIM card, EMIEA number, or the like) to locate a subscriber record in a consumer information database connected to the connectivity hub server105and appends the subscriber data record to the PII received from the user client device115.

The data communications module215interfaces with the third-party data sources135to obtain additional data about the user. Third-party data sources135typically provide data in various formats that are not all consistent with any particular standard or with one another. Data communications module215accordingly provides, for each of such data sources135, a mechanism for properly communicating with such source.

In one embodiment, the data communications module215uses a carrier onboarding tool (not shown) with a rules engine to determine the coverage provider processors125to which to send user data. User data is gathered from a variety of sources, including via data entry through the user client device115or the dealer terminal120and one or more third-party data sources135who provide marketing data, public data, court-based records, and other user data that the user has consented to sharing for purposes of the coverage binding or updating process. Based on user data such as household composition, driver class, driving history, and insurance status, the carrier onboarding tool interacts with a machine learning trained predictive model to predict the most appropriate coverage provider(s) for receiving the user data.

The carrier onboarding tool (COT) is a system that integrates with multiple rating provider systems (not shown), including a rating engine240), to obtain, aggregate, reconcile, and standardize coverage rating configuration data and to rate risks for a plurality of carriers (e.g., every risk for every carrier in every state). The system allows a user to reconcile coverage provider, carrier, and state-specific differences and generates a unified and standardized set of questions and configuration data elements. In one embodiment, the COT system allows a user to provide input to manually define single standardized names, default values, and mappings for each of the coverage provider and state-specific data elements. Additionally or alternatively, the COT system provides user-configurable rules that are used to define a mapping logic used during the data field standardization process. The COT system publishes a unified, standardized coverage rating configuration data set via an API to other software applications. Additionally, the system tracks rating configuration data sets via a versioning mechanism such that specific configuration data set are stored, retrieved, copied, and/or reused as explicit configuration versions. Still further, the system allows the automated comparison of stored rating configuration versions via a graphical view (e.g., displayed in an application on the user client device115) that highlights changes between versions and permits a user to update data field configuration values.

In one embodiment, the data communications module215provides direct API access to the connectivity hub server105to a coverage provider processor125to allow the coverage provider to control and customize a user interface of the connectivity hub server105. Additionally, in some embodiments in which a user's existing coverage is updated, the data communications module215receives updated user information from the third-party data sources135and sends the received user data to the coverage processing module220, as discussed below. In one example, the data communications module215queries one or more public records databases to request information about qualifying update events associated with the user, such as life events (e.g., marriage certificates, divorce certificates, birth certificates, etc.), information about the purchase, sale, renovation, or construction associated with real property (e.g., building permits, variances, special exemption permits, property transfer records, tax liens, changes to a property's square footage, etc.), information about the purchase or other acquisition of personal property valued at over a specified amount (e.g., a boat or a snowmobile), and/or information about a business entity associated with the user (e.g., registration information for a sole proprietorship, LLC, corporation, or partnership established by the user, a trademark application filed by the user, etc.). In one embodiment, the third-party data sources135include LexisNexis's Active Insight product, which provides to the data communications module215data about an existing user of the connectivity hub server105listing a property for sale. Other embodiments use other commercially available third-party data sources135instead of or in addition to the Active Insight product based on the specific application of the networked computing environment100. “The data communications module215then sends the received data to the rules engine235, which signals a variety of life events identified and returns coverage recommendations pre-bundled for qualified life events from the coverage processing module220, as described below, to the front-end module205for the user to confirm the occurrence of the events or to update coverage.

In embodiments in which the user is seeking to bind coverage, the coverage processing module220aggregates user data received from the third-party data sources135and prefills one or more fields of an application for coverage using at least the user data received through the user client device115and the additional user data. In some embodiments, the coverage processing module220provides the additional user data for display on the user client device115to allow the user to verify the accuracy of the received data. The prefilled application is similarly provided to the user for approval before the coverage processing module220submits the completed application to the one or more coverage provider processors125. Additionally, if the coverage processing module220determines that the user data received from the third-party data sources135does not include data responsive to one or more fields of the application, the coverage processing module220queries the user to provide the missing data. The user is further queried, in some embodiments, to answer one or more provider-specific questions based on the product line for which the user seeks coverage (e.g., auto, home, umbrella, etc.). Additionally, in some embodiments, the coverage processing module220allows the user to opt-in to an adaptive coverage policy as described herein.

In some embodiments, the coverage processing module220sets one or more terms of the application to a default amount, such as a default limit of liability (e.g., 100,000/300,000/500,000) and/or the choice of full coverage (e.g., comprehensive and collision coverage with a $500 deductible) such that the user client device115and/or the dealer terminal120display interface elements informing the user and/or the dealer user that the terms cannot be changed. The default terms are included in the application during the initial quoting process and may, in some implementations, be reviewed and adjusted during subsequent interactions between the user and the selected coverage provider. After the user selects an available coverage provider, the coverage processing module220facilitates the processing of the associated coverage option by generating documents such as applications, disclosures, identification cards, binders, and the like, and processing user payment by displaying and accepting user credit card and bank account information.

Additionally, in embodiments in which a user's existing coverage is updated, the coverage processing module220receives and analyzes the updated user information from the data communications module215. In one embodiment, the coverage processing module220maintains a list of qualifying update events and compares the received user information to the list of qualifying update events to determine whether an event has occurred. For example, if the information indicates that the user is married, the coverage processing module220determines that the user is likely to possess one or more items of personal property valued at over a specified amount that are not covered in the user's existing coverage policy. In another example, the coverage processing module220determines that the user has obtained a building or zoning permit associated with a piece of real property and thus likely intends to add a new structure (e.g., a fence, an attached garage, and the like) to the property. Responsive to detecting the occurrence of a qualifying update event based on the received user information, the coverage processing module220notifies the coverage management module225to prompt one or more coverage updates.

In other embodiments, detection of a qualifying update event is based on user input. In this implementation, the user provides input through the user client device115to notify the connectivity hub server105of the user's purchase of the engagement ring or the building permit. The front-end module205notifies the coverage processing module220of the user input, and the coverage processing module220sends the notification to the coverage management module225to determine one or more proposed coverage updates.

In still other embodiments, detection of a qualifying update event is based on the connectivity hub server105determining that one or more members of the user's family have reached a specified age. For example, if the connectivity hub server105determines that the user's son turned 15, front-end module205might query the user to determine whether the user wants to add their son to an existing auto policy. Similarly, if it is determined that the user's daughter turned 17 or 18, the front-end module205might ask the user whether they want to add to the existing coverage an endorsement covering the user's property off-premises.

In embodiments in which the user is seeking to bind coverage, the coverage management module225queries each of a plurality of coverage provider processors125for available coverage options based on the generated application. In one embodiment, the data communications module215requests, from each coverage provider processor125, a “rate call1” rate, such that the rate is non-binding and is based on data provided by the user (i.e., the accuracy of the user-provided data is not verified by data from one or more third-party data sources135). As discussed below, in some embodiments, the coverage management module225queries a subset of the coverage provider processors125for updated coverage options (i.e., “rate call2” rates) responsive to receiving additional data about the user from one or more third-party data sources135. In another embodiment, the coverage management module225sends the completed application to the comparative rater platform140, which returns one or more initial coverage options and rates based on the user data and stored coverage data for the coverage provider processors125.

In some embodiments, the coverage management module225optimizes profitability via machine learning by using a trained model to determine which of the received coverage options to provide for display to the user. In various implementations, input to the trained model includes user data such as household composition, driver class, driving history, insurance status and history, and data associated with the vehicle that the user is purchasing. Input to the model further includes profitability data indicating the user's likely retention rate, a commission rate, and the like. For example, if stored profile data for user A indicates that the user is likely to stay with a coverage provider for a long period of time, the model outputs an instruction to display to the user only available coverage providers that have a higher lifetime expectancy.

In embodiments where additional user data is provided to a dealer terminal120used by a dealer user (e.g., an employee of a dealership at which the user is purchasing a vehicle), the coverage management module225obscures some or all of the received from the third-party data sources135on the display of the dealer terminal120. In some implementations, the coverage management module225analyzes the received user data and determines whether one or more data items have at least a threshold level of sensitivity (e.g., the data includes the user's credit card number, income information, PII, or the like). Responsive to determining that the sensitivity level for one or more data items exceeds the threshold, the coverage management module225obscures the data items such that the dealer user is not able to see the sensitive user data. Rather, the coverage management module225provides for display on the dealer terminal120an indication that the data collection has been completed. Additionally, in embodiments in which the user is seeking to bind coverage (e.g., auto insurance coverage), the coverage management module225queries the rules engine235to generate quotes for one or more additional coverage options based on user data obtained from the coverage application and from one or more third-party data sources135, as discussed below.

In embodiments in which the coverage management module225receives a notification of a qualifying update event from the coverage processing module220, the coverage management module225queries a stored mapping to determine one or more proposed coverage updates to propose to the user. For each qualifying update event, the mapping includes one or more proposed updates to a user's existing policy that add, remove, or change coverage. For instance, with respect to the examples discussed above, the mapping might indicate that the purchase of a boat is associated with a proposal (e.g., via endorsement or rider) to add boat insurance (e.g., including one or more of liability, uninsured motorist, and collision/comprehensive coverage) or that the building permit is associated with a proposal to add outbuilding coverage and/or increase existing personal liability coverage (e.g., adding a fenced pool in the backyard).

In some embodiments, each qualifying update event is associated with a pre-defined endorsement bundle with suggested coverage updates. For example, if it is determined that the user is renting out a portion of their residence for home sharing or business purposes, the coverage management module225recommends a set of coverage related to the situation (e.g., extending existing homeowners coverage to a short-term rental, adding an endorsement to cover a temporary rental, or adding landlord or business insurance). In another example, if the user's child moves into a dorm or apartment, the coverage management module225recommends a different endorsement bundle (e.g., adding coverage for the user's vehicles or other personal property off-premises).

Responsive to determining one or more proposed coverage updates based on the qualifying update event(s), the coverage management module225instructs the front-end module205to query the user (e.g., through the user client device115) to confirm the occurrence of the event and to provide for display the proposed coverage update. For example, the front-end module205might provide a message querying the user “Did you purchase an RV?” If the user confirms the purchase, the front-end module205might provide a secondary message stating “Would you like to speak with someone about adding RV coverage?” Similarly, if the qualifying update event is the user obtaining the building permit, the front-end module205might provide a message querying the user “Did you recently obtain a building permit for 123 Main Street?” If the user answers in the affirmative, the front-end module205might provide a secondary message stating “Would you like to speak with someone about adding outbuilding coverage to your property?” If the user confirms an intent to update the user's existing coverage, the front-end module205notifies the coverage management module225of the update instruction. Responsive to receiving the notification, the coverage management module225updates the existing coverage for the user in accordance with the user input (i.e., by updating a user profile in the user data store245).

Additionally, in some embodiments, the front-end module205notifies the coverage communications module230of the user input, as discussed below. The coverage communications module230facilitates communication between the user and a selected coverage provider by establishing a direct communication channel between the user client device115and the coverage provider agent device130A associated with the selected coverage provider processor125A. In one embodiment, the user selects a preferred method of communication with the selected coverage provider, such as instant messaging, video call, or telephone call. The coverage provider may prompt the user to answer additional questions or provide additional information in accordance with the provider's policies or requirements. Additionally, in some embodiments, the coverage communications module230provides for display on the coverage provider agent device130A an interface allowing the coverage provider to access the user's completed application and/or additional data associated with the user and stored in the user data store245, such as motor vehicle records and accident and claim history reports.

In one embodiment, the direct connection generated by the coverage communications module230allows the user and the coverage provider to communicate about available coverage options and select a policy that fits the user's needs. The coverage provider provides a bindable quote to the user and sends to the user policy documentation associated with the selected coverage option. For example, in one embodiment, the coverage provider processor125A sends the policy documentation directly to the user client device115(e.g., via email). In other embodiments, the policy documentation is uploaded to the connectivity hub server105such that the user client device115can access the documentation through the front-end module205. In some implementations, the policy documentation includes one or more documents for execution by the user. The user accesses the documents, for example, by using a hyperlink provided by the coverage provider processor125A and executes the documents using DocuSign or another means of electronic signature.

Additionally, in embodiments in which the user seeks to update existing coverage, as discussed above, the direct connection generated by the coverage communications module230allows the user to communicate with the coverage provider associated with the user's current policy to discuss the qualifying update event and to execute policy documentation associated with the one or more proposed coverage updates without terminating the existing policy.

In embodiments in which the user seeks to bind coverage, the rules engine235analyzes user data to determine whether the user qualifies for policy price-matching. In one embodiment, the rules engine235queries the user for the user's account information (e.g., ID and password) associated with a first type of coverage (e.g., homeowner's insurance coverage). The rules engine235uses the received account information to query one or more third-party data sources135(e.g., mortgage escrow companies, title companies, government agencies, provider databases, etc.) for information about the user's current coverage such as the current policy provider, term, term limits, premium, insurance dwelling or property, coverage, limits, and deductibles. If the third-party data sources135do not return all of the requested user data, the rules engine235queries the user through the user client device115to provide the requested data. For example, if the user uploads a copy of a policy declaration through the front-end module205, the rules engine235uses optical character recognition (OCR) on an image of the declaration page and analyzes the result of the OCR to determine the applicable coverage, limits, and deductibles.

Expense ratios, profit margins, rating factors, risk algorithms, and related data of available providers are aggregated and stored in a provider data store250on the connectivity hub server105. Responsive to receiving the current coverage information for the user, the rules engine235uses data retrieved from the provider data store250and the current coverage information to calculate a predicted loss cost for the user under the user's current policy. In one embodiment, the rules engine235adds the allocated expense load and profit margin to determine the desired price and compares the desired price and the pre-determined price to determine if the specific risk is acceptable (i.e., if the user qualifies for price-matching). Alternatively, the rules engine235calculates the allowable gross profit margin and compares the desired gross profit margin and the allowable gross profit margin to determine if the specific risk is acceptable.

If the rules engine235determines that the user qualifies for price-matching, the front-end module205provides for display information about the proposed coverage package and individual policy price and savings based on the price-match offer. Conversely, if the rules engine235determines that the user does not qualify, the rules engine235identifies gaps in the user's current coverage and alerts the user, through the front-end module205to a possible exposure or coverage overage and prompts the user to speak with an agent.

In some embodiments, the rules engine235performs an image-mining algorithm to one or more photos submitted by the user through the user client device115to determine whether to suggest additional or updated coverage for one or more items of personal or real property depicted in the photo(s). If the output of the algorithm indicates that the risk is as described in the application and is under insurable conditions, the rules engine235approves the display of the recommended coverage updates to the user.

Still further, the rules engine235uses user data obtained from the completed coverage application and/or from one or more third-party data sources135to generate a quote for one or more types of additional coverage for the user. For example, user data used to complete the coverage application to bind auto insurance is supplemented, in one embodiment, by additional user data obtained from a financial institution or mortgage company to generate a homeowners' insurance quote for the user. In this way, the rules engine235is able to generate an additional coverage quote for the user with no or few additional questions required for manual input from either the user or the dealer. The user may then provide input to complete the binding process (e.g., by making payment or signing policy documents) on the user client device115.

The rating engine240uses user data obtained from the completed coverage application and/or one or more third-party data sources135to generate an estimated premium for one or more types of additional coverage (e.g., homeowner's or renter's coverage). Commercial software is available for providing ratings for standalone purposes and, in one embodiment, is integrated into the connectivity hub server105to provide coverage premium(s). For example, in some embodiments, one or more of the PL Rating product of Vertafore, the DRC Rater of the Decision Research Corporation (DRC), and the CD Rating product of ClarionDoor are used to implement the rating engine240. In this situation, the connectivity hub server105queries the coverage provider processor125directly and generates coverage options and premiums. Along with those obtained from the comparative rater platform140, the connectivity hub server105sends all coverage options and premiums to the user client device115or to the dealer terminal120for the user to compare.

Each user of the connectivity hub server105is associated with a user profile, which is stored in the user data store245. A user profile includes declarative information about the user that was explicitly shared by the user and also includes additional user information received from the third-party data sources135and one or more coverage provider processors125. In one embodiment, a user profile includes multiple data fields, each describing one or more attributes of the corresponding user. Examples of data stored in a user profile include biographic information, employment and income information, credit information, payment information, current and past residences, household information, contact information, mobile device carrier, and current and past insurance policies and individuals and property covered by the policies. In certain embodiments, the user profile further includes policy documentation, such as completed applications and executed policy documents, as well as records of user consent to allow the modules of the connectivity hub server105to access and use the user data in the coverage selection and updating process. Stored data about a user is used, in some embodiments, to prefill applications or other documents such that the user does not have to provide data previously submitted to the connectivity hub server105and to update a user's existing coverage based on the occurrence of one or more qualifying update events. In such embodiments, the user instead is prompted, through the front-end module205, to validate or update the stored information.

Example Coverage Adaptation Process

FIG. 3is a data flow illustrating a method for binding an adaptive coverage policy, according to an embodiment. The steps ofFIG. 3are illustrated from the perspective of the connectivity hub server105that performs the method300. However, in various implementations, some or all of the steps are performed by other entities or components. In addition, some embodiments perform the steps in parallel, perform the steps in different orders, or perform different steps. In addition, the steps are embodied as instructions executable by a processor of a machine, for example, as described byFIG. 6.

At305, the user initiates the coverage binding process through the user client device115or the dealer terminal120by sending a request for coverage to the connectivity hub server105. In one embodiment, the coverage request is a request to bind auto insurance coverage and includes user data including a user name, phone number, and information about the vehicle, such as the year, make, model, VIN, stock number, or the like. In some embodiments, responsive to receiving the user phone number, the front-end module205queries the user client device115requesting consent to access, use, and store user PII as part of the quotation and binding process.

In some embodiments, user PII is further used to verify the user's identity. For example, the front-end module205receives input from the user client device115of minimal PII, such as the user's zip code of primary residence and date of birth. The received PII is transmitted to the identity verification module210, which verifies the user's identity by matching the received PII to the device from which the PII was sent. For example, the identity verification module210combines the received PII with one or more unique network interview device address or identification number(s) (e.g., SIM card, EMIEA number, etc.) assigned to the device to locate a subscriber record in a consumer information database connected to the connectivity hub server105and appends the subscriber record data to the received PII.

At310, data communications module215queries one or more third-party data sources135containing PII and additional user information to append a plurality of additional PII, demographic, and other subscriber/prospective retail user information required for or pertinent to the user transaction (e.g., the purchase of a vehicle) and/or the user request for coverage. Additionally, in some embodiments, the additional user information includes information used to generate a homeowners or renters insurance quote for the user, including information from a financial institution, mortgage provider, data analytics and risk assessment entity, or credit bureau. Responsive to receiving the additional user information, the coverage processing module220aggregates the received data and prefills315one or more fields of a coverage application associated with the requested coverage. In one embodiment, the prefilled application is transmitted to the user client device115, and, optionally, the dealer terminal120, to allow the user and dealer to review, edit, and/or complete the prefilled application prior to submission to one or more coverage provider processors125. Additionally, in embodiments in which the prefilled application is sent to a dealer terminal120, some or all of the additional user information from the third-party data sources135is obscured on the dealer terminal120. For example, as discussed above with respect toFIG. 2, the coverage management module225analyzes the received user data to determine whether one or more data items have at least a threshold level of sensitivity (e.g., the data includes the user's credit card number or income information). Responsive to determining that the sensitivity level for one or more data items exceeds a threshold, the coverage management module225obscures the data item(s) on the dealer terminal120such that the dealer is not able to see the sensitive user data. The sensitive data, however, is provided for display on the user client device115to allow the user to view and, in some embodiments, edit the information. In one embodiment, the completed application includes a request for an adaptive coverage policy in which coverage updates are implemented based on the occurrence of qualifying update events, as discussed herein.

The coverage processing module220receives the completed application and transmits320the application to the comparative rater platform140and one or more coverage provider processors125backed by the rating engine240with a request for coverage options and rates. WhileFIG. 3includes one rating provider system (i.e., rating engine240) and one quote, in other embodiments, the coverage binding process is iterative when qualifying events are identified and includes multiple coverage provider processors125that provide initial and updated quotes (e.g., “rate call1” and “rate call2” quotes) based on user input and, in some instances, additional user data received from the third-party data sources135.

The coverage provider processor125sends a coverage option and quote to the data communications module215, which provides the information for display to the user through the front-end module205. Responsive to receiving user input indicating an intent to purchase325the coverage option using a direct bind process330, the coverage processing module220performs API-based purchase and payment processing with one or more third-party data sources140, such as a lending platform, an insurance rating platform, a carrier platform, a payment platform, and a document platform. The coverage processing module220further generates and provides335policy documents associated with the selected coverage option. In one embodiment, the policy documents are sent by the coverage communications module230to the user client device115for execution340and executed policy documents are stored in the user profile in the user data store245.

Alternatively, if the user input indicates that the user does not wish to use the direct bind process, the coverage communications module230initiates a direct communication345with the user, for example through a phone call, video chat, or other communication between the user client device115and a human agent associated with the connectivity hub server105to allow the user to bind coverage. In some embodiments, the user interacts350with a human agent associated with the connectivity hub server105to obtain or update endorsements or renewals for existing coverage and the human agent interacts355with a website associated with the user's coverage provider125to complete the endorsement or renewal process.

The method300is an iterative process and some or are of the steps described above are repeated if the modules of the connectivity hub server105determine that one or more qualifying update events has occurred. In some embodiments, the front-end module205prompts the user, during or after the initial coverage binding process, to install an application associated with the connectivity hub server105on the user client device115. In this way, the user may interact with the connectivity hub server105to update existing coverage based on the update event(s), as discussed above with respect toFIG. 2and below with respect toFIG. 4. Additionally, in some embodiments, the connectivity hub server105provides, through the application, information about additional products for the user, including quotes for home, auto, boat, RV, and other types of coverage in the form of advertisements or promotions through notifications, emails, text, and the like.

Example Data Flow

FIG. 4is a flow chart illustrating a method for implementing an adaptive coverage policy, according to an embodiment. The steps ofFIG. 4are illustrated from the perspective of the connectivity hub server105that performs the method400. However, in various implementations, some or all of the steps are performed by other entities or components. In addition, some embodiments perform the steps in parallel, perform the steps in different orders, or perform different steps. In addition, the steps are embodied as instructions executable by a processor of a machine, for example, as described byFIG. 6.

For a user for whom the connectivity hub server105has bound an adaptive coverage policy (e.g., using the method300described inFIG. 3), the connectivity hub server105generates recommended coverage updates based on the occurrence of a qualifying update event. At405, the data communications module215queries one or more third-party data sources135for information associated with the user. For example, in one embodiment, the third-party data sources135are public records databases. Additionally or alternatively, the third-party data sources135include entities with which the user has a preexisting relationship or is otherwise associated and to whom the user has provided consent to share user data with the connectivity hub server105. For example, third-party data sources135with which the user is associated include one or more of financial institutions, mortgage providers, data analytics and risk assessment entities, credit bureaus, and the like.

The method400is iterative and may be performed periodically as the user's coverage requirements change over time (e.g., as the user gets married, buys a home, has children, moves, retires, etc.). For example, in one embodiment, the data communications module215queries the third-party data sources135periodically and/or receives periodic updates about qualifying update events from the user through the user client device115.

Responsive to receiving user information from the one or more third-party data sources135and/or update information from a user through the user client device115, the data communications module215sends the information to the coverage processing module220, which detects410the occurrence of a qualifying update event associated with the user. In one embodiment, the coverage processing module220compares the received information to a list of qualifying update events to determine whether an event has occurred. For example, if the information indicates that the user has received approval for a loan to purchase a snowmobile, the coverage processing module220determines that the user has likely purchased or intends to purchase the snowmobile. In other embodiments, detecting the occurrence of the qualifying update event is based on user input (e.g., based on the user notifying the connectivity hub server that the user intends to purchase, or has already purchased, the snowmobile).

The coverage processing module220notifies the coverage management module225of the occurrence of the update event. In one embodiment, the coverage management module225determines415one or more recommended coverage updates based on the event by querying a stored mapping. For each qualifying event, the mapping includes one or more proposed updates to the user's existing policy that add, remove, or change coverage. For instance, with respect to the example discussed above, the mapping might indicate that the purchase of a snowmobile is associated with a proposal (e.g., via endorsement or a separate policy) to add snowmobile coverage (e.g., including one or more of liability, uninsured motorist, and collision/comprehensive coverage). In various embodiments, the recommended updates include a single proposed update to existing coverage or a pre-defined bundle with suggested coverage updates, as discussed above with respect toFIG. 2.

The front-end module205provides420the recommended coverage updates for display to the user through the user client device115. In one embodiment, the front-end module205queries the user to confirm the occurrence of the event and provides the recommended coverage updates responsive to the user input confirming the event occurrence. For instance, continuing the above example, the front-end module205queries the user “Did you recently purchase a snowmobile?” If the user confirms the purchase or an intent to purchase, the front-end module205sends a follow-up query asking the user whether they want to supplement their existing coverage by adding an endorsement or a policy to cover the snowmobile. Additionally or alternatively, the query includes a suggestion that the user discuss available coverage updates with a representative associated with the connectivity hub server105and/or a coverage provider.

At425, the front-end module205receives user input comprising an instruction to implement one or more of the recommended coverage updates. For example, the user might wish to supplement their existing coverage with liability, but might choose not to add uninsured motorist or collision/comprehensive coverage for the snowmobile (e.g., because it is of seasonal use only).

Responsive to receiving the user input, the coverage management module225updates430the existing coverage associated with the user in accordance with the user input. For example, in one embodiment the coverage management module225updates a user profile in the user data store245to reflect the change in coverage (e.g., to indicate that the user's current coverage now includes one or more coverage options from predefined snowmobile coverage bundles for different usage).

Example Machine Learning Subsystem

FIG. 5is a subsystem diagram illustrating components of the connectivity hub server105and interactions between the components, according to one embodiment. The embodiment displayed inFIG. 5includes a propensity to purchase model505, a loss prediction model510, a retention model515, a lifetime value model520, a connectivity hub525, an agency management system530, and a user coverage table535.

In some implementations, the connectivity hub server105uses the models to predict coverage data for an incoming user, such as the user's propensity to purchase one or more types of coverage, a loss prediction for the user, the user's expected retention duration, and a lifetime value of the user. For example, the connectivity hub525receives, through a user client device115or a dealer terminal120, data associated with a new user seeking coverage from a coverage provider. The connectivity hub525provides as input to the propensity to purchase model505underwriting and contributory data associated with the user, such as the user's current premium, violations, quoted carrier, quoted price, a manufacturer's suggested retail price of a vehicle, as well as biographic information about the user, such as the user's age, gender, marital status, state of residence, and the like. In one embodiment, the connectivity hub server105queries one or more third-party data sources135for additional data about the user and enriches the user data with the additional data received from the third-party data sources135prior to inputting the data into the propensity to purchase model505.

In one embodiment, the propensity to purchase model505is trained based on historical data associated with past coverage purchases. The connectivity hub server105receives from a dealer terminal120data indicating whether the dealer sold a coverage policy to a given user. If the dealer sold a coverage policy to the user, data indicating the sale and associated user information is included in a positive training set of data used to train the propensity to purchase model505. Conversely, if the dealer did not sell a coverage policy to a user, data indicating the lack of a sale and associated user information is included in a negative training set of data used to train the propensity to purchase model505. The propensity to purchase model505is thus trained on whether a sale to a given user was successful, and the trained model outputs, based on received user data, an indication of whether the user is likely to purchase coverage through the connectivity hub server105. For each sold policy, the propensity to purchase model505is subsequently trained to predict the likelihood of cross-selling additional policies or increasing coverage needs through time (i.e. adapting).

The enriched user data discussed above additionally serves as input to the loss prediction model510. In one embodiment, the connectivity hub server105uses machine learning to train the loss prediction model510based on training data received from the agency management system530. The training data includes ratios of coverage policy premiums to claims paid by the coverage provider. Once trained, the loss prediction model510outputs, for a given user, an associated loss prediction if the user purchases coverage through the connectivity hub server105.

The agency management system530further provides user data used to train the retention model515. For example, in one embodiment, the training data includes coverage policy cancellation and renewal data, as well as underwriting and agency data for a user, such as an associated coverage provider, policy premium, claim data, the number of drivers and vehicles in the user's household, whether the user has homeowner's insurance, renter's insurance, and/or monoline insurance, a garaging state of a user vehicle, and demographic data associated with the user, such as the user's age and marital status. The connectivity hub server105uses machine learning to train the retention model515on the duration of users' relationships with coverage providers and outputs, for a given user, a resulting prediction of the life expectancy of the relationship with the coverage provider from whom the user purchases coverage.

The connectivity hub server105inputs the loss prediction generated by the loss prediction model510and the life expectancy prediction generated by the retention model515to the lifetime value model520, which computes an estimated lifetime value of a given user. In one embodiment, the lifetime value model520estimates the user value based on a loss ratio and an expected user retention duration.

The connectivity hub server105further maintains, for each user, a user coverage table535that includes, for each of a plurality of coverage providers and types of coverage (e.g., auto insurance, renter's insurance, homeowner's insurance, and the like), the values calculated by the propensity to purchase model505, the loss prediction model510, the retention model515, and the lifetime value model520. In some embodiments, the values generated by the models are used to rank the carriers and to determine which coverage providers and associated coverage options to display to the user. The connectivity hub server105further stores the user coverage table535in a user profile in the user data store245.

Computing System Architecture

FIG. 6is a block diagram illustrating physical components of a computer600used as part or all of the connectivity hub server105, in accordance with an embodiment. Illustrated are at least one processor602coupled to a chipset604. Also coupled to the chipset604are a memory606, a storage device608, a graphics adapter612, and a network adapter616. A display618is coupled to the graphics adapter612. In one embodiment, the functionality of the chipset604is provided by a memory controller hub620and an I/O controller hub622. In another embodiment, the memory606is coupled directly to the processor602instead of the chipset604.

The storage device608is any non-transitory computer-readable storage medium, such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory606holds instructions and data used by the processor602. The graphics adapter612displays images and other information on the display618. The network adapter616couples the computer600to a local or wide area network.

As is known in the art, a computer600can have different and/or other components than those shown inFIG. 6. In addition, the computer600can lack certain illustrated components. In one embodiment, a computer600, such as a host or smartphone, lacks a graphics adapter612, and/or display618, as well as a keyboard610or external pointing device614. Moreover, the storage device608can be local and/or remote from the computer600(such as embodied within a storage area network (SAN)).

Additional Considerations

Some portions of above description describe the embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs comprising instructions for execution by a processor or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of functional operations as modules, without loss of generality.

Some embodiments are described using the expression “coupled” and “connected” along with their derivatives. It should be understood that these terms are not intended as synonyms for each other. For example, some embodiments are described using the term “connected” to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, some embodiments are described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.