ENERGY PRODUCT INSTANT REBATE ENGINE

• US 20200134662A1
• Filed: 05/15/2019
• Published: 04/30/2020
• Est. Priority Date: 10/25/2016
• Status: Active Grant

• Current Assignee: Uplight, Inc.
• Original Assignee: Simple Energy, Inc. (Uplight, Inc.)
• Inventors: Lurie, Yoav, Segall, Justin, Jaroenvanit, Michel, Vajda, John, McColgan, Sean, Stewart, Jarod Earl, Girleanu, Nicolae Radu, Sukhanov, Ilya A., Konrath, Michael
• Granted Patent: US 11,023,919 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 16/9535 Search customisation based on user profiles and personalisation
• CPC Class Codes: G06Q 30/02 Marketing; Price estimation or determination; Fundraising
• CPC Class Codes: G06Q 30/0222 During e-commerce, i.e. online transactions
• CPC Class Codes: G06Q 30/0224 based on user history
• CPC Class Codes: G06Q 30/0236 Incentive or reward received by requiring registration or ID from user
• CPC Class Codes: G06Q 30/0239 Online discounts or incentives
• CPC Class Codes: G06Q 50/06 Energy or water supply
• CPC Class Codes: H04L 12/2838 Distribution of signals within a home automation network, e.g. involving splitting/multiplexing signals to/from different paths adaptations of television systems for transmission by electric cable for domestic distribution H04N7/106; hybrid transport H04L12/6418; home network arrangements specially adapted for distribution of digital video signals H04N7/24
• CPC Class Codes: H04L 67/1006 with static server selection, e.g. the same server being selected for a specific client

Abstract

Systems, methods, and apparatus are disclosed for providing instant rebates before a transaction is completed. This involves ingest of customer and rebate data from two or more utilities, where the data is parsed and normalized into a standard format across all of the utilities. The customer data is then stored in an accounts database, while the rebate data is further processed along with utility rebate rules to determine a set of rebate eligibilities for a variety of scenarios. The resulting rebate profiles can be stored in a rebates database and linked to corresponding customer account data in the accounts database. Third-party frontends can then request rebate eligibility based on a customer identifier and retail channel, and various services can work in tandem to query the rebated database and return a set of eligibilities with so little latency that the eligibility check appears instant from a customer'"'"'s standpoint.

Claims

1. A method for reducing latency in product rebate eligibility,

the method comprising:

parsing and normalizing customer and rebate data from one or more utility companies, via an ingest subsystem, to form normalized customer data and normalized rebate data in a format that is consistent across all of the one or more utility companies, wherein the normalized rebate data includes rebate rules specific to ones of the one or more utility companies;

storing persistent utility rebate rules in a first database, wherein the persistent utility rebate rules constitute rebate eligibility parameters that apply to at least one of the one or more utility companies;

storing runtime rebate rules in the first database or a second database, wherein the runtime rebate rules represent rebate eligibility parameters for a provider of energy-saving products and are customer-specific;

applying, via a rules engine, the persistent utility rebate rules to the normalized rebate data to generate rebate profiles, and storing the rebate profiles in the first or second database or a third database, wherein the rebate profiles include a plurality of rebate eligibilities for a plurality of redemption scenarios, and wherein each rebate profile is not customer-specific; and

then

querying, via the rules engine, the database having the rebate profiles for ones of the rebate profiles corresponding to a customer identification received from an API of a frontend client service;

applying, via the rules engine, the runtime rebate rules to the ones of the rebate profiles to identify one or more customer-specific rebates;

returning, via the rules engine, the customer-specific rebate to the API, so that the one of the frontend client services that provided the customer identification can apply the customer-specific rebate to a customer'"'"'s purchase.

2. The method of claim 1, wherein the normalized rebate data includes a number and type of rebates previously redeemed by customers of a corresponding one of the one or more utility companies.

3. The method of claim 2, wherein the normalized rebate data includes rebate rules specific to ones of the one or more utility companies, and the persistent utility rebate rules apply to at least one of the one or more utility companies.

4. The method of claim 1, wherein the normalized customer data includes at least a customer account number and a customer address.

5. The method of claim 1, wherein the provider of energy-saving products is selected from a group comprising:

one of the one or more utility companies;

an online retailer of energy-saving products;

a brick-and-mortar retailer of energy-saving products;

or a manufacturer of energy-saving products.

6. The method of claim 1, further comprising providing a rebate redemption transaction service configured to tabulate all rebate redemptions, report the same to the one or more utility companies, and update, in rebate profiles in the database having the rebate profiles, a number and type of rebates redeemed.

7. The method of claim 1, wherein the customer identification is an address or a utility account number.

8. The method of claim 1, wherein the parsing and normalizing further comprises:

parsing and normalizing customer and rebate data, via an ingest subsystem, to form the normalized customer data and the normalized rebate data, into a format that is consistent across all of the one or more utility companies, the customer and rebate data retrieved from one or more utility companies, formats of the customer and rebate data across the one or more utility companies being inconsistent before the parsing and normalizing.

9. A non-transitory, tangible processor readable storage medium, encoded with processor executable code to perform a method for determining product rebate eligibility before a transaction is completed, the method comprising:

parsing and normalizing and rebate data from one or more utility companies, via an ingest subsystem, to form normalized customer data and normalized rebate data, in a format that is consistent across all of the one or more utility companies, wherein the normalized rebate data includes rebate rules specific to ones of the one or more utility companies;

storing persistent utility rebate rules in a rebates database, wherein the persistent utility rebate rules constitute rebate eligibility parameters;

storing runtime rebate rules in the rebates database, wherein the runtime rebate rules represent rebate eligibility parameters for a provider of energy-saving products and are customer-specific;

applying, via a rules engine, the persistent utility rebate rules to the normalized rebate data to generate rebate profiles, and storing the rebate profiles in the rebates database, wherein the rebate profiles include a plurality of rebate eligibilities for a plurality of redemption scenarios, and wherein each rebate profile is not customer-specific and each rebate profile being unique to one of the utility companies and applicable to all customers of the one of the utility companies;

receiving a customer identification from a frontend client service;

querying, via the rules engine, the rebates database for ones of the rebate profiles corresponding to the customer identification;

applying, via the rules engine, the runtime rebate rules to the ones of the rebate profiles to identify one or more customer-specific rebates;

returning, via the rules engine, the customer-specific rebate to the frontend client service so that the frontend client service can apply the customer-specific rebate to a purchase of a customer associated with the customer identification.

10. The non-transitory, tangible processor readable storage medium of claim 9, wherein the normalized rebate data includes a number and type of rebates previously redeemed by customers of a corresponding one of the one or more utility companies.

11. The non-transitory, tangible processor readable storage medium of claim 10, wherein the normalized rebate data includes rebate rules specific to ones of the one or more utility companies, and the persistent utility rebate rules apply to at least one of the one or more utility companies.

12. The non-transitory, tangible processor readable storage medium of claim 9, wherein the normalized customer data includes at least a customer account number and a customer address.

13. The non-transitory, tangible processor readable storage medium of claim 9, wherein the provider of energy-saving products is selected from a group comprising:

one of the one or more utility companies;

an online retailer of energy-saving products;

a brick-and-mortar retailer of energy-saving products;

or a manufacturer of energy-saving products.

14. The non-transitory, tangible processor readable storage medium of claim 9, further comprising providing a rebate redemption transaction service configured to tabulate all rebate redemptions, report the same to the one or more utility companies, and update, in rebate profiles in the rebates database, a number and type of rebates redeemed.

15. The non-transitory, tangible processor readable storage medium of claim 9, wherein the customer identification is an address or a utility account number.

16. The non-transitory, tangible processor readable storage medium of claim 9, wherein at least one of the utility companies is associated with one or more rebate profiles.

17. The non-transitory, tangible processor readable storage medium of claim 9, further comprising receiving an update to the normalized rebate data without having to re-parse and re-normalize the customer data.

18. A method for reducing latency in product rebate eligibility, the method comprising:

parsing and normalizing customer and rebate data from a utility company, via an ingest subsystem, to form normalized customer data and normalized rebate data;

storing persistent utility rebate rules and runtime rebate rules in a rebates database,

wherein the persistent utility rebate rules constitute rebate eligibility parameters that apply to the utility company, and

wherein the runtime rebate rules represent customer-specific rebate eligibility parameters for a provider of energy-saving products;

applying, via a rules engine, the persistent utility rebate rules to the normalized rebate data to generate rebate profiles, and storing the rebate profiles in the rebates database, wherein the rebate profiles include a plurality of rebate eligibilities for a plurality of redemption scenarios, and wherein each rebate profile is specific to the utility company but not to any one customer; and

then

querying, via the rules engine, the rebates database for ones of the rebate profiles corresponding to a customer identification received from a frontend client service;

applying, via the rules engine, the runtime rebate rules to the ones of the rebate profiles to identify one or more rebates specific to a customer associated with the customer identification;

returning, via the rules engine, the one or more rebates to the frontend client service so that it can apply the rebate to a purchase of the customer.

19. The method of claim 18, wherein the normalized rebate data includes rebate rules specific to the utility company.