SYSTEM AND METHOD FOR PROVIDING UPDATED OFFERS
20200311787 ยท 2020-10-01
Inventors
Cpc classification
G06Q30/0605
PHYSICS
G06Q20/127
PHYSICS
G06F9/542
PHYSICS
International classification
Abstract
A system for updating offers includes a computer for receiving consumer data. A data entry application removes pertinent data from the consumer data as a function of a type of products being offered. An application program interface maps the pertinent data to products as determined by the appropriateness of the pertinent data for a respective product. A clock stores a time period for which the consumer requires a renewal of the product and determines when such time period elapses and outputs a signal to the application program interface before the time period has elapsed. The application program interface forwards the pertinent data to two or more vendors in response to the clock signal; the two or more vendors chosen as a function of the mapping of the stored pertinent data to products offered by the vendor, and receives product offers corresponding to the pertinent data. The application program interface forwards the received product offers to the computer for display to the consumer as product offerings.
Claims
1. A system for updating offers comprises: a computer for receiving consumer data input by a consumer; a data entry application in communication with the computer for receiving the consumer data and removing pertinent data from the consumer data as a function of a type of products and services being offered; a database for storing the pertinent data, an application program interface in communication with the database, the application program interface mapping the pertinent data to products or services as determined by the appropriateness of the pertinent data for a respective product or service and storing the mapping of pertinent data in the database; a clock in communication with the application program interface, the clock storing a time period for which the consumer requires at least one of a renewal or update of a respective product or service, and determines when such time period elapses, the clock outputting a signal to the application program interface before the time period has elapsed; the application program interface forwarding the pertinent data to two or more vendors in response to the clock signal, the two or more vendors being chosen as a function of the mapping of the stored pertinent data to products or services offered by the vendor, the application program interface receiving product or service offers corresponding to the pertinent data from one or more of the two or more vendors; and the application program interface forwarding the received product or service offers to the computer for display to the consumer as product offerings.
2. The system of claim 1, wherein the application program interface determines the appropriateness of the pertinent data for a respective product or service as a function of relevancy of the pertinent data to the product or service.
3. The system of claim 1, wherein the relevancy is a function of at least one of a geographic location of the consumer, a status of current insurance coverage for the consumer, and a driving record of the consumer.
4. The system of claim 1, wherein the application program interface counts a number of product or service offers received, and not causing the offers to be forwarded until a predetermined number of offers has been received.
5. The system of claim 1, further comprising a data analyzer in communication with the database, the computer transmitting an acceptance of an offer to a selected vendor, the application program interface receiving the acceptance and storing acceptance data in the database, the data analyzer receiving the acceptance data and each offer, and determining acceptance trends as a function of pricing and at least one of past accepted offers, geographic location of the consumer, consumer income, and asset value of the consumer.
6. The system of claim 5, wherein the application program interface receives the acceptance trends and determines which of the two or more vendors are enabled to make offers as a function of said acceptance trends.
7. The system of claim 1, wherein the application program interface receives a clock input from said clock, determines when the pertinent data is forwarded to each respective one of the two or more vendors and begins a time out clock for each vendor in response to such determination.
8. The system of claim 7, wherein the application program interface determines that the time out clock has elapsed for a respective vendor, and if no offer has been received from the respective vendor, preventing transmission of an offer received from said vendor to the computer.
9. The system of claim 1, wherein the application program interface counts the number offers received from a single vendor, and prevents transmission of an additional offer from said single vendor to the computer when the number of offers from the single vendor exceeds a predetermined number.
10. The system of claim 1, wherein the application program interface counts the number offers received from the two or more vendors and prevents additional offers from being transmitted to the computer when the total number of offers exceeds a predetermined number.
11. The system of claim 1, wherein the computer is a mobile device.
12. The system of claim 1, further comprising a webpage portal in communication with the computer and the data entry application and the webpage enabling the computer to receive consumer data.
13. The system of claim 1, wherein the pertinent data does not include data capable of identifying the consumer.
14. A method for updating offers comprises: receiving consumer data at a computer; removing pertinent data from the consumer data with a data entry application, as a function of a type of product or service being offered; mapping the pertinent data with an application program interface to products or services as determined by the appropriateness of the pertinent data for a respective product or service and storing the mapping of the pertinent data; forwarding the pertinent data with the application program interface to two or more vendors in response to a determination that a time period is about to expire, the two or more vendors being chosen as a function of the mapping of the stored pertinent data to products or services offered by the vendor, receiving product at the application program interface offers corresponding to the pertinent data; and forwarding the received product offers to the computer for display to the consumer as product offerings.
15. The method of claim 14, further comprising the step of: counting a number of product or service offers received, and not causing the offers to be forwarded to the computer until a predetermined number of offers has been received.
16. The method of claim 14, further comprising the steps of: transmitting an acceptance of an offer to a selected vendor from the computer; receiving acceptance data about the acceptance of each offer at a data analyzer, and determining acceptance trends as a function of pricing and at least one of past accepted offers, geographic location, consumer income, and asset value.
17. The method of claim 14, further comprising the steps of: receiving a clock input from a clock; determining when the pertinent data is forwarded to each respective one of the two or more vendors and beginning a time out clock with the application program interface for each vendor in response to such determination; determining that the time out clock has elapsed for a respective vendor, and if no offer has been received from the respective vendor, the application program interface prevents transmission of the offer from the respective vendor to the computer.
18. The method of claim 14, further comprising the steps of: counting the number offers received by a single vendor with the application program interface, and preventing transmission of an additional offer from single vendor to the computer when the number of offers from the single vendor exceeds a predetermined number.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The present disclosure is better understood by reading the written description with reference to the accompanying drawings and figures in which like reference numerals denote similar structure and refer to the elements throughout, in which:
[0011]
[0012]
[0013]
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0014] The subject matter of aspects of embodiments of the present invention is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of any patent issuing from this description. Rather, the inventor has contemplated that the claimed subject matter might also be embodied in other ways, to include different elements or combinations of elements similar to the ones described in this document, in conjunction with other present or future technologies.
[0015] Reference is made to
[0016] API 108 communicates with a first database 110. While API 108 stores all necessary data, including personal data, in database 110, API 108 maps pertinent information to products and/or services of interest as a function of the relevancy of the pertinent information to a determination of the appropriateness of the product and/or service. Relevancy may in one non limiting embodiment of an insurance product be a function of the existence of current coverage or not, geographic location (screening out certain providers, representing a high risk area for flood or hurricane). More specifically relevancy may incorporate driving record for vehicle insurance, renter or owner for home insurance, etc.
[0017] API 108 stores the pertinent data as mapped in a first database 110. It should be noted that a portion of the functionality of data entry application 106, in particular determining which data is pertinent as a function of the product, may also be performed by API 108.
[0018] API 108 also communicates with a plurality of product providers (vendors) B.sub.1-B.sub.N (providers 114-120). Vendors 114-120 provide offers for products and services as a function of received pertinent data. For example, if offering property insurance the pertinent data may be the age and geographical location of the property being insured as well as the value of the property being insured. Vendors 114-120 correspond to the online presence of insurance providers in this nonlimiting example.
[0019] A clock 112, in communication with API 108, counts elapsed time. Clock 112 also stores one or more predetermined time intervals corresponding to a time period at the end of which a product must be renewed or replaced. Clock 112 continuously compares the counted elapsed time to a stored predetermined time interval and determines when a predetermined time interval has elapsed and outputs a clock signal in response thereto. In a nonlimiting exemplary insurance example, ahead of the end of each one year anniversary, when an insurance policy is usually due to be renewed, clock 112 outputs a clock signal to the API 108 when the policy term is due to elapse indicating that a replacement policy may be required.
[0020] It should be noted that in a simplified embodiment, clock 112 merely provides an elapsed time count, and the functionality of determining the end of the predetermined time interval can be determined by API 108 as a function of time intervals stored in database 110. By comparing the count as output by clock 112 and the interval as stored in database 110, API 108 can determine when a predetermined time interval has elapsed. This use of clock 112 makes it applicable to other functionality as described below.
[0021] Database 110 is in communication with API 108 and computer 102. As API 108 receives product/service proposals, they are stored in database 110. Once API 108 determines that a sufficient number of proposals have been stored in database 110 for a meaningful comparison, API 108 causes database 110 to push product/service proposals stored in database 110 to computer 102 for consideration by the consumer at a time when renewal decisions must be made.
[0022] In another embodiment of the invention, acceptance of offers are input at computer 102 and transmitted to product vendors 114-120 by API 108. The accepted offer, and offer terms, are stored by API 108 at database 110. A data analyzer 122, such as Google Big Query, in a preferred nonlimiting embodiment, is in communication with database 110 and a second database 124. Second database 124 is in communication with API 108. Data analyzer 122 receives the offers provided to computer 102 as well as the acceptance of the selected offer. Data analyzer 122 determines acceptance trends as a function of pricing and at least any one (or all) of a number of additional factors such as past offers accepted by a particular consumer, geographic location of the item insured, geographic location of the consumer, income, asset value or the like. Data analyzer 122 determines trend lines from this data and stores the trend lines in second database 124. API 108 may utilize these trend lines, in one non limiting embodiment, to ensure that the offers are equally distributed among different consumer options; different product or service providers; i.e. not all from different brokers for the same provider such as the same insurance company; which in effect is the same product offered several times simultaneously.
[0023] It becomes readily apparent, that system 100 communicates with providers 114-120 over a distributed network such as the World Wide Web; the cloud. Additionally, the consumer communicates from their computer 102 with web page 104 and in turn API 108 over the World Wide Web; the cloud. However, applicant notes that the remainder of system 100 may be located at a single local location, or may be part of a distributed network in communication with each other and disposed within the cloud. Lastly it should be noted that any mechanism that transmits information about the consumer from computer 104 to API 108 is within the contemplated scope of the invention.
[0024] Reference is now made to
[0025] In a step 206, API 108 determines whether pertinent data for a particular consumer matches criteria for the offered product of each vendor, and selects the appropriate vendor, if any, based on matching the pertinent data and criteria at a predetermined threshold level indicative of the proposals being the type of interest to the consumer. The threshold may be merchant driven to screen for acceptable viable candidates and may include credit score thresholds, geographic location radius, or the like. API 108 transmits the pertinent consumer data in a step 208 as a function of the desired products or service to the various service/product vendors 114-120 meeting the criteria matching threshold.
[0026] API 108 begins a timeout count in a step 210 as a function of the transmission of the data to a respective vendor 114-120. A timeout count is begun for each respective vendor 114-120 as a function of when the data is transmitted to that particular vendor. API 108, based on inputs of clock 112, determines whether a predetermined interval of time has expired from the offer request transmission. If API 108 determines that no offer has arrived from a particular vendor before expiration of the time interval for that vendor, then API 108 removes the vendor from the list of potential sources for this offer. Offers received before expiration of the time period for each respective vendor are transmitted to the consumer at computer 102 as an updated proposal in a step 214. In this way computing resources are not wasted on offers which may not materialize, other offers are given an opportunity to be presented, and the process of sending the offers to the consumer is not unduly delayed.
[0027] In one embodiment, as information is parsed in step 204 by data entry application 106, information regarding renewal dates for services such as insurance, cell phone service, cable service and the like is transmitted to either one of clock 112 or API 108. As discussed above, a predetermined time interval until the renewal of such service is determined and clock 112 counts down the expiration of the renewal date in a step 216. In step 216 if it is determined that the time interval is about to expire, then the process moves to a step 206 in which potential replacement vendors with updated offers are solicited for proposals as discussed above. If the time interval has not ended then the count continues and the process returns to step 216. In the preferred embodiment, the time interval which is counted is such time period which is less than the expiration date such as one month, ten days or the like to provide the user meaningful time to compare received proposals with their current service contract. However the date cannot be so great that the proposal cannot reasonably expire as they are often time sensitive.
[0028] It is also beneficial to the consumer to receive a variety of quotes in a timely fashion to make an educated choice with respect to updated offers. It also keeps vendors' offers competitive by forcing them to provide offers that will be accepted compared to other vendors. In the preferred nonlimiting example system 100 provides five offers. Furthermore, offers must be screened for appropriateness. This is often a function of geography, budget, offer source (same insurer, many brokers) or the like. Accordingly, in the preferred nonlimiting embodiment, in step 206 appropriate vendors are not only selected, but provided in a manner to optimize the presentation of updated offers to the consumer at computer 102.
[0029] Reference is now made to
[0030] To ensure fairness in the system and that a single vendor does not monopolize the offer system, in a step 306 it is determined whether the selected vendor has exceeded a permitted number of offers made during a predetermined time period; fifteen offers in a single day by way of nonlimiting example. If the limit has been exceeded then the process returns to step 304 and a different vendor is provided. In other words the process stops for that vendor for this search of offers.
[0031] It is also desirable to prevent the consumer from being overwhelmed by a flood of offers even if from a variety of different vendors; this would be no different then the SPAM of current systems. Therefore, if the vendor has not exceeded its permissible allotted quoted offers in step 306, in a step 308 it is determined whether the number of vendors is greater than or equal to a determined limit on the number of vendors. In our non-limiting example, the system promotes providing five offers from five different vendors. However other numbers may be used. API 108 counts the number of vendors it has selected through step 306. In our example if the number of available vendors is less than five the process moves to step 208 to provide the data to the available vendors as no more vendors are available.
[0032] If in step 308 it is determined that the number of desired vendors has been exceeded, then in step 310, the vendor having the longest period since the last offer from that vendor is selected to be presented to the consumer. In this way, the process is fair to each vendor and promotes variety of vendors and offers. In a step 312 it is determined whether the number of vendors is equal to the predetermined limit of vendors, each vendor preferably providing one offer; five in the non limiting example. If the number is equal to five then in a step 314 the final set is created and the process moves to step 208. If the number has not been exceeded then the process proceeds to a step 316 where a determination is made to complete the vendor set.
[0033] In step 316 it is determined by API 108 how many vendors are remaining to be selected. If the number of vendors available for selection is greater than or equal to one the process returns to step 310. However if there are no remaining vendors and the total number of vendors is less than the desired five offers, it is determined by API 108 whether there are a sufficient number of vendors in step 318. If for example three or more vendors are acceptable as providing a sufficient number of updated offers then the final set of offers is made in a step 314 and the process returns to step 208. It should be noted that the number of sufficient vendors may be as low as one or as high as four. However in this way, the system can ensure that a meaningful number of offers is provided to the customer in step 208.
[0034] As a result of receiving consumer data from the consumers, then removing the personal information from that data, and storing that data for repetitive use, and transmitting that data to two or more potential vendors of proposals for goods or services, comparison-shopping for optimized terms and conditions can be provided to a consumer, with little consumer effort, without putting the consumer at risk of unwanted offers, spam, or loss of privacy through the sale of consumer information. Furthermore, by providing a clock to cause the offers to be sought either on a periodic basis, or in a timely manner upon the need for renewal of a product or service, product options are automatically updated and provided to the consumer without the need for the consumer to spend time and effort searching through the morass of online vendors, or the need to continuously reenter both personal and pertinent data for their use.
[0035] By counting and tracking the number of all offers made by each vendor and clocking the time period for accepted offers, system 100 can ensure a variety of offers and opportunities for both the consumer and the vendor.
[0036] The foregoing description is considered as illustrative only of the principles of the invention. Further, since numerous modifications and changes will be readily apparent to those skilled in the art, it is not desired to limit the invention to the exact construction and process shown as described above. Accordingly, all suitable modifications and equivalents may be resorted to falling within the scope of the invention as defined by the claims that follow.