DIGITAL PLATFORM FOR CONNECTING INSURANCE RELATED TRANSACTIONS

Described is a digital platform for facilitating insurance-related transactions using an integrated application programming interface (API). Insurance may include workers' compensation insurance. The integrated API may include a representational state transfer (REST) API that integrates many different transactions into the platform. Transactions may include transactions between insurance agencies and agents, comparative rating entities, companies having insurance needs, or direct consumers having insurance needs. Transactions may include providing of quotes (quoting), finalizing or binding of quotes, managing policies, or pulling of support data. Actions associated with transactions may include creating a quote, getting quote status, getting policy status, or getting class appetite.

BACKGROUND

Many states require employers to provide workers' compensation insurance for their employees. Yet, the requirements may be confusing because workers' compensation insurance laws and requirements vary by state. Also, penalties for noncompliance may include fines, criminal charges, or jail time so regulatory compliance is important for an employer. However, providing workers' compensation insurance for employees may be especially burdensome on a small company due to, for example, transaction costs in acquiring, managing, and using insurance policies. Transaction costs may be associated with, for example, researching insurance quotes, providing of quotes (quoting), finalizing/binding of quotes that then become policies, managing quotes and policies, and/or supporting quotes and policies with data, or a combination thereof.

Direct consumers, such as self-employed individuals or contractors, may experience similar burdens.

Unfortunately, the state of affairs for small companies and/or direct consumers to acquire, manage, and use workers' compensation insurance reveals different approaches that are deficient. Deficiencies arise from, for example, the many people-centric actions necessary for insurance-related transactions. First, a small company and/or a direct consumer may not be staffed and organized to understand the laws and requirements of the state in which the company or consumer operates and to then comply with those laws and requirements. Further, a small company and/or a direct consumer may not understand how the activities of the company and its employees or the activities of the consumer relate to risk and therefore impact the cost of a quote resulting in a policy. Risk factors that have the largest impact on the cost may include, for example, the type of risk associated with a company's or a consumer's business operations, a company's or a consumer's annual payroll, a company's or a consumer's prior claims history, or a number of other factors. Additionally, a small company and/or a direct consumer may not be staffed and organized to manage a quote and a resulting policy when an insurance claim is filed by the company's employee(s) or when the direct consumer files an insurance claim. Also, a small company and/or a direct consumer may not be staffed and organized to understand the data requirements needed to provide a quote and update a related policy. Finally, workers' compensation insurance also benefits a small company's employees and also benefits a direct consumer who depend on the insurance for lost wages, medical treatment, physical therapy, behavioral health, and/or death benefits, or a combination thereof.

For at least these reasons, such waste of resources, time, and money reduces a company's and/or a direct consumer's ability to invest in improving its products or services or to invest in its employees by providing workers' compensation insurance.

SUMMARY

The present disclosure can address at least these issues, for example, by providing an integrated digital agency service, application programming interface (DAS API) that facilitates and automates insurance-related transactions. The DAS API benefits insurance agencies and agents, third party comparative entities, companies having insurance needs, and/or direct consumers having needs by, for example, reducing the burden and transaction costs of researching insurance quotes, providing of quotes (quoting), finalizing/binding of quotes that then become policies, managing quotes and policies, and/or supporting quotes and policies with data, or a combination thereof. Also, the DAS API benefits employees and direct consumers who depend on the insurance for lost wages, medical treatment, physical therapy, behavioral health, and/or death benefits, or a combination thereof. Reducing waste of resources, time, and money improves a company's and/or a direct consumer's ability to invest in improving its products or services or to invest in its employees by providing workers' compensation insurance.

In an aspect, the present disclosure provides a platform for facilitating insurance-related transactions, the platform comprising: an integrated application programming interface (API) that is configured to enable different types/groups of users to connect to, and/or utilize a same backend service architecture for a variety of insurance-related transactions, wherein the different types/groups of users comprise (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, (3) one or more companies that have insurance needs, and (4) one or more direct consumers that have insurance needs.

In some embodiments, the integrated API is configured to connect directly with other partner APIs that are associated with the (1) one or more insurance agencies and agents and/or (2) the one or more third party comparative rating entities.

In some embodiments, the insurance-related transactions comprise a workflow that includes pre-bind and post-bind activities for quotes, wherein the pre-bind activities include pre-quotes and actual quoting.

In some embodiments, the insurance-related transactions or insurance needs relate to or include workers' compensation insurance.

In some embodiments, the integrated API is configured to enable the different types/groups of users to carry out the insurance-related transactions substantially in real-time directly through the users' own systems or APIs, thereby allowing manual and/or redundant data entry on the individual systems to be bypassed or eliminated.

In some embodiments, the integrated API is a representational state transfer (REST) interface that allows integration and exchange of data associated with the insurance-related transactions amongst the different types/groups of users.

In some embodiments, the platform is implemented as an Insurance-as-a-Service (IaaS) over a cloud network.

In some embodiments, the insurance-related transactions that are conducted using the platform include providing of quotes (quoting), finalizing/binding of quotes, policy management, and pulling of support data.

In some embodiments, the providing of quotes (quoting) is performed by the one or more insurance agencies and agents, in response to insurance-related inquiries or requests from (1) the one or more companies, (2) the one or more third party comparative rating entities, and/or (3) the one or more direct consumers. In some embodiments, the API is configured to push the quotes to (1) the one or more companies, (2) the one or more third party comparative rating entities, and/or (3) the one or more direct consumers. In some embodiments, the API is configured to enable the one or more third party comparative rating entities to push the quotes to the one or more companies and/or the one or more direct consumers.

In some embodiments, the platform is configured to enable the quotes to be finalized/bound in real time upon acceptance of the quotes by the one or more companies and/or the one or more direct consumers through the platform. In some embodiments, the platform is configured to facilitate transfer of insurance premium payments upon the quotes being finalized/bound.

In some embodiments, the policy management comprises access to policy documents, endorsements, renewals and/or other related aspects. In some embodiments, the support data comprises questions, responses to questions, rate classes, reservation and/or other types of data.

In some embodiments, the integrated API is configured to process and direct a plurality of request types, to generate a plurality of response types by, to or between the different types/groups of users. In some embodiments, the request types comprise one or more of the following quote-related actions: create quote, change quote, quote inquiry, quote not taken, bind quote, refer quote, list quote documents, add quote documents, delete quote documents, or get quote status. In some embodiments, the request types comprise one or more of the following policy-related actions: get policy documents, list policy documents, policy inquiry, list payment profile, or get policy status. In some embodiments, the request types comprise one or more of the following data management-related actions: validate agency code, validate agent code, get class appetite, list industry groups, get questions, or get state modifiers.

In another aspect, the present disclosure provides a computer-implemented system comprising: a digital processing device comprising: at least one processor, an operating system configured to perform executable instructions, a memory, and a computer program including instructions executable by the digital processing device to create an application comprising: an integrated application programming interface (API) that is configured to enable different types/groups of users to connect to, and/or utilize a same backend service architecture for a variety of insurance-related transactions, wherein the different types/groups of users comprise (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, (3) one or more companies that have insurance needs, and/or (4) one or more direct consumers that have insurance needs.

In another aspect, the present disclosure provides a non-transitory computer-readable storage media encoded with a computer program including instructions executable by a processor to create an application comprising: an integrated application programming interface (API) that is configured to enable different types/groups of users to connect to, and/or utilize a same backend service architecture for a variety of insurance-related transactions, wherein the different types/groups of users comprise (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, (3) one or more companies that have insurance needs, and/or (4) one or more direct consumers that have insurance needs.

In another aspect, the present disclosure provides a computer-implemented platform comprising: an integrated application programming interface (API) that is configured to enable different types/groups of users to connect to, and/or utilize a same backend service architecture for a variety of insurance-related transactions, wherein the different types/groups of users comprise (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, (3) one or more companies that have insurance needs, and/or (4) one or more direct consumers that have insurance needs.

INCORPORATION BY REFERENCE

DETAILED DESCRIPTION

While various embodiments of the present disclosure have been shown and described herein, it will be obvious that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions may occur without departing from the present disclosure. It can be understood that various alternatives to the embodiments of the present disclosure described herein may be employed.

Recognized herein is a need for a platform for facilitating insurance-related transactions, the platform comprising: an integrated application programming interface (API) that is configured to enable different types/groups of users to connect to, and/or utilize a same backend service architecture for a variety of insurance-related transactions. The different types/groups of users may comprise, for example, (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, (3) one or more companies that have insurance needs, and (4) one or more direct consumers that have insurance needs.

The integrated API may be viewed as a digital agency service API (DAS API) that reduces or eliminates human actions by automating some or all actions related to insurance-related transactions. The DAS API benefits insurance agencies and agents, third party comparative entities, companies having insurance needs, and/or direct consumers having insurance needs by, for example, reducing the burden and cost of researching insurance quotes, providing of quotes (quoting), finalizing/binding of quotes that then become policies, managing quotes and policies, and/or supporting quotes and policies with data, or a combination thereof. Also, the DAS API benefits employees and/or direct consumers who depend on the insurance for lost wages, medical treatment, physical therapy, behavioral health, and/or death benefits, or a combination thereof. Reducing waste of resources, time, and money improves a company's and/or a direct consumer's ability to invest in improving its products or services or to invest in its employees by providing workers' compensation insurance.

Further, the DAS API facilitates and automates many different types of requests and responses related to insurance-related transactions through the platform described herein. For example, requests and responses may include quote-related requests and responses such as create quote or get quote status. Requests and responses may include policy-related requests and responses such as list policy documents or get policy status. Requests and responses may include data management-related requests and responses such as validate agency code or get class appetite. Additionally, the DAS API facilitates and automates many different types of transactions received through a plurality of partner APIs by transforming partner API data and then performing the insurance-related transactions on the platform described herein. Partner APIs may include, for example, an Intuit® API or an Attune™ API.

Insurance agencies and agents may include, for example, an agency or agent that services one or more agencies or agents, an agency or agent that operates as a hosted service, and/or an agency or agent that operates as a system integrator, or a combination thereof. Third party comparative rating entities may include, for example, rating entities that provide quotes from multiple agencies, rating entities that allow a user to choose a best quote, and/or rating entities that act as an agent or broker for a user when obtaining a quote, or combination thereof. Companies that have insurance needs may include, for example, sole proprietorships, partnerships, limited liability companies, and/or corporations. Companies may include, for example, a small company that needs and/or wants workers' compensation insurance. Direct consumers, or direct-to-consumers, may include, for example, self-employed individuals or individual contractors who have insurance needs. Direct consumers may require insurance, e.g., workers' compensation insurance to, e.g., fulfill terms of a service contract or guard against medical bills and lost wages. Direct consumers may or may not be associated with the (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, and/or (3) one or more companies that have insurance needs. Direct consumers may or may not use an agency for insurance-related transactions. Direct consumers may use the integrated API described herein to facilitate insurance-related transactions.

DAS API Platforms

In an embodiment, the integrated API may be configured to connect directly with other partner APIs that are associated with the (1) one more insurance agencies and agents and/or (2) the one or more third party comparative rating entities. Alternatively, or in addition to, a company or a direct consumer may use a partner API to connect directly to the integrated API described herein. The integrated API (also DAS API) may, for example, provide a user an ability to communicate a request through the DAS API structured in the API's request body. The DAS API may, for example, communicate a response to a user through the DAS API structured in the API's response body. Partner APIs may include, for example, public APIs and private APIs. Public APIs may include, for example, social media APIs like Twitter®, third-party login APIs that allow a user to log in to the user's account using third-party party like Google®, or ecommerce APIs that allow a user to pay for a product or service with a third-party like PayPal®. Private APIs may include, for example, streaming service APIs that allow a user to stream content on any device from content providers like Netflix® or financial APIs that allow a user to access financial information from disparate sources such as banking and insurance information from banks like USAA®.

In another embodiment, the insurance-related transactions comprise a workflow that includes pre-bind and post-bind activities for quotes, wherein the pre-bind activities include pre-quotes and actual quoting. Additionally, as shown inFIG.1, the workflow may include other high-level activities, for example, providing of quotes (quoting), finalizing/binding of quotes, policy management, and/or pulling of support data, or a combination thereof. Pre-bind activities may include activities related to, for example, quote-related request types and data management-related request types. Post-bind activities may include activities related to, for example, policy-related request types and data management-related request types. Also, as shown inFIG.1, the workflow may include modules supporting the high-level activities of the backend service architecture, for example, a process mode module, a data translation module, an internal services module, or an internal databases module, or a combination thereof. The process mode module may, for example, determine whether an insurance-related transaction is requested through the platform described herein or whether a transaction is initially requested through a partner API. If the transaction is requested through the platform described herein, then the workflow activities may include, for example, translating data, converting to API JavaScript® Object Notation (JSON), using internal services, or saving data to the internal database of the backend architecture of the platform described herein. If the transaction is initially requested through a partner API, then the workflow may include, for example, translating the data for use by the platform described herein, using internal services, or saving to the internal database of the backend architecture of the platform described herein. Translating data may be required when a partner API uses a simple object access protocol (SOAP) API interface, a graph query language (GraphQL™) API interface using extensible markup language (XML), or an Association for Cooperative Operations Research and Development (ACORD™) API interface using XML, or combination thereof. The platform described herein translates the partner API data to API JSON for performing the insurance-related transactions in the backend service architecture.

In another embodiment, the insurance-related transactions or insurance needs relate to or include workers' compensation insurance. Additionally, insurance-related transactions or insurance needs may include, for example, life insurance, auto insurance, homeowner's insurance, renter's insurance, health insurance, disability insurance, long-term care insurance, identity theft insurance, and/or umbrella insurance, or a combination thereof.

In another embodiment, the integrated API is configured to enable the different types/groups of users to carry out the insurance-related transactions substantially in real-time directly through the users' own systems or APIs, thereby allowing manual and/or redundant data entry on the individual systems to be bypassed or eliminated. For example, data entry that may be bypassed or eliminated may include the name of the user, the password of the user, the location of the user (e.g., the address of primary place of business of an entity that the user represents), owner/officer, prior claims, the user's IP (Internet Protocol) address, the user's IP provider, and/or user metadata, or a combination thereof. Additionally, the user may update the data in real time so that data entry may be bypassed the next time the user carries out insurance-related transactions.

In another embodiment, the integrated API is a REST interface that allows integration and exchange of data associated with the insurance-related transactions amongst the different types/groups of users. The integrated API (or DAS API) may also use or otherwise translate data from, for example, a simple object access protocol (SOAP) API interface, a graph query language (GraphQL™) API interface using extensible markup language (XML), or an Association for Cooperative Operations Research and Development (ACORD™) API interface using XML, or a combination thereof. The representational state transfer (REST) API may include for example, a client-server architecture made up of clients, servers, and/or resources with requests managed through hypertext transfer protocol (HTTP), or combination thereof. The REST API may include, for example, a stateless client-server communication, cacheable data, a uniform interface between components, a layered system that organizes each type of server, and/or code-on-demand, or a combination thereof. The REST endpoints may be developed using, for example, JavaScript® Object Notation (JSON), comma separated value (CSV), and/or really simple syndication (RSS), or a combination thereof. The platform described herein may interface with SOAP APIs by extracting ACORD XML payload and converting to API JSON.

In another embodiment, the platform is implemented as an Insurance-as-a-Service (IaaS) over a cloud network. Cloud networks may include, for example, a public cloud, a private cloud, a hybrid cloud, and/or a multicloud, or a combination thereof. A public cloud may be, for example, Amazon® Web Services (AWS). Additionally, cloud networks may be structured with, for example, an operating system, a management platform, application APIs, virtualization software, and/or automation software, or a combination thereof. Cloud computing services may include, for example, infrastructure-as-a-service (IaaS), platforms-as-a-service (PaaS), and/or software-as-a-service (SaaS), or combination thereof.

In another embodiment, the insurance-related transactions that are conducted using the platform include providing of quotes (quoting), finalizing/binding of quotes, policy management, and pulling of support data. In an example, the providing of quotes (quoting) is performed by the one or more insurance agencies and agents, in response to insurance-related inquiries or requests from (1) the one or more companies, (2) the one or more third party comparative rating entities, and/or (3) the one or more direct consumers. As shown inFIG.1, the providing of quotes (quoting) may include activities related to, for example, inquiring about quotes, creating quotes, changing quotes, or referring quotes, or a combination thereof. In an example, the API is configured to push the quotes to (1) the one or more companies, (2) the one or more third party comparative rating entities, and/or (3) the one or more direct consumers. In an example, the API is configured to enable the one or more third party comparative rating entities to push the quotes to the one or more companies and/or the one or more direct consumers.

In an example, the platform is configured to enable the quotes to be finalized/bound in real time upon acceptance of the quotes by the one or more companies and/or the one or more direct consumers through the platform. As shown inFIG.1, the finalizing or binding of quotes may include activities related to, for example, changing quotes, binding quotes, or paying for quotes that become policies, or a combination thereof. In an example, the platform is configured to facilitate transfer of insurance premium payments upon the quotes being finalized/bound.

In an example, the policy management comprises access to policy documents, endorsements, renewals and/or other related aspects. In an embodiment, the support data comprises questions, responses to questions, rate classes, reservation and/or other types of data.

Request Types and Actions of DAS API Platforms

In another embodiment, the integrated API is configured to process and direct a plurality of request types, to generate a plurality of response types by, to or between the different types/groups of users. A user may communicate a request type through the integrated API (or DAS API) structured in the API's request header and/or request body. A user may receive a response type through the DAS API structured in the API's response header and/or response body. A request header may, for example, authenticate the user using a client identification and secret provided to the user when joining the platform described herein. Additionally, a request header may, for example, include language indicating the request type. For example, the request header may include the word, quote, when a create quote type is requested by a user. Depending on the request type, a request body may be required for the user to receive a response type or not be required to receive a response type. Depending on the response type, a response header may be provided to the user when receiving a response type or not be provided to the user when receiving a response type. A response body may provide the content of the response type to the user.

The request type and related response type are determined using the backend service architecture of the platform described herein. The request type and related response type may be categorized as, for example, quote-related request types, policy-related request types, or data management-related request types as shown inFIG.2A. As shown inFIG.2B, the platform contains a plurality of endpoints associated with a plurality of request types and a plurality of response types. The plurality of endpoints establish, for example, a location of the requested data within the backend service architecture of the platform described herein. Request types and the related response types may be grouped, for example, into requests related to quotes, requests related to policies, or requests related to data management. Each grouping comprises a plurality of related actions.

In another embodiment, the request types comprise one or more of the following quote-related actions: create quote, change quote, quote inquiry, quote not taken, bind quote, refer quote, list quote documents, add quote documents, delete quote documents, or get quote status.

In an example, a quote-related request type may include a create quote type as shown inFIG.2C. A user may request a new quote using the platform described herein. The create quote type is associated with an endpoint having a request header, a request body, and a response body. The request body of the create quote endpoint may include data about, for example, a policy, an applicant contact, a billing contact, a proposal contact, an agency, an agent, an association, named insureds, coverage limits, payment plans, prior losses, questions, disclaimers, and/or state modifiers, or combination thereof. The response body of the create quote endpoint may include the same or different data as the request body or additionally may include data about, for example, available payment plans, rating summary, and/or attachments, or a combination thereof. Also, the response body may include data about, for example, a quote's status, system messages, details, rating data, and/or relevant document attachments, or a combination thereof. After receiving the create quote type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining the processing mode (e.g., the platform described herein or a partner API). If the processing mode is the platform described herein, then the plurality of actions may include converting to a backend quote, generating a new quote, submitting to the backend for quoting, generating or not generating a quote letter, converting to API JSON, or responding to the user, or a combination thereof. If the processing mode is a partner API, then the plurality of actions may include converting to the partner quote, submitting to the partner, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a quote-related request type may include a change quote type as shown inFIG.2C. A user may request to make changes to an existing quote rather than generating a new quote using the platform described herein. The change quote type is associated with an endpoint having a request header, a request body, and a response body. The request body of the change quote endpoint may include data about, for example, a policy, an applicant contact, a billing contact, a proposal contact, an agency, an agent, an association, named insureds, coverage limits, payment plans, prior losses, questions, disclaimers, and/or state modifiers, or combination thereof. The response body of the create quote endpoint may include the same or different data as the request body or additionally may include data about, for example, available payment plans, rating summary, and/or attachments, or a combination thereof. Also, the response body may include data about, for example, an updated quote status, system messages, details, rating data, and/or relevant document attachments, or a combination thereof. After receiving the change quote type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions many include, for example, looking up the prior processing mode and determining the processing mode (e.g., the platform described herein or a partner API). If the processing mode is the platform described herein, then the plurality of actions may include converting to a backend quote and determining whether a quote already exists. If a quote already exists, then the plurality of actions may include submitting to backend for re-quoting, generating or not generating a quote letter, converting to API JSON, or responding to the user, or a combination thereof. If a quote does not already exist, the plurality of actions may include responding to the user. If the processing mode is a partner API, then the plurality of actions may include converting to the partner quote, submitting to the partner, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a quote-related request type may include a quote inquiry type as shown inFIG.2C. A user may request the status or details of a quote using the platform described herein. The quote inquiry type is associated with an endpoint having an optional request body but having a response body. The response body of the quote inquiry endpoint may include data about, for example, a policy, an applicant contact, a billing contact, a proposal contact, an agency, an agent, an association, named insureds, coverage limits, payment plans, prior losses, questions, disclaimers, and/or state modifiers, or combination thereof. Also, the response body may include data about, for example, the latest quote status, system messages, details, rating data, and/or relevant document attachments, or a combination thereof. After receiving the quote inquiry type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions many include, for example, loading the backend quote, generating or not generating a quote letter, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a quote-related request type may include a quote not taken type as shown inFIG.2C. A user may request not to continue with binding a quote and instead delete the quote using the platform described herein. The quote not taken type is associated with an endpoint having an optional request body but having a response body. The response body of the quote not taken endpoint may include data about, for example, a policy, an applicant contact, a billing contact, a proposal contact, an agency, an agent, an association, named insureds, coverage limits, payment plans, prior losses, questions, disclaimers, and/or state modifiers, or combination thereof. Also, the response body may include data about, for example, not taken quote status, system messages, details, rating data, and/or relevant document attachments, or a combination thereof. After receiving the quote not taken type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, loading the backend quote and determining whether to delete the quote. If the user elects to delete the quote, then the plurality of actions may include changing the status of the quote to referred for auditing purposes, saving the quote, converting to API JSON, or responding to the user, or a combination thereof. If the user elects not to delete the quote, then the plurality of actions may include converting to API JSON or responding to the user, or a combination thereof.

In an example, a quote-related request type may include a bind quote type as shown inFIG.2C. A user may request to bind a quote and turn the quote into an actual policy after successful quoting or approval by underwriting using the platform described herein. The bind quote type is associated with an endpoint having an optional request body but having a response body. The response body of the bind quote endpoint may include data about, for example, a policy, an applicant contact, a billing contact, a proposal contact, an agency, an agent, an association, named insureds, coverage limits, payment plans, prior losses, questions, disclaimers, or state modifiers, or a combination thereof. Also, the response body may include data about, for example, the bound quote status, system messages, details, rating data, or relevant document attachments, or a combination thereof. After receiving the bind quote type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, loading the backend quote and determining whether to bind the quote. If the user elects to bind the quote, then the plurality of actions may include submitting the quote to the backend for binding, converting to API JSON, or responding to the user, or combination thereof. If the user elects not bind the quote, then the plurality of actions may include converting to API JSON or responding to the user, or a combination thereof.

In an example, a quote-related request type may include a refer quote type as shown inFIG.2C. A user may request to refer a quote that is pending referral so that the quote may be actually referred to underwriting for approval using the platform described herein. The refer quote type is associated with an endpoint having an optional request body but having a response body. The response body of the refer quote endpoint may include data about, for example, a policy, an applicant contact, a billing contact, a proposal contact, an agency, an agent, an association, named insureds, coverage limits, payment plans, prior losses, questions, disclaimers, or state modifiers, or a combination thereof. Also, the response body may include data about, for example, the referred quote status, system messages, details, rating data or relevant document attachments, or a combination thereof. After receiving the refer quote type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, loading the backend quote and determining whether to refer the quote. If the user elects to refer the quote, then the plurality of actions may include changing the status of the quote to referred, saving the quote, converting to API JSON, or responding to the user, or a combination thereof. If the user elects not to refer the quote, then the plurality of actions may include responding to the user.

In an example, a quote-related request type may include a list quote documents type as shown inFIG.2C. A user may request to retrieve documents related to a quote using a plurality of requests for documents using the platform described herein. For example, the user may request a specific document associated with a quote, a list of documents associated with a quote, a compressed file of all documents associated with a quote, one or more documents from a quote by document type code, a specific document associated with a provided policy number and document identification, or a list of documents associated with a provided policy number. The list quote documents type is associated with an endpoint having an optional request body but having a response header (e.g., showing the originally uploaded document name) and a response body. The response body of the list quote documents endpoint may include data about, for example, the document type, document identification, insured named, policy number, agency identification, creation date, recipient list, octet stream for a document, document type code, file name, file size, upload date, octet stream for a compressed file, or byte stream for a document, or a combination thereof. After receiving the list quote documents type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, loading an allowed backend document list, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a quote-related request type may include an add quote documents type as shown inFIG.2C. A user may request to add documents to a quote using the platform described herein. Allowable document types may include, for example, .doc, .docx, .log, .msg, .odt, .rtf, .txt, .wpd, .csv, .dat, .pps, .ppt, .pptx, .bmp, .gif, .jpg, .png, .tif, .tiff, .pdf, .xlr, .xls, or .xlsx, or a combination thereof. The add quote document type is associated with an endpoint having a request body allowing multipart/form-data. The response body of the add quote document endpoint may include data about, for example, successful document upload or document identification, or a combination thereof. After receiving the add quote document type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether the document type is an allowed document type, e.g., a .pdf. If the document type is allowed, then the plurality of actions may include uploading the document to the backend or responding to the user, or a combination thereof. If the document type is not allowed, then the plurality of actions may include responding to the user.

In an example, a quote-related request type may include a delete quote documents type as shown inFIG.2C. A user may request to delete a document previously added to a quote using the platform described herein. The delete quote document type is associated with an endpoint having an optional request body. The response body of the delete quote document endpoint may include data about, for example, successful document deletion. After receiving the delete quote document type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether deleting the document is allowed. If deleting the document is allowed, then the plurality of actions may include deleting the document from the backend or responding to the user, or a combination thereof. If deleting the document is not allowed, then the plurality of actions may include responding to the user.

In an example, a quote-related request type may include a get quote status type as shown inFIG.2E. A user may request to retrieve the current status of a quote using the platform described herein. The get quote status type is associated with an endpoint having an optional request body. The response body of the get quote status endpoint may include data about, for example, the quote identification number, the status of the quote, or an indetermination of the status, or a combination thereof. After receiving the get quote status type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether a policy exists. If a policy exists, then the plurality of actions my include loading backend policy status, converting to API JSON, or responding to the user, or a combination thereof. If a policy does not exist, then the plurality of actions may include determining whether a quote exists. If a quote exists, then the plurality of actions may include loading backend quote status, converting to API JSON, or responding to the user, or a combination thereof. If a quote does not exist, then the plurality of actions may include converting to API JSON or responding to the user, or a combination thereof.

In another embodiment, the request types comprise one or more of the following policy-related actions: get policy documents, list policy documents, policy inquiry, list payment profile, or get policy status.

In an example, a policy-related request type may include a get policy documents type as shown inFIG.2D. A user may request to retrieve documents related to a policy using the platform described herein. The get policy documents type is associated with an endpoint having an optional request body but having a response header (e.g., document name as uploaded) and a response body. The response body of the get policy documents endpoint may include data about, for example, a document as byte stream. After receiving the get policy documents type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether the policy documents are allowed to be retrieved. If retrieval is allowed, then the plurality of actions may include loading the backend policy document or responding to the user, or a combination thereof. If retrieval is not allowed, then the plurality of actions may include responding to the user.

In an example, a policy-related request type may include a list policy documents type as shown inFIG.2D. A user may request to retrieve a list of documents associated with a policy using the platform described herein. The list policy documents type is associated with an endpoint having an optional request body but having a response body. The response body of the list policy documents endpoint may include data about, for example, document identification, document type, insured name, policy number, agency identification, creation date, or recipient list, or a combination thereof. After receiving the list policy documents type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, loading an allowed backend document list, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a policy-related request type may include a policy inquiry type as shown inFIG.2D. A user may inquire about the status or details of a policy using the platform described herein. The policy inquiry type is associated with an endpoint having an optional request body but having a response body. The response body of the policy inquiry endpoint may include data about, for example, policy number, creation date, effective date, expiration date, cancellation date, reinstatement date, issued date, years in business, total premium, status, prior policy number, valuation date, agent, agency, payment plan, available payment plans, or named insureds, or a combination thereof. After receiving the policy inquiry type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions many include, for example, loading backend policy data, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a policy-related request type may include a list payment profile type as shown inFIG.2E. A user may request to retrieve payment profiles related to a specific agency code or to retrieve payment profiles related to an authorized agency code using the platform described herein. The list payment profile type is associated with an endpoint having an optional request body but having a response body. The response body of the list payment profile endpoint may include data about, for example, customer number, account nickname, account type, last four characters of account number, or account token, or a combination thereof. After receiving the list payment profile type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions many include, for example, determining whether the request is for an agency. If the request is for an agency, then the plurality of actions may include, loading agency payment profiles, converting to API JSON, or responding to the user, or a combination thereof. If the request is not for any agency, then the plurality of actions may include loading partner payment profiles, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a policy-related request type may include ager policy status type as shown inFIG.2E. A user may request to retrieve the current status of a policy using the platform described herein. The get policy status type is associated with an endpoint having an optional request body but having a response body. The response body of the get policy status endpoint may include data about, for example, the policy identification number, the status of the policy, or an indetermination of the status, or a combination thereof. After receiving the get policy status type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether a policy exists. If a policy exists, then the plurality of actions my include loading backend policy status, converting to API JSON, or responding to the user, or a combination thereof. If a policy does not exist, then the plurality of actions may include determining whether a quote exists. If a quote exists, then the plurality of actions may include loading backend quote status, converting to API JSON, or responding to the user, or a combination thereof. If a quote does not exist, then the plurality of actions may include converting to API JSON or responding to the user, or a combination thereof.

Data Management-Related Actions

In another embodiment, the request types comprise one or more of the following data management-related actions: validate agency code, validate agent code, get class appetite, list industry groups, get questions, or get state modifiers.

In an example, a data management-related request type may include a validate agency code type as shown inFIG.2E. A user may request to verify that an agency is an active agency using the platform described herein. The validate agency code type is associated with an endpoint having an optional request body but having a response body. The response body of the validate agency code endpoint may include data about, for example, the active agency code or an error in determining active agency or combination thereof. After receiving the validate agency code type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether an agency code exists. If an agency code exists, then the plurality of actions my include loading agency summary, converting to API JSON, or responding to the user, or a combination thereof. If an agency code does not exist, then the plurality of actions may include responding to the user.

In an example, a data management-related request type may include a validate agent code type as shown inFIG.2E. A user may request to verify that an agent is an active agent using the platform described herein. The validate agent code type is associated with an endpoint having an optional request body but having a response body. The response body of the validate agent code endpoint may include data about, for example, the active agency code, agent email, customer number, or an error in determining active agent, or a combination thereof. After receiving the validate agent code type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether an agent code exists. If an agent code exists, then the plurality of actions my include loading agent summary, converting to API JSON, or responding to the user, or a combination thereof. If an agent code does not exist, then the plurality of actions may include responding to the user.

In an example, a data management-related request type may include a get class appetite type as shown inFIG.2E. A user may request to retrieve the platform's appetite by state using the platform described herein. The get class appetite type is associated with an endpoint having an optional request body but having a response body. The response body of the get class appetite endpoint may include data about, for example, class code, class description, class industry, class operations, North American Industry Classification System (NAICS) code, NAICS description, companion class codes, appetite, or targeting, or a combination thereof. After receiving the get class appetite type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether the user wants to retrieve specific appetites by a search or to retrieve all appetites. If specific appetites are desired, then the plurality of actions my include loading matching appetite data, processing the mode (e.g., the platform described herein or a partner API), converting to API JSON or converting to partner data, or responding to the user, or a combination thereof. If all appetites are desired, then the plurality of actions may include loading all appetite data, processing the mode (e.g., the platform described herein or a partner API), converting to API JSON or converting to partner data, or responding to the user, or a combination thereof.

In an example, a data management-related request type may include a list Industry groups type as shown inFIG.2E. A user may request to retrieve all distinct industries associated with the platform's appetites using the platform described herein. The list industry groups type is associated with an endpoint having an optional request body but having a response body. The response body of the list industry groups endpoint may include data about, for example, distinct appetite industries. Industries may include, for example, accounting, apparel manufacturing, architecture, auto parts, auto services, banking, bars, beauty, chemical and electrical manufacturing, clerical, daycare, dry cleaning, fast food, food manufacturing, food services, funerals, gas stations, hotels, mailing, meat stores, medical services, miscellaneous manufacturing, photo, professional services, real estate, retail, schools, wholesale, winery, or wood manufacturing, or a combination thereof. After receiving the list industry groups type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, loading backend industry data, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a data management-related request type may include a get questions type as shown inFIG.2E. A user may request to retrieve some or all questions with or without an effective date using the platform described herein. The get questions type is associated with an endpoint having an optional request body but having a response body. The response body of the get questions endpoint may include data about, for example, description of the question, industry code, industry, effective date of the question, state specific question, state exception, additional questions when positively answered, or additional questions when negatively answered, or a combination thereof. After receiving the get questions type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, loading all question data and processing the mode (e.g., the platform described herein or a partner API). If the processing mode is the platform described herein, then the plurality of actions many include converting to API JSON or responding to the user, or a combination thereof. If the processing mode is a partner API, then the plurality of actions may include converting to partner data, converting to API JSON, or responding to the user, or a combination thereof.

In an example, a data management-related request type may include a get state modifiers type as shown inFIG.2C. A user may request to retrieve all state modifiers that can be applied for a plurality of states with an optional effective date using the platform described herein. The get state modifiers type is associated with an endpoint having an optional request body but having a response body. The response body of the get state modifiers endpoint may include data about, for example, modifiers associated with a state, e.g., a label, a modifier type, textual help, minimum value of the modifier, or maximum value of the modifier, or a combination thereof. After receiving the get state modifiers type through the integrated API, the backend service architecture performs a plurality of actions to generate the response type. The plurality of actions may include, for example, determining whether the request is for a quote. If the request is for a quote, then the plurality of actions may include loading eligible backend state modifiers, converting to API JSON, or responding to the user, or a combination thereof. If the request is not for a quote, then the plurality of actions may include loading all backend state modifiers, converting to API JSON, or responding to the user, or a combination thereof.

In another embodiment, the present disclosure provides a computer-implemented system comprising: a digital processing device comprising: at least one processor, an operating system configured to perform executable instructions, a memory, and a computer program including instructions executable by the digital processing device to create an application comprising: an integrated application programming interface (API) that is configured to enable different types/groups of users to connect to, and/or utilize a same backend service architecture for a variety of insurance-related transactions, wherein the different types/groups of users comprise (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, (3) one or more companies that have insurance needs, and/or (4) one or more direct consumers that have insurance needs.

In another embodiment, the present disclosure provides a non-transitory computer-readable storage media encoded with a computer program including instructions executable by a processor to create an application comprising: an integrated application programming interface (API) that is configured to enable different types/groups of users to connect to, and/or utilize a same backend service architecture for a variety of insurance-related transactions, wherein the different types/groups of users comprise (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, (3) one or more companies that have insurance needs, and/or (4) one or more direct consumers that have insurance need.

In another embodiment, the present disclosure provides a computer-implemented platform comprising: an integrated application programming interface (API) that is configured to enable different types/groups of users to connect to, and/or utilize a same backend service architecture for a variety of insurance-related transactions, wherein the different types/groups of users comprise (1) one or more insurance agencies and agents associated with said agencies, (2) one or more third party comparative rating entities, (3) one or more companies that have insurance needs, and/or (4) one or more direct consumers that have insurance needs.

Terms and Definitions

Unless otherwise defined, all technical terms used herein have the same meaning as commonly understood.

As used herein, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Any reference to “or” herein is intended to encompass “and/or” unless otherwise stated.

As used herein, the term “about” in some cases refers to an amount that is approximately the stated amount.

As used herein, the term “about” refers to an amount that is near the stated amount by 10%, 5%, or 1%, including increments therein.

As used herein, the term “about” in reference to a percentage refers to an amount that is greater or less the stated percentage by 10%, 5%, or 1%, including increments therein.

Computing System

Referring toFIG.3, a block diagram is shown depicting an example platform that includes a computer system300(e.g., a processing or computing system) within which a set of instructions can execute for causing a device to perform or execute any one or more of the aspects of the platform described herein. The components inFIG.3are examples only and do not limit the scope of use or functionality of any hardware, software, embedded logic component, or a combination of two or more such components implementing particular embodiments.

Computer system300may include one or more processors301, a memory303, and a storage308that communicate with each other, and with other components, via a bus340. The bus340may also link a display332, one or more input devices333(which may, for example, include a keypad, a keyboard, a mouse, a stylus, etc.), one or more output devices334, one or more storage devices335, and various tangible storage media336. All of these elements may interface directly or via one or more interfaces or adaptors to the bus340. For instance, the various tangible storage media336can interface with the bus340via storage medium interface326. Computer system300may have any suitable physical form, including but not limited to one or more integrated circuits (ICs), printed circuit boards (PCBs), mobile handheld devices (such as mobile telephones or PDAs), laptop or notebook computers, distributed computer systems, computing grids, or servers.

Computer system300includes one or more processor(s)301(e.g., central processing units (CPUs) or general purpose graphics processing units (GPGPUs)) that carry out functions. Processor(s)301optionally contains a cache memory unit302for temporary local storage of instructions, data, or computer addresses. Processor(s)301are configured to assist in execution of computer readable instructions. Computer system300may provide functionality for the components depicted inFIG.3as a result of the processor(s)301executing non-transitory, processor-executable instructions embodied in one or more tangible computer-readable storage media, such as memory303, storage308, storage devices335, and/or storage medium336. The computer-readable media may store software that implements particular embodiments, and processor(s)301may execute the software. Memory303may read the software from one or more other computer-readable media (such as mass storage device(s)335,336) or from one or more other sources through a suitable interface, such as network interface320. The software may cause processor(s)301to carry out one or more processes or one or more operations of one or more processes described or illustrated herein. Carrying out such processes or operations may include defining data structures stored in memory303and modifying the data structures as directed by the software.

The memory303may include various components (e.g., machine readable media) including, but not limited to, a random access memory component (e.g., RAM304) (e.g., static RAM (SRAM), dynamic RAM (DRAM), ferroelectric random access memory (FRAM), phase-change random access memory (PRAM), etc.), a read-only memory component (e.g., ROM305), and any combinations thereof. ROM305may act to communicate data and instructions unidirectionally to processor(s)301, and RAM304may act to communicate data and instructions bidirectionally with processor(s)301. ROM305and RAM304may include any suitable tangible computer-readable media described below. In one example, a basic input/output system306(BIOS), including basic routines that help to transfer information between elements within computer system300, such as during start-up, may be stored in the memory303.

Fixed storage308is connected bidirectionally to processor(s)301, optionally through storage control unit307. Fixed storage308provides additional data storage capacity and may also include any suitable tangible computer-readable media described herein. Storage308may be used to store operating system309, executable(s)310, data311, applications312(application programs), and the like. Storage308can also include an optical disk drive, a solid-state memory device (e.g., flash-based systems), or a combination of any of the above. Information in storage308may, in appropriate cases, be incorporated as virtual memory in memory303.

In one example, storage device(s)335may be removably interfaced with computer system300(e.g., via an external port connector (not shown)) via a storage device interface325. Particularly, storage device(s)335and an associated machine-readable medium may provide non-volatile and/or volatile storage of machine-readable instructions, data structures, program modules, and/or other data for the computer system300. In one example, software may reside, completely or partially, within a machine-readable medium on storage device(s)335. In another example, software may reside, completely or partially, within processor(s)301.

Computer system300may also include an input device333. In one example, a user of computer system300may enter commands and/or other information into computer system300via input device(s)333. Examples of an input device(s)333include, but are not limited to, an alpha-numeric input device (e.g., a keyboard), a pointing device (e.g., a mouse or touchpad), a touchpad, a touch screen, a multi-touch screen, a joystick, a stylus, a gamepad, an audio input device (e.g., a microphone, a voice response system, etc.), an optical scanner, a video or still image capture device (e.g., a camera), and any combinations thereof. In some embodiments, the input device is a Kinect, Leap Motion, or the like. Input device(s)333may be interfaced to bus340via any of a variety of input interfaces323(e.g., input interface323) including, but not limited to, serial, parallel, game port, USB, FIREWIRE, THUNDERBOLT, or any combination of the above.

In particular embodiments, when computer system300is connected to network330, computer system300may communicate with other devices, specifically mobile devices and enterprise systems, distributed computing systems, cloud storage systems, cloud computing systems, and the like, connected to network330. Communications to and from computer system300may be sent through network interface320. For example, network interface320may receive incoming communications (such as requests or responses from other devices) in the form of one or more packets (such as Internet Protocol (IP) packets) from network330, and computer system300may store the incoming communications in memory303for processing. Computer system300may similarly store outgoing communications (such as requests or responses to other devices) in the form of one or more packets in memory303and communicated to network330from network interface320. Processor(s)301may access these communication packets stored in memory303for processing.

Examples of the network interface320include, but are not limited to, a network interface card, a modem, and any combination thereof. Examples of a network330or network segment330include, but are not limited to, a distributed computing system, a cloud computing system, a wide area network (WAN) (e.g., the Internet, an enterprise network), a local area network (LAN) (e.g., a network associated with an office, a building, a campus or other relatively small geographic space), a telephone network, a direct connection between two computing devices, a peer-to-peer network, and any combinations thereof. A network, such as network330, may employ a wired and/or a wireless mode of communication. In general, any network topology may be used.

Information and data can be displayed through a display332. Examples of a display332include, but are not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a thin film transistor liquid crystal display (TFT-LCD), an organic liquid crystal display (OLED) such as a passive-matrix OLED (PMOLED) or active-matrix OLED (AMOLED) display, a plasma display, and any combinations thereof. The display332can interface to the processor(s)301, memory303, and fixed storage308, as well as other devices, such as input device(s)333, via the bus340. The display332is linked to the bus340via a video interface322, and transport of data between the display332and the bus340can be controlled via the graphics control321. In some embodiments, the display is a video projector. In some embodiments, the display is a head-mounted display (HMD) such as a VR headset. In further embodiments, suitable VR headsets include, by way of non-limiting examples, HTC Vive, Oculus Rift, Samsung Gear VR, Microsoft HoloLens, Razer OSVR, FOVE VR, Zeiss VR One, Avegant Glyph, Freefly VR headset, and the like. In still further embodiments, the display is a combination of devices such as those disclosed herein.

In addition to a display332, computer system300may include one or more other peripheral output devices334including, but not limited to, an audio speaker, a printer, a storage device, and any combinations thereof. Such peripheral output devices may be connected to the bus340via an output interface324. Examples of an output interface324include, but are not limited to, a serial port, a parallel connection, a USB port, a FIREWIRE port, a THUNDERBOLT port, and any combinations thereof.

In addition or as an alternative, computer system300may provide functionality as a result of logic hardwired or otherwise embodied in a circuit, which may operate in place of or together with software to execute one or more processes or one or more operations of one or more processes described or illustrated herein. Reference to software in this disclosure may encompass logic, and reference to logic may encompass software. Moreover, reference to a computer-readable medium may encompass a circuit (such as an IC) storing software for execution, a circuit embodying logic for execution, or both, where appropriate. The present disclosure encompasses any suitable combination of hardware, software, or both.

Various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality.

In accordance with the description herein, suitable computing devices include, by way of non-limiting examples, server computers, desktop computers, laptop computers, notebook computers, sub-notebook computers, netbook computers, netpad computers, set-top computers, media streaming devices, handheld computers, Internet appliances, mobile smartphones, tablet computers, personal digital assistants, video game consoles, and vehicles. Select televisions, video players, and digital music players with optional computer network connectivity are suitable for use in the system described herein. Suitable tablet computers, in various embodiments, include those with booklet, slate, and convertible configurations, known to those of skill in the art.

Non-Transitory Computer Readable Storage Medium

Computer Program

Web Application

Referring toFIG.4, in a particular embodiment, an application provision system comprises one or more databases400accessed by a relational database management system (RDBMS)410. Suitable RDBMSs include Firebird, MySQL, PostgreSQL, SQLite, Oracle Database, Microsoft SQL Server, IBM DB2, IBM Informix, SAP Sybase, SAP Sybase, Teradata, and the like. Alternatively or additionally to an RDBMS, the application provision system comprises a NoSQL database, e.g., MongoDB®. In this embodiment, the application provision system further comprises one or more application severs420(such as Java servers, .NET servers, PHP servers, and the like) and one or more web servers430(such as Apache, IIS, GWS and the like). The web server(s) optionally expose one or more web services via app application programming interfaces (APIs)440. Via a network, such as the Internet, the system provides browser-based and/or mobile native user interfaces.

Referring toFIG.5, in a particular embodiment, an application provision system alternatively has a distributed, cloud-based architecture500and comprises elastically load balanced, auto-scaling web server resources510and application server resources520as well synchronously replicated databases530.

Mobile Application

In some embodiments, a computer program includes a mobile application provided to a mobile computing device. In some embodiments, the mobile application is provided to a mobile computing device at the time it is manufactured. In other embodiments, the mobile application is provided to a mobile computing device via the computer network described herein.

In view of the disclosure provided herein, a mobile application is created by techniques using hardware, languages, and development environments. Mobile applications can be written in several languages. Suitable programming languages include, by way of non-limiting examples, C, C++, C#, Objective-C, Java™, Javascript, Pascal, Object Pascal, Python™, Ruby, VB.NET, WML, and XHTML/HTML with or without CSS, or combinations thereof.

Several commercial forums are available for distribution of mobile applications including, by way of non-limiting examples, Apple® App Store, Google® Play, Chrome WebStore, BlackBerry® App World, App Store for Palm devices, App Catalog for webOS, Windows® Marketplace for Mobile, Ovi Store for Nokia devices, Samsung® Apps, and Nintendo® DSi Shop.

Standalone Application

Web Browser Plug-In

Software Modules

Databases

In some embodiments, the platforms, systems, media, and methods disclosed herein include one or more databases, or use of the same. In view of the disclosure provided herein, many databases are suitable for storage and retrieval of data. In various embodiments, suitable databases include, by way of non-limiting examples, relational databases, non-relational databases, object oriented databases, object databases, entity-relationship model databases, associative databases, and XML databases. Further non-limiting examples include SQL, PostgreSQL, MySQL, Oracle, DB2, and Sybase. In some embodiments, a database is internet-based. In further embodiments, a database is web-based. In still further embodiments, a database is cloud computing-based. In a particular embodiment, a database is a distributed database. In other embodiments, a database is based on one or more local computer storage devices.

Machine Learning, Risk (Appetite) Endpoint, and Internal Services

The insurance-related transactions that are performed by the platform described herein may include, for example, providing of quotes (quoting), finalizing/binding of quotes, policy management, and pulling of support data. The platform performs the insurance-related transactions using a same backend service architecture ofFIG.1. For example, providing of quotes (quoting) may utilize a risk assessment model to determine the risk, or appetite, associated with an insurance-related transaction for a user. The risk assessment model may determine the risk, or appetite, for the insurance related-related transaction, thereby, allowing the platform to use risk to determine, in part, the quote for the user. The risk assessment model may be associated with, for example, the internal services module ofFIG.1.

The risk assessment model of the internal services module ofFIG.1may utilize, for example, a modeling engine, a model deployment manager, a performance monitoring engine, and/or a model development engine to provide the platform a risk, or an appetite, for an insurance-related transaction. Multiple models may be developed, trained, and initially tested in the model development engine, then tested with live production data as shadow models in the performance monitoring engine, with the results compared over time against other the other shadow models as well as the production models. This comparison of results can result in production models being replaced by shadow models that have statistically significant better results over time. Based on this process and the learnings of which models perform best over time, better models can be developed, trained, and initially tested in the model development engine and the process of testing and replacing models repeated. This is a dynamic feedback loop that may result in a continuously improving process of assessing risks for insurance-related transactions.

The risk assessment model of the internal services module ofFIG.1may utilize several different types of models for performing various parts of providing of quotes (quoting), finalizing/binding of quotes, policy management, and pulling of support data. In some embodiments, the platform described herein utilizes machine learning algorithms to classify risk, or appetite, associated with an insurance-related transaction for a user. Many statistical classification techniques are suitable as approaches to perform the risk classification. Such methods include but are not limited to supervised learning approaches.

Commonly used supervised classifiers may include, without limitation, the neural network (e.g., artificial neural network, multi-layer perceptron), support vector machines, k-nearest neighbors, Gaussian mixture model, Gaussian, naive Bayes, decision tree and radial basis function (RBF) classifiers. Linear classification methods include Fisher's linear discriminant, logistic regression, naive Bayes classifier, perceptron, and support vector machines (SVMs). Other classifiers for use with methods according to the disclosure include quadratic classifiers, k-nearest neighbor, boosting, decision trees, random forests, neural networks, pattern recognition, Bayesian networks and Hidden Markov models. Other classifiers, including improvements or combinations of any of these, commonly used for supervised learning, can also be suitable for use with the methods described herein.

Classification of risk, or appetite, using supervised methods can generally be performed by the following methodology: 1) Gather a training set. The training samples are used to train the classifier. 2) Determine the input feature representation of the learned function. The accuracy of the learned function depends on how the input object is represented. Typically, the input object is transformed into a feature vector, which contains a number of features that are descriptive of the object. 3) Determine the structure of the learned function and corresponding learning algorithm. A learning algorithm is chosen, e.g., artificial neural networks, decision trees, Bayes classifiers, or support vector machines. The learning algorithm is used to build the classifier. 4). Build the classifier. The learning algorithm is run on the gathered training set. Parameters of the learning algorithm may be adjusted by optimizing performance on a validation subset of the training set or via cross-validation. After parameter adjustment and learning, the performance of the algorithm may be measured on a test set of naive samples that is separate from the training set. The built model can involve feature coefficients or importance measures assigned to individual features. Once the classifier is trained as above, it can be used to classify a sample, e.g., a risk associated with an insurance-related transaction for a user.

EXAMPLES

The following illustrative examples are representative of embodiments of the platform, software applications, systems, or methods described herein and are not meant to be limiting in any way.

Example 1—Quick Quote—Single Location, One Class Code

A user associated with the platform described herein or a user associated with a partner API may request a new quote. The user submits a request for a quote by including a request type header and a request type body. The request type header includes a POST statement that includes the word, quote, indicating that the user requests a create quote type. Additionally, the request type header includes the user's secure token which authenticates the user. The request body includes fields and data for those fields. The fields may include quote id, effective date, expiration date, years in business, agency, named insureds, locations, or rate classes, or a combination thereof. The agency field may additionally include agency code. The named insureds field may additionally include company name or federal employer identification number (FEIN). The location field may additionally include whether the location is a primary location, number of employees, or company address. The rate classes field may additionally include class code, class code description, or payroll amount.

After receiving the request type through the platform described herein, the DAS API converts the data of the request type to a backend quote that is processable by the backend service architecture of the platform. The backend service architecture then uses internal services, as shown inFIG.1, to create a quote. After creation, the platform then converts the quote to API JSON so that the platform may provide a response to the user.

The response type may not include a response header but may include a response body. The response body includes fields and data for those fields. The fields may include quote identification, success of quoting, status of quote, policy number, policy uniform resource locator (URL), effective date, expiration date, state for the policy, years in business, total premium, commission percent, underwriting company, underwriting company NAIC code, underwriting company code, agency, named insureds, coverage limits, payment plan, available payment plans, prompted questions, state modifiers, rating summary, or attachments, or a combination thereof.

While preferred embodiments of the present disclosure have been shown and described herein, it will be obvious that such embodiments are provided by way of example only. It is not intended that the present disclosure be limited by the specific examples provided within the specification. While the present disclosure has been described with reference to the aforementioned specification, the descriptions and illustrations of the embodiments herein are not meant to be construed in a limiting sense. Numerous variations, changes, and substitutions will now occur without departing from the present disclosure. Furthermore, it shall be understood that all aspects of the present disclosure are not limited to the specific depictions, configurations or relative proportions set forth herein which depend upon a variety of conditions and variables. It can be understood that various alternatives to the embodiments of the present disclosure described herein may be employed in practicing the present disclosure. It is therefore contemplated that the present disclosure shall also cover any such alternatives, modifications, variations or equivalents. It is intended that the following claims define the scope of the present disclosure and that methods and structures within the scope of these claims and their equivalents be covered thereby.