Energy product instant rebate engine
First Claim
1. A method for reducing latency in product rebate eligibility, the method comprising:
- providing an ingest subsystem;
providing a rebate rules registry in communication with the ingest subsystem;
providing an accounts database in communication with the ingest subsystem;
providing a rebates database in communication with the rebate rules registry;
providing a broker module;
providing a rules engine in communication with the rebates database and the broker module;
providing an accounts service in communication with the accounts database; and
parsing and normalizing customer and rebate data, via the ingest subsystem, to form normalized customer data and normalized rebate data, into a format that is consistent across all of the two or more utility companies, the customer and rebate data retrieved from two or more utility companies, formats of the customer and rebate data across the two or more utility companies being inconsistent before the parsing and normalizing, and wherein the normalized rebate data includes rebate rules specific to ones of the two or more utility companies;
storing persistent utility rebate rules in a rebate database, wherein the persistent utility rebate rules constitute rebate eligibility parameters that apply to at least two of the two or more utilities;
storing runtime rebate rules in the rebate database, wherein the runtime rebate rules represent rebate eligibility parameters for a provider of energy-saving products and are customer-specific;
storing the normalized customer data in the accounts database;
passing the normalized rebate data from the ingest subsystem to the rebate rules registry;
applying, via the rebate rules registry, the persistent utility rebate rules to the normalized rebate data to generate rebate profiles, and storing the rebate profiles in the rebate 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
thenreceiving a customer identification at the broker module from one of the frontend client services;
calling, via the broker module, the rules engine, with the customer identification as an input;
querying, via the rules engine, the rebates database for rebate profiles corresponding to the customer identification;
applying, via the rules engine, the runtime rebate rules to the rebate profiles to identify one or more customer-specific rebates;
returning, via the rules engine, the customer-specific rebate to the broker module; and
returning, via the broker module, 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.
6 Assignments
0 Petitions
Accused Products
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.
-
Citations
16 Claims
-
1. A method for reducing latency in product rebate eligibility, the method comprising:
-
providing an ingest subsystem; providing a rebate rules registry in communication with the ingest subsystem; providing an accounts database in communication with the ingest subsystem; providing a rebates database in communication with the rebate rules registry; providing a broker module; providing a rules engine in communication with the rebates database and the broker module; providing an accounts service in communication with the accounts database; and parsing and normalizing customer and rebate data, via the ingest subsystem, to form normalized customer data and normalized rebate data, into a format that is consistent across all of the two or more utility companies, the customer and rebate data retrieved from two or more utility companies, formats of the customer and rebate data across the two or more utility companies being inconsistent before the parsing and normalizing, and wherein the normalized rebate data includes rebate rules specific to ones of the two or more utility companies; storing persistent utility rebate rules in a rebate database, wherein the persistent utility rebate rules constitute rebate eligibility parameters that apply to at least two of the two or more utilities; storing runtime rebate rules in the rebate database, wherein the runtime rebate rules represent rebate eligibility parameters for a provider of energy-saving products and are customer-specific; storing the normalized customer data in the accounts database; passing the normalized rebate data from the ingest subsystem to the rebate rules registry; applying, via the rebate rules registry, the persistent utility rebate rules to the normalized rebate data to generate rebate profiles, and storing the rebate profiles in the rebate 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
thenreceiving a customer identification at the broker module from one of the frontend client services; calling, via the broker module, the rules engine, with the customer identification as an input; querying, via the rules engine, the rebates database for rebate profiles corresponding to the customer identification; applying, via the rules engine, the runtime rebate rules to the rebate profiles to identify one or more customer-specific rebates; returning, via the rules engine, the customer-specific rebate to the broker module; and returning, via the broker module, 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. - View Dependent Claims (2, 3, 4, 5, 6, 7)
-
-
8. 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:
-
providing an ingest subsystem; providing a rebate rules registry in communication with the ingest subsystem; providing an accounts database in communication with the ingest subsystem; providing a rebates database in communication with the rebate rules registry; parsing and normalizing customer and rebate data, via the ingest subsystem, to form normalized customer data and normalized rebate data, into a format that is consistent across all of two or more utility companies, the customer and rebate data retrieved from two or more utility companies, formats of the customer and rebate data across the two or more utility companies being inconsistent before the parsing and normalizing; storing persistent utility rebate rules in a rebate database, wherein the persistent utility rebate rules constitute rebate eligibility parameters that apply to at least two of the two or more utilities; storing runtime rebate rules in the rebate database, wherein the runtime rebate rules represent rebate eligibility parameters for a provider of energy-saving products and are customer-specific; storing the normalized customer data in the accounts database; passing the normalized rebate data from the ingest subsystem to the rebate rules registry; applying, via the rebate rules registry, the persistent utility rebate rules to the normalized rebate data to generate rebate profiles, and storing the rebate profiles in the rebate 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; providing a broker module; a rules engine in communication with the rebates database and the broker module; providing an accounts service in communication with the accounts database; and providing an API in communication with the broker module and the accounts service, and configured to interface with one or more frontend client services hosted on one or more frontend devices, the one or more frontend client services configured for interfacing with customers of the two or more utilities; receiving a customer identification at the broker module from one of the frontend client services; calling, via the broker module, the rules engine, with the customer identification as an input; querying, via the rules engine, the rebates database for rebate profiles corresponding to the customer identification; applying, via the rules engine, the runtime rebate rules to the rebate profiles to identify one or more customer-specific rebates; returning, via the rules engine, the customer-specific rebate to the broker module; and returning, via the broker module, 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. - View Dependent Claims (9, 10, 11, 12, 13, 14, 15, 16)
-
Specification