The present disclosure relates to the field of data processing, in particular, to apparatuses, methods and storage media associated with provision and underwriting of insurance products.
The background description provided herein is for the purpose of generally presenting the context of the disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Individuals and companies participate in an ever-increasing range of activities, both commercial and recreational. Many of these activities involve degrees of risk, and in particular financial risk. In order to mitigate this risk, individuals and other entities may seek to purchase insurance which may provide one or more payments in the case of an unwanted event. However, today most insurance are provided by corporations, resulting in individuals and other entities finding it difficult to find insurance that is suited to their particular situation and needs.
Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example, and not by way of limitation, in the Figures of the accompanying drawings.
In the following detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.
Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiment. Various additional operations may be performed and/or described operations may be omitted in additional embodiments.
For the purposes of the present disclosure, the phrase “A and/or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C).
The description may use the phrases “in an embodiment,” or “in embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous.
As used herein, the term “logic” and “module” may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
Referring now to
In various embodiments, the IPPS 100 may be configured to facilitate underwriting of the payment by one or more insurance underwriters 160 upon occurrence of the triggering event. In various embodiments, the IPPS 100 may be configured to facilitate underwriting by individuals acting as insurance underwriters 160, such as illustrated individuals 170 and 180. In various embodiments, the IPPS 100 may be configured to facilitate underwriting by non-individual insurance underwriters, such as by organization 190, which, in various embodiments, may include for-profit and non-profit organizations.
In various embodiments, the IPPS 100 may be configured to facilitate the underwriting by encumbering financial resources of the insurance underwriters 160. For example, in various embodiments, the IPPS 100 may be configured to obtain an authorization to take an individual payment amount from an insurance underwriter 160 upon occurrence of the triggering event. In some embodiments, the IPPS 100 may be configured to obtain an authorization to take the individual payment amount out of a line of credit or credit card under control of an insurance underwriter (referred to herein generally as “a line of credit”) or out of a bank account. In such embodiments, the insurance underwriter 160 may be facilitated in underwriting an insurance product without a requirement that the insurance underwriter provide funds at the time of creation of the product. Instead, in such embodiments, the insurance underwriter 160 may agree to the authorization of an individual payment amount without needing to have the payment on-hand at the time the insurance underwriter 160 agrees to underwrite the insurance product. Additionally, the insurance underwriter 160 may be facilitated by the IPPS 100 in entering into agreements to underwrite an insurance product based on the insurance underwriter's available credit rather than other resources, such as liquid funds or other capital.
In various embodiments, the IPPS 100 may be configured to facilitate collection and sharing of a premium from the insurance customer 110 to the insurance underwriters 160. Thus, in various embodiments, the IPPS 100 may facilitate the division of an insurance premium between various insurance underwriters 160. In various embodiments, this division may be performed at least in part based on an amount of the payment the insurance underwriter 160 has agreed to pay upon occurrence of the triggering event. Thus, as shown, the individual insurance underwriter 180, which has agreed to pay less of the payment than the individual insurance underwriter 170, is also receiving less of the premium. Similarly, the organization insurance underwriter 190, which has agreed to pay a larger amount, receives a larger premium amount. In various embodiments, the IPPS 100 may be configured to facilitate collection of premiums and payment of divisions of the premiums on a recurring basis, such as, for example, monthly or yearly.
In various embodiments, the IPPS 100 may include one or more computing devices as described herein. In various embodiments the IPPS 100 may include one or more modules configured to be operated on the one or more computing devices to perform techniques described herein. While particular modules are illustrated and described, in various embodiments, techniques described herein may be performed by other modules, combined into modules, and/or omitted.
In various embodiments, the IPPS 100 may include a customer interface module 120, which may be configured to receive one or more requests for insurance products from the insurance customer 110 and to provide insurance products to the insurance customer. The customer interface module 120 may also facilitate payment of premiums by the insurance customer 110 as well as payment to the insurance customer 110 upon occurrence of a triggering event. In various embodiments, the IPPS 100 may include a underwriter interface 140 which may be configured to receive offers to underwrite insurance products from the insurance underwriters 160, as well as to facilitate payment of divisions of premium amounts to the insurance underwriters 160.
In various embodiments, the IPPS 100 may include an insurance product generation module 130, which may be configured to generate one or more insurance products and to provide these to the insurance customer 110. In various embodiments, the insurance product generation module 130 may be configured to generate insurance terms, premium amounts, and/or payment amounts based at least in part on requests from the insurance customer 110 for insurance products and/or offers to underwrite insurance products received from the insurance underwriters 160. In various embodiments the insurance product generation module 130 may also be configured to select one or more insurance underwriters 160 to underwrite a particular insurance product. Particular details of insurance product generation and insurance underwriter selection are described below.
In various embodiments, the IPPS 100 may also include a payment facilitation module 150. In various embodiments, the payment facilitation module 150 may be configured to divide received premium payments between the insurance underwriters 160 and facilitate payment of the divided premiums between the insurance underwriters 160. In various embodiments, the payment facilitation module 150 may also be configured to facilitate payment from the insurance underwriters 160 to the insurance customer 110 after occurrence of a triggering event. In various embodiments, the payment facilitation module 150 may be configured to perform automated authorized payment from resources under control of the insurance underwriters 160, such as by obtaining authorization to pay from credit cards, lines of credit, and/or bank accounts under control of one or more insurance underwriters 160. Examples of payment facilitation are described below.
Referring now to
In various embodiments, through performance of operations 220 and 230, the IPPS 100 may facilitate the performance of one or more types of auctions for insurance products. In various embodiments, the IPPS 100 may facilitate performance of a forward auction for an insurance product, where, for example, the insurance customer 110 may bid a premium amount for a given insurance product. In various embodiments, the IPPS 100 may facilitate performance of a reverse auction, where, for example, the insurance customer 110 may request a specific premium amount and receive offers of insurance products to choose from. Thus, in a reverse auction, as illustrated in process 200, the IPPS 100 may receive a request along with a premium amount from the insurance customer 110 at operation 220 before generating an insurance product at operation 230. By contrast, in an embodiment where a forward auction is facilitated, the IPPS 100 may generate insurance products before receiving bids from insurance customers 110. Examples of these auctions are described below.
Next, at operation 240, the insurance customer 110 may accept the generated insurance product. In embodiments where a forward auction is facilitated (not illustrated) at operation 240, the IPPS 110 may receive bids for a generated insurance product and select an offered bid. After acceptance, at operation 250, the IPPS 100 may facilitate sharing of premiums received from the insurance customer 110 with the insurance underwriters 160. Particular examples of operation 250 are described below with reference to
Referring now to
The process may begin at operation 310, where the IPPS 100 may receive underwriting limit information for the insurance underwriter 160. For example, the IPPS 100 may receive an indication of maximum amount the insurance underwriter 160 may be willing to underwrite. In various embodiments, at operation 310 the insurance underwriter 160 may provide an indication of available credit limits that it is willing to authorize payment out of In various embodiments, the underwriting limit information received at operation 310 may be indicated on a per-insurance product basis, and/or as a total limit on all insurance products.
Next, at operation 320, the IPPS 100 may receive a desired premium amount from the insurance underwriter 160. In various embodiments, the IPPS 100 may facilitate indication of different desired premiums for different levels of underwriting; thus, an insurance underwriter 160 may indicate that it is willing to provide additional underwriting for a higher received premium. Next, at operation 330, the IPPS 100 may receive desired risk information. In various embodiments, the IPPS 100 may thus receive an indication of a likelihood (which may be measured as a percentage or in some other metric) of a triggering event occurring; this likelihood may then be associated with the insurance underwriter 160's underwriting offer.
Next, at operation 340, the IPPS 100 may receive financial information for the insurance underwriter 160. In various embodiments, this financial information may be utilized by the IPPS 100 to facilitate payment to the insurance customer 110 upon occurrence of a triggering event. In various embodiments, the financial information may facilitate the IPPS 100 in encumbering the insurance underwriter 160 to better ensure payment. For example, the IPPS 100 may receive financial information that allows the IPPS 100 to place a spending authorization against a line of credit of the insurance underwriter 160. In various embodiments, this financial information may include one or more contract agreements between the insurance underwriter 160 and the IPPS 100 (or an entity associated with the IPPS 100) to provide legal authorization for future payments. In various embodiments, the financial information received at operation 340 may include authorization for the IPPS 100 to repeat obtaining authorization to encumber the insurance underwriter 160, such as if a previous authorization times out. The process may then end.
Referring now to
The process may begin at operation 410, where the IPPS 100 may receive an identification of one or more triggering events. As discussed above, in various embodiments, triggering events may include health based events, such as physician visits, prescription filling, medical procedures, etc. In some embodiments, triggering events may include business-based events, such as breaches of contract, late shipments, receipt of goods of substandard quality, etc. In other embodiments, other triggering events may be received. In some embodiments, triggering events may be described explicitly, while in others, the insurance customer 110 may generally describe a type of insurance (i.e. health or home insurance) without specifying particular triggering events. In such cases, the IPPS 100 may generate an insurance product with specific events based on the general request. In various embodiments, at operation 410, the IPPS 100 may also receive a desired payment amount for the triggering event. In various embodiments, the payment amount may be indicated as a total amount per event, and/or as amounts over time.
Next, at operation 420, the IPPS 100 may receive risk information relating to the requested insurance product. In various embodiments, the risk information my include data relating to an actual numerical risk of a triggering event occurring. In other embodiments, risk information may include information that facilitates the IPPS 100 in determining risk, such as the insurance customer 110's health or business history, weather patterns (such as for an agricultural insurance product), mitigating resources available to the insurance customer 110, etc. Next, at operation 430, the IPPS 100 may receive a desired premium amount from the insurance customer. The premium amount, in various embodiments, may include an amount that the insurance customer 110 may be willing to pay per time period for the type of coverage identified through the received triggering event (and possible payment amount) information previously received. The process may then end.
It may be noted that, in other embodiments, a forward auction may be used instead of a reverse auction. Thus, the insurance customer 110 may not provide a desired premium amount before an insurance product is generated. In such embodiments, the insurance product may even be generated (such as through operation of process 500 of
Referring now to
The process may begin at operation 510, where the IPPS 100 may identify underwriters who have indicated they are willing to underwrite a particular risk level for the requested insurance product. In various embodiments, the risk level may be determined from the risk information provided at operation 430. In some embodiments, the IPPS 100 may identify those underwriters that are willing to provide underwriting for lowest premium levels for the given risk, and/or at highest premium levels for the given risk.
Next, at operation 520, the IPPS may determine the portions of the payment to be provided by the insurance underwriters 160. In various embodiments, this determination may be based on the insurance underwriters' underwriting limits as well as identified desired risks. Next, at operation 530, the IPPS 100 may determine a total coverage amount for the insurance customer 110's desired premium based on the desired premiums identified by the selected underwriters. Next, at operation 540, the IPPS 100 may generate a description of the insurance product. In various embodiments, the description may include a description of one or more of payment amounts, triggering events, premium, terms and conditions of the insurance product, etc. Next, at operation 550, the IPPS 100 may provide the description to the insurance customer 110. The process may then end.
In other embodiments, the IPPS 100 may generate the insurance product based on underwriter-provided information without having received a desired premium amount from an insurance customer. The IPPS 100 may then receive bids for the insurance product, thereby facilitating a forward auction for the insurance product.
Referring now to
Next, at operation 620, the IPPS 100 may receive a premium payment. In some embodiments, rather than receiving the premium payment directly, the IPPS 100 may receive indication that the premium payment has been paid to another entity. Next, at operation 630, the IPPS 100 may divide the received premium. In various embodiments, this division may be performed according to the encumbered individual payment amounts and/or risk accepted by the insurance underwriters. For example, in some embodiments, the premium may be divided between when insurance underwriters 160 as a pro rata share according to their amount of payment offered. Next, at operation 640, the IPPS 100 may provide (or facilitate provision of) the divided premium to the insurance underwriters. The process may then end.
Referring now to
Referring now to
Each of these elements may perform its conventional functions known in the art. In particular, system memory 804 and mass storage devices 806 may be employed to store a working copy and a permanent copy of the programming instructions implementing the modules shown in
The permanent copy of the programming instructions may be placed into permanent storage devices 806 in the factory, or in the field, through, for example, a distribution medium (not shown), such as a compact disc (CD), or through communication interface 810 (from a distribution server (not shown)). That is, one or more distribution media having an implementation of the agent program may be employed to distribute the agent and program various computing devices.
The number, capability and/or capacity of these elements 810-812 may vary. Their constitutions are otherwise known, and accordingly will not be further described.
Although certain embodiments have been illustrated and described herein for purposes of description, a wide variety of alternate and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that embodiments described herein be limited only by the claims.
Where the disclosure recites “a” or “a first” element or the equivalent thereof, such disclosure includes one or more such elements, neither requiring nor excluding two or more such elements. Further, ordinal indicators (e.g., first, second or third) for identified elements are used to distinguish between the elements, and do not indicate or imply a required or limited number of such elements, nor do they indicate a particular position or order of such elements unless otherwise specifically stated.