US20090063369A1 - Automatically refreshing tailored pricing for retail energy market - Google Patents
Automatically refreshing tailored pricing for retail energy market Download PDFInfo
- Publication number
- US20090063369A1 US20090063369A1 US11/856,005 US85600507A US2009063369A1 US 20090063369 A1 US20090063369 A1 US 20090063369A1 US 85600507 A US85600507 A US 85600507A US 2009063369 A1 US2009063369 A1 US 2009063369A1
- Authority
- US
- United States
- Prior art keywords
- pricing
- energy
- price
- consumer
- customer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0201—Market modelling; Market analysis; Collecting market data
- G06Q30/0206—Price or cost determination based on market factors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0283—Price estimation or determination
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/06—Electricity, gas or water supply
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
Definitions
- This disclosure relates to computer systems and methods and, more particularly, to methods, systems, and software for pricing energy for a retail market and communicating the pricing.
- a typical electricity energy market includes power generating companies (PCGs), who generate electricity; wholesalers, who purchase electricity in bulk directly from the utilities; retailers, who sell electricity to and service consumers; and consumers, who purchase and consume electricity.
- PCGs power generating companies
- ISOs independent system operators
- RTOs regional transmission organizations
- retailers pair with a qualified scheduling entity (QSE) who matches the retailer's load with generation from the PCGs, and schedules the delivery of power, often through the ISO.
- Retailers sometimes engage salespeople to seek out new customers. These salespeople may work directly for the retailer or may be third-party brokers.
- a method for providing energy pricing includes receiving a pricing component.
- the method also includes automatically determining multiple prices for supplying energy. Each price may be determined for a different energy consumer and may be based at least on information about the consumer and the pricing component.
- the method further includes outputting the plurality of prices for supplying energy.
- a system for providing energy pricing includes a pricing engine operable to receive a pricing component and automatically determine multiple prices for supplying energy. Each price may be determined for a different energy consumer and may be based at least on information about the consumer and the pricing component.
- the system further includes an interface operable to output the plurality of prices for supplying energy.
- a computer readable media having instructions for a processor for performing operations includes receiving a pricing component.
- the operations also include automatically determining multiple prices for supplying energy. Each price is determined for a different energy consumer and is based at least on information about the consumer and the pricing component.
- the operations also include outputting the plurality of prices for supplying energy.
- a method for communicating energy pricing includes providing a first tailored transactable price for a customer. The method also includes automatically providing a second tailored transactable price for the customer in response to a change in a pricing component.
- a method in another embodiment, includes receiving usage data for a customer. The method also includes providing a tailored price based on the usage data. The method further includes before receiving a request for an updated price, determining the updated price. The method also includes providing the updated price.
- a method in another embodiment, includes a method includes receiving information about a customer. The method also includes determining a price tailored to the information about the customer. The method further includes displaying the price in a portal, wherein the portal is accessible through the internet.
- example methods and systems may be computer implementable and embodied in software. Moreover, some or all of these aspects and other aspects may be further included in respective systems and software for tailored transactable pricing.
- the method may also include receiving an updated pricing component and automatically updating the multiple prices for supplying energy based on at least the updated pricing component.
- the method may also include receiving multiple consumer profiles each having information on an energy consumer.
- the updated pricing component may be different for each of the plurality of consumer profiles.
- the pricing component may include a forecasted cost of energy supplied to the customer.
- Determining the updated price may include receiving a change to a pricing component, and automatically determining the updated price based, on the change.
- Providing the updated price may include providing a current updated price throughout a time period over which a pricing component used in determining the price changes.
- FIG. 1 Illustrates an example of the parties that participate in an energy market, and their relationships to one another.
- FIG. 2 is a block diagram of an example system for pricing energy for retail market and communicating pricing.
- FIGS. 3A-3C depict a process flow diagram illustrating the operation of an example system for pricing energy for retail market and communicating pricing.
- FIGS. 4A-4T are screen shots of graphical user interfaces (GUIs) associated with various aspects of the portal 240 of retailer system 226 .
- GUIs graphical user interfaces
- FIGS. 5A-5U are screen shots associated with various aspects of the pricing engine 242 , hedge engine 244 , report engine 246 , and database 248 .
- FIG. 6 is a flow chart of an example method for pricing energy for retail market and communicating pricing.
- FIG. 1 illustrates one example of the parties involved in producing and selling energy in a market.
- a power generating company (PCG) 110 generates or otherwise produces energy.
- the energy may be, for example, electricity, natural gas, oil, fuel, hydrocarbon byproducts, or other suitable forms of energy.
- An energy wholesaler 112 buys energy from the PCG 110 and sells to the retail or other suitable market.
- An energy retailer 114 buys energy from the wholesaler 112 and resells to consumers 118 through a sales agent (SA) 116 .
- SA sales agent
- system 200 includes SAs 228 , a wholesaler system 224 , and a retailer system 226 , all of which may be connected through a network 220 .
- the retailer 114 sells to consumers 118 via sales agents 116 .
- the energy is electricity.
- the system 200 may be used for selling energy at other levels and/or multiple levels.
- Network 220 facilitates wireless or wireline communication between computers and/or computer systems, such as between energy wholesaler 224 and energy retailer 226
- network 220 may be a logically segregated or distributed network without departing from the scope of this disclosure, so long as at least portion of network 220 may facilitate communications between senders and recipients of requests and results.
- network 220 encompasses any internal and/or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components in system 200 .
- Network 220 may communicate, for example, Internet Protocol (IP) packets.
- IP Internet Protocol
- ATM Asynchronous Transfer Mode
- Network 220 may include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the global computer network known as the Internet, and/or any other communication system or systems at one or more locations.
- LANs local area networks
- RANs radio access networks
- MANs metropolitan area networks
- WANs wide area networks
- the retailer system 226 generally may include a pricing engine 242 and a portal 240 .
- the portal 240 may receive customer information 202 from a sales associate 228 .
- the customer information 202 may include usage information 264 or may be used to obtain the usage information from a customer usage information system 210 .
- pricing engine 242 may forecast (at 284 ) the usage for the customer for a period of time, for example, up to a maximum contract term or for another period of time. This forecast 284 may be stored for the customer and used in future pricing calculations.
- the pricing engine 242 may calculate a tailored transactable price 204 that is forwarded to the sales agent 228 .
- the tailored transactable price 204 may be tailored to the usage pattern of the customer and form the basis of an offer to contract energy for a certain time period.
- retailer system 226 may communicate transactable prices 204 on demand, periodically, based on customer preferences, when warranted by changes In COGS 230 , the margin of the retailer 114 and/or other changes, and/or at other intervals.
- a tailored transactable price 204 may be requested by an SA 228 and returned to the SA 228 within a few minutes, or even a few seconds.
- an executable contract for energy services may also be transmitted. Some or all of these steps may be performed automatically.
- An advantage may be scalability in providing quick tailored transactable pricing for a large number of customers. This has the advantage of increasing customer yields for sales agents and retailers. Additionally, an advantage is that customer pricing may be done more efficiently, which allows retailers to reduce resources that are dedicated to pricing and focus those resources on other parts of the business. Various embodiments may have none, some, or all of these advantages.
- an energy retailer system 226 generally includes a portal 240 , a pricing engine 242 , a hedge engine 244 , a report engine 246 , and a database 248 .
- the portal 240 may be a combination of computer software and hardware that may provide an interlace between the energy retail system 226 and its users.
- the users of the system may include sales associates 228 , customers 208 , and internal users or administrators (not shown).
- the SA 228 or other user may, among other things, perform an initial setup for a customer by providing customer information 202 and may request pricing for the customer.
- the portal 240 may be accessible over a network 220 , such as the internet.
- the portal 240 may accept customer information 202 and store it in database 248 in a customer table 292 .
- the customer information 202 may include the usage history 206 for a customer 208 and other information.
- the usage history 206 may be independently obtained by the portal 240 from a customer usage database 210 that may be maintained by the PCG 110 or other entity.
- the PCG 110 may provide a downloadable file containing the usage data or may provide other access, including displaying the usage history on a web page.
- the energy retail system 226 can be configured to capture the usage data from the web page and process it into a format usable by the components of the energy retail system 226 .
- the portal 240 may retrieve automatically the usage history 206 from customer usage database 210 in response to receiving customer information 202 .
- the portal 240 also may be used to display and/or organize SA data 250 for each SA 228 .
- Each SA data 250 may include customer data 252 for customers 208 associated with the SA 228 , and current pricing 254 for each customer 208 .
- the current pricing 254 may be tailored to the specific customer 208 , for example taking into account one or more of the cost to transport the electricity to the customer 208 , the forecast usage 260 by the customer 208 , the peak usage by the customer 208 , the credit history of the customer 208 , and other factors.
- the current pricing 254 may be a tailored transactable pricing that is capable of acceptance by the customer 208 as part of a binding contract to sell and/or provide the agreed amount of energy during the agreed period at the current pricing 254 .
- Each SA 228 may create multiple pricing scenarios for the same client 208 and may associate a SA fee charged by the SA 228 with each different pricing scenario. Each pricing scenario may be periodically updated with current pricing 254 .
- the multiple pricing scenarios provide a customer 208 with options to compare when contracting for energy.
- the pricing scenarios may be for different contract periods, start dates, pricing models (such as fixed and indexed as described below), and/or other scenarios. In certain embodiments, the pricing scenarios may also include pricing for modifying or changing an existing contract.
- Each SA 228 may access the portal 240 to view the data and pricing for the customers 208 associated with the SA 228 .
- the portal 40 may be accessed via a secure logon or otherwise.
- the portal 240 or other part of the retailer system 226 may transmit an electronic mail message (email), instant message, or otherwise automatically contact the SA 228 or customer 208 in response to changes to pricing data 254 .
- the portal 240 or system 226 may automatically transmit an email to an SA 228 in response to any change in pricing, in response to upward or downward pricing information, in response to current pricing meeting a predefined or other point or threshold, in response to current pricing meeting a buy point or contract modification point, or in response to other suitable event.
- Many other events may be used in various embodiments to trigger an automatic contact to the SA 228 .
- the portal 240 may also display pricing information for a customer 208 , which may be accessible by a user of the system through a network 220 .
- the portal 240 may also, at the request of the SA 228 or otherwise, generate a contract for the customer 208 based on the pricing data 254 and a contract template 290 , which may be stored in database 248 .
- the contract may contain the pricing data 254 , a selected option within the pricing data 254 , or a price based on the pricing data 254 .
- the pricing in the contract may be transactable in that the contract is capable of immediate or later acceptance by the customer 208 without farther approval from the retailer 114 , without a later and more definite determination of pricing, or with reduced, simplified, or minimized approval. For example, a simple approval may only ensure that the customer returned the contract within a certain time period.
- the contract may be generated upon acceptance of the pricing or may be emailed or otherwise communicated upon the pricing meeting a value or threshold.
- generation and acceptance of the contract could be Immediate where the pricing meets a value agreed by the parties to be one at which a binding agreement would be automatically entered.
- the pricing engine 242 may be a combination of computer software and hardware that makes determinations and performs calculations related to tailored transactable prices for customers.
- the system 226 may use the pricing engine 242 to automatically push current pricing to sales agents 228 and potential customers 208 .
- the system 226 may also provide the current pricing for energy contracts as a legal offer in a transactable form.
- the pricing engine 242 may receive a number of inputs including the usage history 206 for a consumer 208 , the proposed contract period, the proposed service start date, the SA fees, the retailer margin, and the COGS 230 .
- the pricing engine 242 may determine a forecast 284 to facilitate the process of determining a tailored transactable price 204 .
- Other embodiments may have additional functionally, may omit certain functions and/or may have disparate functions.
- the usage history 206 is one or more files that contain information related to the past energy demands of a customer. Overall demand for energy may vary during the course of a day. For example, from 8:00 AM to 5:00 PM demand for energy may be at its peak. Because of the higher demand, prices for energy during those peak times may be higher. Thus, pricing is usually calculated based on-peak and off-peak usage.
- the usage data 206 may include information related to the total energy used in a given time interval, the maximum usage in a given time interval, and how the energy usage is distributed throughout the time interval. For example, usage history 206 may include the total energy used over a two-year period expressed in monthly intervals as kilowatt hours (kWh) per month.
- the interval may be small, such as 15 minutes, in which case the total energy used in a two-year period may be kWh per quarter hour.
- the interval may be any time period, including, but not limited to, daily, weekly, hourly, and semi-annually.
- the usage history 206 may also include for each month the maximum energy consumed on any day during each month, such as 196 kWh in April, and 210 kWh in May.
- the usage history 206 may also include a load profile describing how the energy usage is distributed throughout the time energy.
- the load profile may be determined by matching a customer 208 to one of several standard profiles that have been determined by ISOs or RTOs, based on, among other things, the industry, the size, and/or the location of the customer 208 .
- the load profile may indicate how the energy usage is distributed over a period, such as a year, using small intervals, such as 15 minutes. In some embodiments, certain customers may have equipment that measures usage at small enough intervals such that matching to a standard profile may not be needed.
- a customer 208 may have one or more sites. Each of these sites may have usage data associated with it.
- the forecast 284 may be determined from the on and off peak usage of a customer 208 .
- the usage data 206 may be used to determine the amount of energy used in hourly increments by combining a load profile with other usage data and adjusting the result to average usage per hour.
- the usage per hour may be used to determine the amount of energy consumed during peak and non-peak times.
- a forecast 208 may be determined for a specified maximum period, such as five years. The maximum period may be determined by the maximum period a retailer is willing to contract energy with any customer.
- the pricing engine 242 may store the forecast 284 . In some embodiments, the forecast. 284 may not have to be calculated again for the customer.
- the forecast 284 may be recalculated after the usage data 206 for a customer is refreshed.
- the usage data 206 may need to be refreshed if the characteristics of a customer 208 change and/or after a certain amount of time has elapsed since the usage data 206 was last loaded for a customer 208 .
- a tailored transactable price 204 may be determined for the customer 208 .
- pricing models there are two types, fixed and indexed. Some embodiments use other pricing models that are different from or are combinations of the fixed and indexed pricing models.
- the fixed pricing model is based on a customer agreeing to pay the same price regardless of market conditions.
- An indexed pricing model is based on a customer agreeing to pay some amount (in one example, a fixed amount) over an index that tracks energy prices, and may be based on a market clearing price for energy (MCPE).
- MCPE market clearing price for energy
- the risks of energy prices decreasing and increasing are respectively wholly born by the customer 118 (risk of decrease) or the wholesaler 112 /retailer 114 (risk of increase), respectively.
- the risk of energy prices decreasing or increasing is shared by the customer 118 and the wholesaler 112 /retailer 114 .
- the pricing engine 242 first takes a subset of the forecast 284 that corresponds to the period that the customer 208 proposes as an energy contracting period, which is the proposed start and term of a contract for energy. This period may be limited by the maximum period for which the retailer 114 is willing to contract. The retailer 114 may also determine the credit history of a customer and limit the contracting period based on the credit history.
- the wholesaler system 224 may generate or otherwise provide cost of goods data (COGS) 230 based on market information.
- the COGS 230 may include wholesale pricing information for the energy being sold. COGS 230 , expressed in some embodiments in dollars per kWh, may include the costs to deliver energy to a particular location.
- COGS 230 may vary according to, among other things, location, peak and off peak usage, month in which the energy is being delivered and/or other things.
- the pricing engine 242 may apply the COGS 230 to the subset of the forecast usage 284 corresponding to the contract period to determine a peak and an off peak cost.
- a combination cost may be determined from the weighted average of the peak price and the off peak costs.
- a tailored transactable price may be determined from the combination cost of energy by applying adders.
- the adders may include the fee of the sales agent, the margin of the retailer, and/or other fees and taxes. The other fees and taxes may vary by the specific market and/or customer location.
- the report engine 246 may be a combination of computer software and hardware that generates reports for users of the system 200 .
- the report engine 46 may generate one or more reports 80 .
- the reports 80 may be retailer reports on, for example, customer contracts entered and wholesale contracts entered.
- the reports may also include sales agent or customer reports.
- a report may describe the total sales on a monthly basis, an annualized volume of sales comparing actual to planned, contribution margins, or may itemize the number of customers contracted per month of a the past year. There are many variations of reports that may be implemented by report engine 246 .
- the hedge engine 244 may be a combination of computer hardware and software that may provide reports to users of the system 226 to facilitate hedging in the contracts in the wholesale market.
- the hedge engine 244 may include customer contracts 270 and wholesale contracts 272 .
- the hedge engine 244 may provide a report listing the contracts that need to be purchased on the wholesale market.
- the hedge engine 244 may also provide reports indicating the margins that may be needed on contracts.
- a user may use the information contained in the reports to decide which wholesale contracts to execute.
- the reports and the decisions based on the report may be automated within hedge engine 244
- the database 248 may be a combination of computer hardware and software that stores and organizes information used by retailer system 226 .
- the database 248 may store contract templates 290 , detailed customer data 292 and detailed broker SA data 294 .
- the contract templates 290 may include the necessary terms to form a binding contract absent pricing and customer identification which may be merged with the template data upon contract generation by the portal 240 or system 226 .
- the detailed customer information 292 may include customer name, address, locations of energy usage, and other suitable information. Customer usage 264 , forecast 284 , and credit reports, and other information may be stored in the detailed customer data 292 .
- the detailed SA data 294 may include SA name, address, customers, sales levels, and histories. Other suitable information on the SA 228 or his or her customers may also be stored in the detailed broker data 294 .
- Data and files described above in connection with elements of system 226 may be centrally stored in the database 248 , stored in other elements or systems, or otherwise.
- the modules of system 226 may access, but not store, the files and data in database 248 .
- the described functionally maybe automatic or automatically preformed, or may be preformed with user interaction.
- the engines and modules may perform or be used to perform the described functionality of other engines and modules.
- the customer 208 may directly use the system.
- the system 226 may allow SAs 228 to post proposed pricing for a customer to the retailer, and the retailer to accept the proposed pricing to form a binding contract, the remainder of the contract terms having been agreed.
- SA 208 may have contact with a customer 208 .
- the customer 208 may be interested in contracting for energy over a period of two years for example.
- the SA 228 may access retailer system 226 through portal 240 to determine the pricing for a retailer 114 implementing system 226 .
- the portal 240 may access database 248 to retrieve the customers 208 that are associated with the SA 228 .
- the SA 228 may be presented with a view of the customers 208 of the SA 228 , and with options to perform other tasks.
- the SA 228 may choose to setup a new customer prospect based on the information of the customer 208 .
- the information for the customer 208 may be inputted through a graphical user interface (GUI).
- GUI graphical user interface
- the SA 228 may upload the usage data associated with the customer 208 .
- the usage data 206 may alternatively be automatically obtained after the uploading of customer data 202 by system 226 from customer usage database 210 .
- the customer data 202 and/or usage data 206 may be manually verified.
- the pricing engine 242 may generate and store forecast usage data 260 .
- the pricing engine 242 may generate current pricing 254 based on the COGS 230 that are stored and the usage data 264 for the customer 260 .
- the current pricing 254 may be communicated (at 204 ) to the SA 228 and customer 208 within a short time after the customer data 202 is uploaded.
- the SA 228 may also setup a notification in system 226 , whereby system 226 may notify the SA 228 and/or customer 208 that the current pricing 260 has changed, or that the current pricing 260 has met some threshold value.
- Periodically system 226 may receive new COGS 230 from the wholesaler 224 . These new COGS 230 may not warrant an update in the current pricing 254 . At certain times newly received COGS 230 may prompt a change in current pricing 254 . Other changes within the system 226 may also prompt changes in current pricing 254 , such as the changes in the margins.
- a margin is the net of costs of goods sold and sales price. Users of the system 226 , such as administrators or others internal to the retailer 114 , may have access to update the margins.
- the system 226 may be configured to allow users to specify customers matching certain criteria to get a certain margin adjustment. The criteria may be based on geographic region, product type (e.g., fixed or Indexed), usage, and/or a host of other criteria.
- margins may be adjusted based on the commission of an SA 228 .
- Implementing margin adjustment may allow the retailer 114 to react quickly to the competitive marketplace.
- the system 226 may implement a default margin that is applied to customers meeting certain criteria similar to the criteria described with respect to updating margins. Margins may also be updated based on determinations made by the hedge engine 244 .
- the system 226 may retrieve the forecast usage data 284 for one or more customers 208 whose pricing may have changed and may apply the new COGS 230 and/or new margins to update the current pricing 254 .
- an SA 228 and/or customer 208 user may have a notification set to inform them of pricing changes.
- the SA 228 , wholesaler 224 , retailer 226 , and customer usage database 210 may each comprise one or more electronic computing devices operable to receive, transmit, process, and store data associated with system 200 .
- Each computer is generally intended to encompass any suitable processing device.
- Each computer may be any computer or processing device such as, for example, a blade server, a general-purpose personal computer (PC), Macintosh, workstation, Unix-based computer, or any other suitable device.
- PC general-purpose personal computer
- Macintosh workstation
- Unix-based computer Unix-based computer
- Each computer may be adapted to execute any operating system including Linux, UNIX, Windows Server, or any other suitable operating system.
- each computer may also include or be communicably coupled with a web server and/or a mail server.
- Each computing device may have memory and a processor.
- the memory may also be remote and connected through a network, such as network 220 .
- the memory is computer readable media suitable for storing computer program instructions and data.
- the memory may be any form of non volatile memory, media and memory devices, including by way of example random access memory (RAM), read-only memory (ROM), or other memory devices, such as, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks.
- the memory may store data, such as the contents of the database 248 , the reports 280 , or any data used in the various computing devices implemented in system 200 .
- the memory may also store software related to the portal 240 , the pricing engine 242 , the hedge engine 244 , the report engine 246 , and any other software executed by any of the computing devices used in system 200 .
- some or all of the foregoing data structures may be stored in one or more tables in a relational database described in terms of SQL statements or scripts.
- some or all of the foregoing data structures may be formatted, stored, or defined as various data structures in text files, eXtensible Markup Language (“XML”) documents, Virtual Storage Access Method (“VSAM”) files, flat files, Btrieve files, comma-separated-value (“CSV”) files, internal variables, or one or more libraries.
- the foregoing data structures may comprise one table or file or a plurality of tables or files stored on one computer or across a plurality of computers in any appropriate format. Indeed, some or all of the foregoing data structures may be local or remote without departing from the scope of this disclosure and store any type of appropriate data.
- Each computing device in system 200 may contain a processor that executes instructions and manipulates data to perform the operations of a computing device such as, for example, a central processing unit (CPU), a blade, an application specific Integrated circuit (ASIC), or a field-programmable gate array (FPGA).
- a processor will be operatively coupled to receive data and/or instructions from, or transfer data to, the memory.
- the processor and some or all of the data stored in the memory can be supplemented by, or incorporated in, special purpose logic circuitry, such as an application-specific integrated circuit.
- the SA 228 , wholesaler 224 , retailer 226 , and customer usage database 210 may each comprise or reference a local, distributed, or hosted computing software.
- computing software is any application, program, module, process, or other software that may access, retrieve, modify, delete, or otherwise manage some information of the in the memory.
- One example computing software may be a computer application for performing any suitable business process by implementing or executing a plurality of steps.
- Another example of computing software is an application that provides interconneetivity with one or more engines or modules.
- GUIs which allow users to input data and interact with the system 200 , are another example of computing software.
- computing software may be a composite application, or an application built on other applications, that includes an object access layer (OAL) and a service layer.
- the example service layer is operable to provide services to the composite application.
- These layers may help composite application to orchestrate a business process in synchronization with other existing processes (e.g., native processes of enterprise base systems) and leverage existing investments in the IT platform.
- composite application 112 may run on a heterogeneous IT platform.
- Computing software may also include or be coupled with a persistence layer and one or more application system connectors.
- application system connectors enable data exchange and integration with enterprise sub-systems and may include an Enterprise Connector (EC) interface, an Internet Communication Manager/Internet Communication Framework (ICM/ICF) interface, an Encapsulated PostScript (EPS) interface, and/or other interlaces that provide Remote Function Call (RFC) capability.
- EC Enterprise Connector
- ICM/ICF Internet Communication Manager/Internet Communication Framework
- EPS Encapsulated PostScript
- RRC Remote Function Call
- Computing software may also perform processing automatically, which may indicate that the appropriate processing is substantially performed by at least one component of system 200 .
- this disclosure further contemplates any suitable administrator or other user interaction with computing software or other components of system 200 without departing from its original scope.
- system 200 may utilize or be coupled with various instances of computing software.
- SA 228 may run a first computing software that is communicably coupled with a second computing software that is running on the retailer 226 .
- Portions of the computing software may be implemented as Enterprise Java Beans (EJBs) or design-time components may have the ability to generate run-time implementations into different platforms, such as J2EE (Java 2 Platform, Enterprise Edition), ABAP (Advanced Business Application Programming) objects, or Microsoft's .NET.
- J2EE Java 2 Platform, Enterprise Edition
- ABAP Advanced Business Application Programming
- Microsoft's .NET one or more processes associated with computing software may be stored, referenced, or executed remotely.
- a portion of computing software may be a web service that is remotely called, while another portion of computing software may be an interface object bundled for processing locally.
- computing software may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure.
- computing software may be a hosted solution that allows multiple parties in different portions of the process to perform the respective processing.
- SA 228 may access computing software, once developed, on retailer 226 or even as a hosted application located over network 220 without departing from the scope of this disclosure.
- “software” may include software, firmware, wired or programmed hardware, or any combination thereof as appropriate. Indeed, each of the foregoing software applications may be written or described in any appropriate computer language including C, C++, Java, Visual Basic, assembler, Perl, any suitable version of 4GL, as well as others. It will be understood that while these applications are shown as a single multi-tasked module that implements the various features and functionality through various objects, methods, or other processes, each may instead be a distributed application with multiple sub-modules. Further, one or more processes associated with these applications may be stored, referenced, or executed remotely. Moreover, each of these software applications may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure.
- Portions of the SA 228 , the wholesaler 224 , the customer usage database 210 , and the retailer 226 may be clients and/or servers in a client/server architecture.
- a client is any local or remote computing device operable to receive requests from the user via a user interface, such as a GUI, a CLI (Command Line Interface), or any of numerous other user interfaces. Thus, where reference is made to a particular interface, it should be understood that any other user interface may be substituted in its place.
- each client includes at least user interface and comprises an electronic computing device operable to receive, transmit, process and store any appropriate data associated with system 200 . It will be understood that there may be any number of clients communicably coupled to any given server.
- client and “user” may be used interchangeably as appropriate without departing from the scope of this disclosure.
- each client may be described in terms of being used by one user. But this disclosure contemplates that many users may use one computing device or that one user may use multiple computers to submit or review queries via user interface 116 .
- a client is intended to encompass a personal computer, touch screen terminal, workstation, network computer, kiosk, wireless data port, wireless or wireline phone, personal data assistant (PDA), one or more processors within these or other devices, or any other suitable processing device.
- PDA personal data assistant
- a client may comprise a computer that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with the operation of a server or clients, including digital data, visual information, or user interface.
- Both the input device and output device may include fixed or removable storage media such as a magnetic computer disk, CD-ROM, or other suitable media to both receive input from and provide output to users of a client through the display, namely a user interface.
- a GUI is a computer program hosted on a client.
- a GUI comprises a graphical user interface operable to allow the user of a client to interface with at least a portion of system 200 for any suitable purpose, such as viewing application or other transaction data.
- a GUI provides the particular user with an efficient and user-friendly presentation of data provided by or communicated within system 200 , such as current pricing 254 or customer data 252 .
- the GUI has presentation elements which may correspond to underlying data and/or to business objects of system 200 .
- Business objects may be software data structures that correspond to business entities, such as customers, prices, usage, and others.
- GUIs may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, and buttons operated by a user.
- a GUI may be operable to display certain presentation elements in a user-friendly form based on the user context, such as being tailored to a specific SA 228 that is logged into system 226 , and the displayed data.
- the term graphical user interface may be used in the singular or in the plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface.
- reference to the GUI may indicate a reference to the front-end or a component of an application, as well as the particular interface accessible via a client, as appropriate, without departing from the scope of this disclosure.
- a GUI contemplates any graphical user interface, such as a generic web browser or touchscreen, that processes information in system 200 and efficiently presents the results to the user.
- Servers can accept data from clients via a web browser (e.g., Microsoft Internet Explorer, Apple Safari, or Mozilla Firefox) and return the appropriate HTML or XML responses to the browser using network 220 .
- a web browser e.g., Microsoft Internet Explorer, Apple Safari, or Mozilla Firefox
- FIGS. 3A-3C depict a process flow diagram illustrating the operation of an example system for pricing energy for retail market and communicating pricing.
- the sales agent may obtain usage data associated with a customer.
- this data may be submitted to the retailer 226 along with a request for current pricing information.
- the retailer 226 may validate the usage data. In some embodiments, the usage data may be obtained directly from a PCG and may not need verification.
- the usage data is loaded into the retailer system 226 .
- the retailer system 226 may shape the usage data to the load profile to determine a more accurate indication of how the customer's usage is distributed.
- the usage forecast may be generated.
- the usage forecast may be generated for a maximum number of months or for a number of months indicated by the customer or sales agent.
- an offer may be created by determining a transactable price at which to sell the energy that is based on the customer's usage.
- the offer is validated. This may be done manually in some embodiments.
- offer documents are generated. The documents may be generated on the retailer system 226 and transmitted to the sales agent, or may be generated at the sales agent based on information from the retailer system 226 . A customer may decide to accept the offer and sign the documents.
- the signed documents may be received and reviewed at block 322 .
- the signed offer documents may be converted to a contract.
- FIGS. 4A-4T are screen shots associated with various aspects of the portal 240 of retailer system 226 .
- FIG. 4A is an example prospect list of potential customers 208 .
- FIGS. 4B-4G are example screen shots associated with various aspects of setting up a customer with the retailer system 226 .
- FIGS. 4H and 4I are example screen shots of transactable pricings based on a customer's usage.
- FIG. 4J is an example screen shot of a list of contracts that may be converted from one pricing model to another.
- FIG. 4K is an example screen shot of a conversion pricing request list.
- FIG. 4L is an example screen shot of pricing for a conversion request.
- FIG. 4M is a screen shot of a list of available sales material.
- FIG. 4N is a screen shot of an account view.
- FIG. 4O is a screen shot of a list of sales partners, which may not be available to SAs 228 that are not employees of the retailer 114 .
- FIGS. 4P and 4Q are screen shots of a view of details of a third party sales partner.
- FIGS. 4R and 4S are screen shots of example sales reports.
- FIG. 4T is an example general administration page.
- FIGS. 5A-5U are screen shots associated with various aspects of the pricing engine 242 , hedge engine 244 , report engine 246 , and database 248 .
- FIG. 5A is a screen shot of a pricing request administrator menu.
- FIGS. 5B-5D are screen shots of a pricing request creation GUI.
- FIG. 5E is a screen shot of a pricing request view.
- FIG. 5F is a screen shot of a list of batch jobs for automatic price updates.
- FIG. 5G is a screen shot of a GUI to adjust the margins for customers meeting certain criteria.
- FIG. 5H is a screen shot of a GUI to manage default margins.
- FIG. 5I is a screen shot of a usage library menu.
- FIG. 5J is a screen shot of a view of forecast data for a customer.
- FIG. 5K is a screen shot of a documents menu.
- FIG. 5L is a screen shot of a view of a list of documents associated with a particular customer.
- FIG. 5M is a screen shot of an enrollments/billing menu.
- FIG. 5N is a screen shot of an enrollment list.
- FIG. 5O is a screen shot of a GUI to convert a signed offer into a contract.
- FIG. 5P is a screen shot of an enrollment extract list.
- FIG. 5Q is a screen shot of a GUI for managing welcome packages.
- FIG. 5R is a screen shot of a forecasting/scheduling menu.
- FIG. 5S is a screen shot of an administration menu.
- FIG. 5T is a screen shot of a GUI for uploading COGS 230 .
- FIG. 5U is a screen shot of a GUI for managing global application switches such as automatic pricing and portal offer generation.
- the consumer profiles are associated with the consumers set up on the system by the sales agent, and can contain information such as identifying information about the consumer, the number of premises that energy will be supplied to, the geographic location of these premises, usage history at these premises and/or other information, as well as information on pricing scenarios including pricing model (fixed/indexed/hybrid), start date, term and/or others that are desired to be priced for the consumer.
- pricing model fixed/indexed/hybrid
- a forecasted usage is generated for a one or more consumers. As discussed above, a forecasted usage is generated corresponding to each consumer and may be determined from the on an off-peak usage of a consumer and may be generated for a specified maximum period.
- pricing components used in determining the price for supplying energy are received.
- the pricing components can include information such as COGS, sales agent fees, retailer margin, and/or other components and can include information specific one or more consumer (including information in the consumer profiles).
- the COGS can be specific to the characteristics of consumer, including for example, a raw cost of energy and the cost to transport the energy to the consumer's location(s).
- the energy retailer will periodically upload updated COGS into the energy retail system and/or update other pricing components as changes in the pricing components occur.
- the price is determined for supplying energy for one or more consumers over a future term for one or more pricing scenarios.
- the price can be tailored to each consumer, and based on information in the consumer profile, the forecasted usage for the consumer, pricing components (including COGS, sales agent fees, retailer margin) and/or other information.
- the pricing scenarios can provide for a fixed price pricing model, an indexed price pricing model, and/or a hybrid pricing model having a component of the price based on a fixed-price pricing model and a component of the price based on an indexed price pricing model.
- Operation 608 can be performed individually for each consumer, for example initially after the consumer profile and forecast are generated, or can be performed in a batch operation for a plurality of consumers selected by the energy retailer.
- the price is output for one or more consumers.
- the price may be output in a number of manners.
- the price may be displayed on the portal and/or may be communicated to the consumer or the sales agent via an e-mail or other electronic communication.
- updated prices are determined for supplying energy for one or more consumers over future term for one or more pricing scenarios.
- the updated price is output for one or more consumers.
- customers and consumers are entities that buy and/or use energy from retail energy providers.
- a customer or consumer may be a composite entity that includes multiple sites or buildings each having a separate utility connection. In such cases, each site or building having a separate utility connection may be viewed as separate customers or consumers, or each site or building could be aggregated and viewed as a single customer or consumer.
Abstract
Description
- This application claims priority under 35 USC §119(e) to U.S. Patent Application Ser. No. 60/967,036, filed on Aug. 31, 2007, and U.S. Patent Application Ser. No. 60/970,932, filed on Sep. 7, 2007 the entire contents of which are hereby incorporated by reference.
- This application is related to co-pending application entitled “Determining Tailored Pricing for Retail Energy Market”, application Ser. No. ______, filed on Sep. 14, 2007, the entire contents of which are hereby incorporated by reference.
- This disclosure relates to computer systems and methods and, more particularly, to methods, systems, and software for pricing energy for a retail market and communicating the pricing.
- A typical electricity energy market includes power generating companies (PCGs), who generate electricity; wholesalers, who purchase electricity in bulk directly from the utilities; retailers, who sell electricity to and service consumers; and consumers, who purchase and consume electricity. In many markets, independent system operators (ISOs) and regional transmission organizations (RTOs) exist to oversee the reliable and efficient transmission, of electricity from the utilities to the customers. In some markets, retailers pair with a qualified scheduling entity (QSE) who matches the retailer's load with generation from the PCGs, and schedules the delivery of power, often through the ISO. Retailers sometimes engage salespeople to seek out new customers. These salespeople may work directly for the retailer or may be third-party brokers.
- The disclosure provides various embodiments of systems, methods, and software for managing product development processes. In one embodiment, a method for providing energy pricing includes receiving a pricing component. The method also includes automatically determining multiple prices for supplying energy. Each price may be determined for a different energy consumer and may be based at least on information about the consumer and the pricing component. The method further includes outputting the plurality of prices for supplying energy.
- In another embodiment, a system for providing energy pricing includes a pricing engine operable to receive a pricing component and automatically determine multiple prices for supplying energy. Each price may be determined for a different energy consumer and may be based at least on information about the consumer and the pricing component. The system further includes an interface operable to output the plurality of prices for supplying energy.
- In another embodiment, a computer readable media having instructions for a processor for performing operations includes receiving a pricing component. The operations also include automatically determining multiple prices for supplying energy. Each price is determined for a different energy consumer and is based at least on information about the consumer and the pricing component. The operations also include outputting the plurality of prices for supplying energy.
- In another embodiment, a method for communicating energy pricing includes providing a first tailored transactable price for a customer. The method also includes automatically providing a second tailored transactable price for the customer in response to a change in a pricing component.
- In another embodiment, a method includes receiving usage data for a customer. The method also includes providing a tailored price based on the usage data. The method further includes before receiving a request for an updated price, determining the updated price. The method also includes providing the updated price.
- In another embodiment, a method includes a method includes receiving information about a customer. The method also includes determining a price tailored to the information about the customer. The method further includes displaying the price in a portal, wherein the portal is accessible through the internet.
- Each of the foregoing—as well as other disclosed—example methods and systems may be computer implementable and embodied in software. Moreover, some or all of these aspects and other aspects may be further included in respective systems and software for tailored transactable pricing.
- These and other embodiments can optionally include one or more of the following features. The method may also include receiving an updated pricing component and automatically updating the multiple prices for supplying energy based on at least the updated pricing component. The method may also include receiving multiple consumer profiles each having information on an energy consumer. The updated pricing component may be different for each of the plurality of consumer profiles. The pricing component may include a forecasted cost of energy supplied to the customer. The pricing component may include a margin. Outputting the prices for supplying energy may include offering to contract to supply energy to the consumer at the price.
- Automatically providing the second tailored transactable price may include receiving a change to the pricing component; automatically determining the second tailored transactable price based on the change; and automatically providing the second tailored transactable price. Automatically providing a second tailored transactable price may include automatically providing the second tailored transactable price through a time period.
- Determining the updated price may include receiving a change to a pricing component, and automatically determining the updated price based, on the change. Providing the updated price may include providing a current updated price throughout a time period over which a pricing component used in determining the price changes.
- The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
-
FIG. 1 Illustrates an example of the parties that participate in an energy market, and their relationships to one another. -
FIG. 2 is a block diagram of an example system for pricing energy for retail market and communicating pricing. -
FIGS. 3A-3C depict a process flow diagram illustrating the operation of an example system for pricing energy for retail market and communicating pricing. -
FIGS. 4A-4T are screen shots of graphical user interfaces (GUIs) associated with various aspects of the portal 240 ofretailer system 226. -
FIGS. 5A-5U are screen shots associated with various aspects of thepricing engine 242,hedge engine 244,report engine 246, anddatabase 248. -
FIG. 6 is a flow chart of an example method for pricing energy for retail market and communicating pricing. - Like reference symbols in the various drawings indicate like elements.
-
FIG. 1 illustrates one example of the parties involved in producing and selling energy in a market. One or more of the illustrated parties may be omitted or merged with others and/or additional parties included without departing from the scope of the present disclosure. Referring toFIG. 1 , a power generating company (PCG) 110 generates or otherwise produces energy. The energy may be, for example, electricity, natural gas, oil, fuel, hydrocarbon byproducts, or other suitable forms of energy. Anenergy wholesaler 112 buys energy from thePCG 110 and sells to the retail or other suitable market. Anenergy retailer 114 buys energy from thewholesaler 112 and resells toconsumers 118 through a sales agent (SA) 116. There are many variations that may exist. In other embodiments, for example, theretailer 114 andSA 116 maybe a single party. - Turning now to
FIG. 2 , which is a block diagram of an example system for pricing energy for retail market and communicating pricing,system 200 includesSAs 228, awholesaler system 224, and aretailer system 226, all of which may be connected through anetwork 220. In this embodiment, theretailer 114 sells toconsumers 118 viasales agents 116. In this example, the energy is electricity. Thesystem 200 may be used for selling energy at other levels and/or multiple levels. -
Network 220 facilitates wireless or wireline communication between computers and/or computer systems, such as betweenenergy wholesaler 224 andenergy retailer 226 Indeed, while illustrated as one network,network 220 may be a logically segregated or distributed network without departing from the scope of this disclosure, so long as at least portion ofnetwork 220 may facilitate communications between senders and recipients of requests and results. In other words,network 220 encompasses any internal and/or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components insystem 200.Network 220 may communicate, for example, Internet Protocol (IP) packets. Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses.Network 220 may include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the global computer network known as the Internet, and/or any other communication system or systems at one or more locations. - The
retailer system 226 generally may include apricing engine 242 and a portal 240. The portal 240 may receivecustomer information 202 from asales associate 228. Thecustomer information 202 may includeusage information 264 or may be used to obtain the usage information from a customerusage information system 210. Based on theusage information 264,pricing engine 242 may forecast (at 284) the usage for the customer for a period of time, for example, up to a maximum contract term or for another period of time. Thisforecast 284 may be stored for the customer and used in future pricing calculations. Based at least in part on theforecast 284 and the cost of goods sold data (COGS) 230, which may be obtained periodically from theenergy wholesaler 224, thepricing engine 242 may calculate a tailoredtransactable price 204 that is forwarded to thesales agent 228. The tailoredtransactable price 204 may be tailored to the usage pattern of the customer and form the basis of an offer to contract energy for a certain time period. After thecustomer information 202 andusage information 206 has been obtained and verified,retailer system 226 may communicatetransactable prices 204 on demand, periodically, based on customer preferences, when warranted by changes InCOGS 230, the margin of theretailer 114 and/or other changes, and/or at other intervals. In some embodiments, a tailoredtransactable price 204 may be requested by anSA 228 and returned to theSA 228 within a few minutes, or even a few seconds. In some embodiments, along with the tailoredtransactable price 204, an executable contract for energy services may also be transmitted. Some or all of these steps may be performed automatically. - An advantage may be scalability in providing quick tailored transactable pricing for a large number of customers. This has the advantage of increasing customer yields for sales agents and retailers. Additionally, an advantage is that customer pricing may be done more efficiently, which allows retailers to reduce resources that are dedicated to pricing and focus those resources on other parts of the business. Various embodiments may have none, some, or all of these advantages.
- Turning back to
FIG. 2 , anenergy retailer system 226 generally includes a portal 240, apricing engine 242, ahedge engine 244, areport engine 246, and adatabase 248. - The portal 240 may be a combination of computer software and hardware that may provide an interlace between the
energy retail system 226 and its users. The users of the system may includesales associates 228,customers 208, and internal users or administrators (not shown). Through portal 240, theSA 228 or other user may, among other things, perform an initial setup for a customer by providingcustomer information 202 and may request pricing for the customer. The portal 240 may be accessible over anetwork 220, such as the internet. The portal 240 may acceptcustomer information 202 and store it indatabase 248 in a customer table 292. Thecustomer information 202 may include theusage history 206 for acustomer 208 and other information. Some examples of other information include identifying information, for the consumer, the number of premises that energy will be supplied to, the geographic locations of the premises, and other information. In some embodiments, theusage history 206 may be independently obtained by the portal 240 from acustomer usage database 210 that may be maintained by thePCG 110 or other entity. For example, thePCG 110 may provide a downloadable file containing the usage data or may provide other access, including displaying the usage history on a web page. In instances where the usage data is displayed on a web page, theenergy retail system 226 can be configured to capture the usage data from the web page and process it into a format usable by the components of theenergy retail system 226. The portal 240 may retrieve automatically theusage history 206 fromcustomer usage database 210 in response to receivingcustomer information 202. The portal 240 also may be used to display and/or organizeSA data 250 for eachSA 228. EachSA data 250 may includecustomer data 252 forcustomers 208 associated with theSA 228, andcurrent pricing 254 for eachcustomer 208. - As described in more detail below, the
current pricing 254 may be tailored to thespecific customer 208, for example taking into account one or more of the cost to transport the electricity to thecustomer 208, theforecast usage 260 by thecustomer 208, the peak usage by thecustomer 208, the credit history of thecustomer 208, and other factors. Thecurrent pricing 254 may be a tailored transactable pricing that is capable of acceptance by thecustomer 208 as part of a binding contract to sell and/or provide the agreed amount of energy during the agreed period at thecurrent pricing 254. EachSA 228 may create multiple pricing scenarios for thesame client 208 and may associate a SA fee charged by theSA 228 with each different pricing scenario. Each pricing scenario may be periodically updated withcurrent pricing 254. The multiple pricing scenarios provide acustomer 208 with options to compare when contracting for energy. The pricing scenarios may be for different contract periods, start dates, pricing models (such as fixed and indexed as described below), and/or other scenarios. In certain embodiments, the pricing scenarios may also include pricing for modifying or changing an existing contract. EachSA 228 may access the portal 240 to view the data and pricing for thecustomers 208 associated with theSA 228. The portal 40 may be accessed via a secure logon or otherwise. - In addition, the portal 240 or other part of the
retailer system 226 may transmit an electronic mail message (email), instant message, or otherwise automatically contact theSA 228 orcustomer 208 in response to changes topricing data 254. For example, the portal 240 orsystem 226 may automatically transmit an email to anSA 228 in response to any change in pricing, in response to upward or downward pricing information, in response to current pricing meeting a predefined or other point or threshold, in response to current pricing meeting a buy point or contract modification point, or in response to other suitable event. Many other events may be used in various embodiments to trigger an automatic contact to theSA 228. The portal 240 may also display pricing information for acustomer 208, which may be accessible by a user of the system through anetwork 220. - The portal 240 may also, at the request of the
SA 228 or otherwise, generate a contract for thecustomer 208 based on thepricing data 254 and acontract template 290, which may be stored indatabase 248. The contract may contain thepricing data 254, a selected option within thepricing data 254, or a price based on thepricing data 254. The pricing in the contract may be transactable in that the contract is capable of immediate or later acceptance by thecustomer 208 without farther approval from theretailer 114, without a later and more definite determination of pricing, or with reduced, simplified, or minimized approval. For example, a simple approval may only ensure that the customer returned the contract within a certain time period. The contract may be generated upon acceptance of the pricing or may be emailed or otherwise communicated upon the pricing meeting a value or threshold. In addition, generation and acceptance of the contract could be Immediate where the pricing meets a value agreed by the parties to be one at which a binding agreement would be automatically entered. - The
pricing engine 242 may be a combination of computer software and hardware that makes determinations and performs calculations related to tailored transactable prices for customers. Thesystem 226 may use thepricing engine 242 to automatically push current pricing tosales agents 228 andpotential customers 208. Thesystem 226 may also provide the current pricing for energy contracts as a legal offer in a transactable form. Thepricing engine 242 may receive a number of inputs including theusage history 206 for aconsumer 208, the proposed contract period, the proposed service start date, the SA fees, the retailer margin, and theCOGS 230. Thepricing engine 242 may determine aforecast 284 to facilitate the process of determining a tailoredtransactable price 204. Other embodiments may have additional functionally, may omit certain functions and/or may have disparate functions. - The
usage history 206 is one or more files that contain information related to the past energy demands of a customer. Overall demand for energy may vary during the course of a day. For example, from 8:00 AM to 5:00 PM demand for energy may be at its peak. Because of the higher demand, prices for energy during those peak times may be higher. Thus, pricing is usually calculated based on-peak and off-peak usage. To determine the on and off peak usage of a customer, theusage data 206 may include information related to the total energy used in a given time interval, the maximum usage in a given time interval, and how the energy usage is distributed throughout the time interval. For example,usage history 206 may include the total energy used over a two-year period expressed in monthly intervals as kilowatt hours (kWh) per month. The interval may be small, such as 15 minutes, in which case the total energy used in a two-year period may be kWh per quarter hour. The interval may be any time period, including, but not limited to, daily, weekly, hourly, and semi-annually. Theusage history 206 may also include for each month the maximum energy consumed on any day during each month, such as 196 kWh in April, and 210 kWh in May. Theusage history 206 may also include a load profile describing how the energy usage is distributed throughout the time energy. The load profile may be determined by matching acustomer 208 to one of several standard profiles that have been determined by ISOs or RTOs, based on, among other things, the industry, the size, and/or the location of thecustomer 208. The load profile may indicate how the energy usage is distributed over a period, such as a year, using small intervals, such as 15 minutes. In some embodiments, certain customers may have equipment that measures usage at small enough intervals such that matching to a standard profile may not be needed. Acustomer 208 may have one or more sites. Each of these sites may have usage data associated with it. - The
forecast 284 may be determined from the on and off peak usage of acustomer 208. Theusage data 206 may be used to determine the amount of energy used in hourly increments by combining a load profile with other usage data and adjusting the result to average usage per hour. The usage per hour may be used to determine the amount of energy consumed during peak and non-peak times. By extrapolating the peak and off-peak usage, aforecast 208 may be determined for a specified maximum period, such as five years. The maximum period may be determined by the maximum period a retailer is willing to contract energy with any customer. Thepricing engine 242 may store theforecast 284. In some embodiments, the forecast. 284 may not have to be calculated again for the customer. Theforecast 284 may be recalculated after theusage data 206 for a customer is refreshed. Theusage data 206 may need to be refreshed if the characteristics of acustomer 208 change and/or after a certain amount of time has elapsed since theusage data 206 was last loaded for acustomer 208. - After the
forecast 284 has been generated for acustomer 208, a tailoredtransactable price 204 may be determined for thecustomer 208. Generally, there are two types of pricing models, fixed and indexed. Some embodiments use other pricing models that are different from or are combinations of the fixed and indexed pricing models. The fixed pricing model is based on a customer agreeing to pay the same price regardless of market conditions. An indexed pricing model is based on a customer agreeing to pay some amount (in one example, a fixed amount) over an index that tracks energy prices, and may be based on a market clearing price for energy (MCPE). In the fixed pricing model, the risks of energy prices decreasing and increasing are respectively wholly born by the customer 118 (risk of decrease) or thewholesaler 112/retailer 114 (risk of increase), respectively. In the indexed pricing model, the risk of energy prices decreasing or increasing is shared by thecustomer 118 and thewholesaler 112/retailer 114. - In determining fixed prices, the
pricing engine 242 first takes a subset of theforecast 284 that corresponds to the period that thecustomer 208 proposes as an energy contracting period, which is the proposed start and term of a contract for energy. This period may be limited by the maximum period for which theretailer 114 is willing to contract. Theretailer 114 may also determine the credit history of a customer and limit the contracting period based on the credit history. Thewholesaler system 224 may generate or otherwise provide cost of goods data (COGS) 230 based on market information. TheCOGS 230 may include wholesale pricing information for the energy being sold.COGS 230, expressed in some embodiments in dollars per kWh, may include the costs to deliver energy to a particular location.COGS 230 may vary according to, among other things, location, peak and off peak usage, month in which the energy is being delivered and/or other things. Thepricing engine 242 may apply theCOGS 230 to the subset of theforecast usage 284 corresponding to the contract period to determine a peak and an off peak cost. A combination cost may be determined from the weighted average of the peak price and the off peak costs. A tailored transactable price may be determined from the combination cost of energy by applying adders. The adders may include the fee of the sales agent, the margin of the retailer, and/or other fees and taxes. The other fees and taxes may vary by the specific market and/or customer location. - Turning now to indexed prices, an indexed price may be expressed as a fixed price amount added to a market index, such as for example $0.07 per kWh over the MCPE. The fixed price portion of the indexed price may be determined by adding adders to the costs associated with line loss. Line loss may depend on the location of the customer and the amount of energy transmitted. The adders are similar to the adders in the fixed pricing model.
- The
report engine 246 may be a combination of computer software and hardware that generates reports for users of thesystem 200. The report engine 46 may generate one or more reports 80. The reports 80 may be retailer reports on, for example, customer contracts entered and wholesale contracts entered. The reports may also include sales agent or customer reports. For example, a report may describe the total sales on a monthly basis, an annualized volume of sales comparing actual to planned, contribution margins, or may itemize the number of customers contracted per month of a the past year. There are many variations of reports that may be implemented byreport engine 246. - The
hedge engine 244 may be a combination of computer hardware and software that may provide reports to users of thesystem 226 to facilitate hedging in the contracts in the wholesale market. Thehedge engine 244 may include customer contracts 270 andwholesale contracts 272. Thehedge engine 244 may provide a report listing the contracts that need to be purchased on the wholesale market. Thehedge engine 244 may also provide reports indicating the margins that may be needed on contracts. A user may use the information contained in the reports to decide which wholesale contracts to execute. The reports and the decisions based on the report may be automated withinhedge engine 244 - The
database 248 may be a combination of computer hardware and software that stores and organizes information used byretailer system 226. In one embodiment, thedatabase 248 may storecontract templates 290,detailed customer data 292 and detailedbroker SA data 294. Thecontract templates 290 may include the necessary terms to form a binding contract absent pricing and customer identification which may be merged with the template data upon contract generation by the portal 240 orsystem 226. Thedetailed customer information 292 may include customer name, address, locations of energy usage, and other suitable information.Customer usage 264,forecast 284, and credit reports, and other information may be stored in thedetailed customer data 292. Thedetailed SA data 294 may include SA name, address, customers, sales levels, and histories. Other suitable information on theSA 228 or his or her customers may also be stored in thedetailed broker data 294. - Data and files described above in connection with elements of
system 226 may be centrally stored in thedatabase 248, stored in other elements or systems, or otherwise. Thus, the modules ofsystem 226 may access, but not store, the files and data indatabase 248. The described functionally maybe automatic or automatically preformed, or may be preformed with user interaction. The engines and modules may perform or be used to perform the described functionality of other engines and modules. In an embodiment where theSA 228 is omitted, thecustomer 208 may directly use the system. Thesystem 226 may allowSAs 228 to post proposed pricing for a customer to the retailer, and the retailer to accept the proposed pricing to form a binding contract, the remainder of the contract terms having been agreed. - In operation,
SA 208 may have contact with acustomer 208. Thecustomer 208 may be interested in contracting for energy over a period of two years for example. TheSA 228 may accessretailer system 226 through portal 240 to determine the pricing for aretailer 114 implementingsystem 226. Based on the credentials ofSA 228, the portal 240 may accessdatabase 248 to retrieve thecustomers 208 that are associated with theSA 228. TheSA 228 may be presented with a view of thecustomers 208 of theSA 228, and with options to perform other tasks. TheSA 228 may choose to setup a new customer prospect based on the information of thecustomer 208. The information for thecustomer 208 may be inputted through a graphical user interface (GUI). TheSA 228 may upload the usage data associated with thecustomer 208. Theusage data 206 may alternatively be automatically obtained after the uploading ofcustomer data 202 bysystem 226 fromcustomer usage database 210. In some embodiments, thecustomer data 202 and/orusage data 206 may be manually verified. - After the
customer data 202 andcustomer usage data 206 is received by thesystem 226, thepricing engine 242 may generate and storeforecast usage data 260. Thepricing engine 242 may generatecurrent pricing 254 based on theCOGS 230 that are stored and theusage data 264 for thecustomer 260. In some embodiments, thecurrent pricing 254 may be communicated (at 204) to theSA 228 andcustomer 208 within a short time after thecustomer data 202 is uploaded. TheSA 228 may also setup a notification insystem 226, wherebysystem 226 may notify theSA 228 and/orcustomer 208 that thecurrent pricing 260 has changed, or that thecurrent pricing 260 has met some threshold value. - Periodically
system 226 may receivenew COGS 230 from thewholesaler 224. Thesenew COGS 230 may not warrant an update in thecurrent pricing 254. At certain times newly receivedCOGS 230 may prompt a change incurrent pricing 254. Other changes within thesystem 226 may also prompt changes incurrent pricing 254, such as the changes in the margins. A margin is the net of costs of goods sold and sales price. Users of thesystem 226, such as administrators or others internal to theretailer 114, may have access to update the margins. Thesystem 226 may be configured to allow users to specify customers matching certain criteria to get a certain margin adjustment. The criteria may be based on geographic region, product type (e.g., fixed or Indexed), usage, and/or a host of other criteria. For example, margins may be adjusted based on the commission of anSA 228. Implementing margin adjustment may allow theretailer 114 to react quickly to the competitive marketplace. Furthermore, thesystem 226 may implement a default margin that is applied to customers meeting certain criteria similar to the criteria described with respect to updating margins. Margins may also be updated based on determinations made by thehedge engine 244. - When changes to
COGS 230 or margins warrant, thesystem 226 may retrieve theforecast usage data 284 for one ormore customers 208 whose pricing may have changed and may apply thenew COGS 230 and/or new margins to update thecurrent pricing 254. As previously mentioned, anSA 228 and/orcustomer 208 user may have a notification set to inform them of pricing changes. - The
SA 228,wholesaler 224,retailer 226, andcustomer usage database 210 may each comprise one or more electronic computing devices operable to receive, transmit, process, and store data associated withsystem 200. Each computer is generally intended to encompass any suitable processing device. Each computer may be any computer or processing device such as, for example, a blade server, a general-purpose personal computer (PC), Macintosh, workstation, Unix-based computer, or any other suitable device. In other words, the present disclosure contemplates computers other than general purpose computers, as well as computers without conventional operating systems. Each computer may be adapted to execute any operating system including Linux, UNIX, Windows Server, or any other suitable operating system. According to one embodiment, each computer may also include or be communicably coupled with a web server and/or a mail server. - Each computing device may have memory and a processor. The memory may also be remote and connected through a network, such as
network 220. The memory is computer readable media suitable for storing computer program instructions and data. The memory may be any form of non volatile memory, media and memory devices, including by way of example random access memory (RAM), read-only memory (ROM), or other memory devices, such as, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The memory may store data, such as the contents of thedatabase 248, thereports 280, or any data used in the various computing devices implemented insystem 200. The memory may also store software related to the portal 240, thepricing engine 242, thehedge engine 244, thereport engine 246, and any other software executed by any of the computing devices used insystem 200. - In some embodiments, some or all of the foregoing data structures may be stored in one or more tables in a relational database described in terms of SQL statements or scripts. In some alternative or complimentary situations, some or all of the foregoing data structures may be formatted, stored, or defined as various data structures in text files, eXtensible Markup Language (“XML”) documents, Virtual Storage Access Method (“VSAM”) files, flat files, Btrieve files, comma-separated-value (“CSV”) files, internal variables, or one or more libraries. In short, the foregoing data structures may comprise one table or file or a plurality of tables or files stored on one computer or across a plurality of computers in any appropriate format. Indeed, some or all of the foregoing data structures may be local or remote without departing from the scope of this disclosure and store any type of appropriate data.
- Each computing device in
system 200 may contain a processor that executes instructions and manipulates data to perform the operations of a computing device such as, for example, a central processing unit (CPU), a blade, an application specific Integrated circuit (ASIC), or a field-programmable gate array (FPGA). Generally, the processor will be operatively coupled to receive data and/or instructions from, or transfer data to, the memory. The processor and some or all of the data stored in the memory can be supplemented by, or incorporated in, special purpose logic circuitry, such as an application-specific integrated circuit. - The
SA 228,wholesaler 224,retailer 226, andcustomer usage database 210 may each comprise or reference a local, distributed, or hosted computing software. At a high level, computing software is any application, program, module, process, or other software that may access, retrieve, modify, delete, or otherwise manage some information of the in the memory. One example computing software may be a computer application for performing any suitable business process by implementing or executing a plurality of steps. Another example of computing software is an application that provides interconneetivity with one or more engines or modules. GUIs, which allow users to input data and interact with thesystem 200, are another example of computing software. - More specifically, computing software may be a composite application, or an application built on other applications, that includes an object access layer (OAL) and a service layer. The example service layer is operable to provide services to the composite application. These layers may help composite application to orchestrate a business process in synchronization with other existing processes (e.g., native processes of enterprise base systems) and leverage existing investments in the IT platform. Further,
composite application 112 may run on a heterogeneous IT platform. - Computing software may also include or be coupled with a persistence layer and one or more application system connectors. Such application system connectors enable data exchange and integration with enterprise sub-systems and may include an Enterprise Connector (EC) interface, an Internet Communication Manager/Internet Communication Framework (ICM/ICF) interface, an Encapsulated PostScript (EPS) interface, and/or other interlaces that provide Remote Function Call (RFC) capability. Computing software may also perform processing automatically, which may indicate that the appropriate processing is substantially performed by at least one component of
system 200. It should be understood that this disclosure further contemplates any suitable administrator or other user interaction with computing software or other components ofsystem 200 without departing from its original scope. Finally, it will be understood thatsystem 200 may utilize or be coupled with various instances of computing software. For example,SA 228 may run a first computing software that is communicably coupled with a second computing software that is running on theretailer 226. - Portions of the computing software may be implemented as Enterprise Java Beans (EJBs) or design-time components may have the ability to generate run-time implementations into different platforms, such as J2EE (
Java 2 Platform, Enterprise Edition), ABAP (Advanced Business Application Programming) objects, or Microsoft's .NET. Further, one or more processes associated with computing software may be stored, referenced, or executed remotely. For example, a portion of computing software may be a web service that is remotely called, while another portion of computing software may be an interface object bundled for processing locally. Moreover, computing software may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure. Indeed, computing software may be a hosted solution that allows multiple parties in different portions of the process to perform the respective processing. For example,SA 228 may access computing software, once developed, onretailer 226 or even as a hosted application located overnetwork 220 without departing from the scope of this disclosure. - Regardless of the particular implementation, “software” may include software, firmware, wired or programmed hardware, or any combination thereof as appropriate. Indeed, each of the foregoing software applications may be written or described in any appropriate computer language including C, C++, Java, Visual Basic, assembler, Perl, any suitable version of 4GL, as well as others. It will be understood that while these applications are shown as a single multi-tasked module that implements the various features and functionality through various objects, methods, or other processes, each may instead be a distributed application with multiple sub-modules. Further, one or more processes associated with these applications may be stored, referenced, or executed remotely. Moreover, each of these software applications may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure.
- Portions of the
SA 228, thewholesaler 224, thecustomer usage database 210, and theretailer 226 may be clients and/or servers in a client/server architecture. A client is any local or remote computing device operable to receive requests from the user via a user interface, such as a GUI, a CLI (Command Line Interface), or any of numerous other user interfaces. Thus, where reference is made to a particular interface, it should be understood that any other user interface may be substituted in its place. In various embodiments, each client includes at least user interface and comprises an electronic computing device operable to receive, transmit, process and store any appropriate data associated withsystem 200. It will be understood that there may be any number of clients communicably coupled to any given server. Further, “client” and “user” may be used interchangeably as appropriate without departing from the scope of this disclosure. Moreover, for ease of illustration, each client may be described in terms of being used by one user. But this disclosure contemplates that many users may use one computing device or that one user may use multiple computers to submit or review queries viauser interface 116. As used in this disclosure, a client is intended to encompass a personal computer, touch screen terminal, workstation, network computer, kiosk, wireless data port, wireless or wireline phone, personal data assistant (PDA), one or more processors within these or other devices, or any other suitable processing device. For example, a client may comprise a computer that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with the operation of a server or clients, including digital data, visual information, or user interface. Both the input device and output device may include fixed or removable storage media such as a magnetic computer disk, CD-ROM, or other suitable media to both receive input from and provide output to users of a client through the display, namely a user interface. - A GUI is a computer program hosted on a client. A GUI comprises a graphical user interface operable to allow the user of a client to interface with at least a portion of
system 200 for any suitable purpose, such as viewing application or other transaction data. Generally, a GUI provides the particular user with an efficient and user-friendly presentation of data provided by or communicated withinsystem 200, such ascurrent pricing 254 orcustomer data 252. The GUI has presentation elements which may correspond to underlying data and/or to business objects ofsystem 200. Business objects may be software data structures that correspond to business entities, such as customers, prices, usage, and others. - As shown in later figures, GUIs may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, and buttons operated by a user. For example, a GUI may be operable to display certain presentation elements in a user-friendly form based on the user context, such as being tailored to a
specific SA 228 that is logged intosystem 226, and the displayed data. It should be understood that the term graphical user interface may be used in the singular or in the plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. Indeed, reference to the GUI may indicate a reference to the front-end or a component of an application, as well as the particular interface accessible via a client, as appropriate, without departing from the scope of this disclosure. Therefore, a GUI contemplates any graphical user interface, such as a generic web browser or touchscreen, that processes information insystem 200 and efficiently presents the results to the user. Servers can accept data from clients via a web browser (e.g., Microsoft Internet Explorer, Apple Safari, or Mozilla Firefox) and return the appropriate HTML or XML responses to thebrowser using network 220. -
FIGS. 3A-3C depict a process flow diagram illustrating the operation of an example system for pricing energy for retail market and communicating pricing. Atprocess block 302, the sales agent may obtain usage data associated with a customer. Atprocess block 304, this data may be submitted to theretailer 226 along with a request for current pricing information. Atblock 306, theretailer 226 may validate the usage data. In some embodiments, the usage data may be obtained directly from a PCG and may not need verification. Atblock 308, the usage data is loaded into theretailer system 226. Atblock 310, theretailer system 226 may shape the usage data to the load profile to determine a more accurate indication of how the customer's usage is distributed. Atblock 312, the usage forecast may be generated. The usage forecast may be generated for a maximum number of months or for a number of months indicated by the customer or sales agent. At block 314, an offer may be created by determining a transactable price at which to sell the energy that is based on the customer's usage. In some embodiments, atblock 316 the offer is validated. This may be done manually in some embodiments. Atblock 318, offer documents are generated. The documents may be generated on theretailer system 226 and transmitted to the sales agent, or may be generated at the sales agent based on information from theretailer system 226. A customer may decide to accept the offer and sign the documents. Atblock 320, the signed documents may be received and reviewed atblock 322. Atblock 324, the signed offer documents may be converted to a contract. -
FIGS. 4A-4T are screen shots associated with various aspects of the portal 240 ofretailer system 226.FIG. 4A is an example prospect list ofpotential customers 208.FIGS. 4B-4G are example screen shots associated with various aspects of setting up a customer with theretailer system 226.FIGS. 4H and 4I are example screen shots of transactable pricings based on a customer's usage.FIG. 4J is an example screen shot of a list of contracts that may be converted from one pricing model to another.FIG. 4K is an example screen shot of a conversion pricing request list.FIG. 4L is an example screen shot of pricing for a conversion request.FIG. 4M is a screen shot of a list of available sales material.FIG. 4N is a screen shot of an account view.FIG. 4O is a screen shot of a list of sales partners, which may not be available toSAs 228 that are not employees of theretailer 114.FIGS. 4P and 4Q are screen shots of a view of details of a third party sales partner.FIGS. 4R and 4S are screen shots of example sales reports.FIG. 4T is an example general administration page. -
FIGS. 5A-5U are screen shots associated with various aspects of thepricing engine 242,hedge engine 244,report engine 246, anddatabase 248.FIG. 5A is a screen shot of a pricing request administrator menu.FIGS. 5B-5D are screen shots of a pricing request creation GUI.FIG. 5E is a screen shot of a pricing request view.FIG. 5F is a screen shot of a list of batch jobs for automatic price updates.FIG. 5G is a screen shot of a GUI to adjust the margins for customers meeting certain criteria.FIG. 5H is a screen shot of a GUI to manage default margins.FIG. 5I is a screen shot of a usage library menu.FIG. 5J is a screen shot of a view of forecast data for a customer.FIG. 5K is a screen shot of a documents menu.FIG. 5L is a screen shot of a view of a list of documents associated with a particular customer.FIG. 5M is a screen shot of an enrollments/billing menu.FIG. 5N is a screen shot of an enrollment list.FIG. 5O is a screen shot of a GUI to convert a signed offer into a contract.FIG. 5P is a screen shot of an enrollment extract list.FIG. 5Q is a screen shot of a GUI for managing welcome packages.FIG. 5R is a screen shot of a forecasting/scheduling menu.FIG. 5S is a screen shot of an administration menu.FIG. 5T is a screen shot of a GUI for uploadingCOGS 230.FIG. 5U is a screen shot of a GUI for managing global application switches such as automatic pricing and portal offer generation. - Turning now to
FIG. 6 , an example method for pricingenergy 600 is shown. Atoperation 602, one or more consumer profiles are received. The consumer profiles are associated with the consumers set up on the system by the sales agent, and can contain information such as identifying information about the consumer, the number of premises that energy will be supplied to, the geographic location of these premises, usage history at these premises and/or other information, as well as information on pricing scenarios including pricing model (fixed/indexed/hybrid), start date, term and/or others that are desired to be priced for the consumer. - At
operation 604, a forecasted usage is generated for a one or more consumers. As discussed above, a forecasted usage is generated corresponding to each consumer and may be determined from the on an off-peak usage of a consumer and may be generated for a specified maximum period. - At
operation 606, pricing components used in determining the price for supplying energy are received. The pricing components can include information such as COGS, sales agent fees, retailer margin, and/or other components and can include information specific one or more consumer (including information in the consumer profiles). The COGS can be specific to the characteristics of consumer, including for example, a raw cost of energy and the cost to transport the energy to the consumer's location(s). In certain instances, the energy retailer will periodically upload updated COGS into the energy retail system and/or update other pricing components as changes in the pricing components occur. - At
operation 608 the price is determined for supplying energy for one or more consumers over a future term for one or more pricing scenarios. As discussed above, the price can be tailored to each consumer, and based on information in the consumer profile, the forecasted usage for the consumer, pricing components (including COGS, sales agent fees, retailer margin) and/or other information. The pricing scenarios can provide for a fixed price pricing model, an indexed price pricing model, and/or a hybrid pricing model having a component of the price based on a fixed-price pricing model and a component of the price based on an indexed price pricing model.Operation 608 can be performed individually for each consumer, for example initially after the consumer profile and forecast are generated, or can be performed in a batch operation for a plurality of consumers selected by the energy retailer. - At
operation 610, the price is output for one or more consumers. As discussed above, the price may be output in a number of manners. For example, the price may be displayed on the portal and/or may be communicated to the consumer or the sales agent via an e-mail or other electronic communication. - At
operation 612, for example upon receipt of different or updated pricing components, updated prices are determined for supplying energy for one or more consumers over future term for one or more pricing scenarios. - At
operation 614, the updated price is output for one or more consumers. - The preceding flowchart and accompanying description illustrates
example method 600. It will be understood that this illustrated method is for example purposes only and that the described or similar techniques or processes may be performed at any appropriate time, including concurrently, individually, or in combination. In addition, many of the steps in the flowchart may take place simultaneously and/or in different orders than as shown. Moreover, methods may be used with additional steps, fewer steps, and/or different steps, so long as the methods remain appropriate. Also, as discussed above, one or more of the operations can be performed automatically. - The terms customers and consumers, as used throughout this specification, should be interpreted as interchangeable. Customers and consumers are entities that buy and/or use energy from retail energy providers. A customer or consumer may be a composite entity that includes multiple sites or buildings each having a separate utility connection. In such cases, each site or building having a separate utility connection may be viewed as separate customers or consumers, or each site or building could be aggregated and viewed as a single customer or consumer.
- A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.
Claims (25)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/856,005 US20090063369A1 (en) | 2007-08-31 | 2007-09-14 | Automatically refreshing tailored pricing for retail energy market |
CA 2697842 CA2697842A1 (en) | 2007-08-31 | 2008-08-29 | Tailored pricing for retail energy market |
PCT/US2008/074923 WO2009029895A2 (en) | 2007-08-31 | 2008-08-29 | Tailored pricing for retail energy market |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US96703607P | 2007-08-31 | 2007-08-31 | |
US97093207P | 2007-09-07 | 2007-09-07 | |
US11/856,005 US20090063369A1 (en) | 2007-08-31 | 2007-09-14 | Automatically refreshing tailored pricing for retail energy market |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090063369A1 true US20090063369A1 (en) | 2009-03-05 |
Family
ID=40408992
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/856,001 Active 2030-11-16 US8688506B2 (en) | 2007-08-31 | 2007-09-14 | Determining tailored pricing for retail energy market |
US11/856,005 Abandoned US20090063369A1 (en) | 2007-08-31 | 2007-09-14 | Automatically refreshing tailored pricing for retail energy market |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/856,001 Active 2030-11-16 US8688506B2 (en) | 2007-08-31 | 2007-09-14 | Determining tailored pricing for retail energy market |
Country Status (2)
Country | Link |
---|---|
US (2) | US8688506B2 (en) |
CA (1) | CA2697842A1 (en) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090222297A1 (en) * | 2008-02-29 | 2009-09-03 | International Business Machines Corporation | System and method for composite pricing of services to provide optimal bill schedule |
US20090222366A1 (en) * | 2008-02-29 | 2009-09-03 | International Business Machines Corporation | System and method for generating optimal bill/payment schedule |
US20090222371A1 (en) * | 2008-03-03 | 2009-09-03 | Arthur Miller | Method of energy procurement and system for employing |
US20090222319A1 (en) * | 2008-02-29 | 2009-09-03 | International Business Machines Corporation | System and method for calculating piecewise price and incentive |
US20090222311A1 (en) * | 2008-02-29 | 2009-09-03 | International Business Machines Corporation | System and method for calculating potential maximal price and share rate |
WO2011094378A1 (en) | 2010-02-01 | 2011-08-04 | The Procter & Gamble Company | Threaded closure assembly |
WO2011094739A1 (en) | 2010-02-01 | 2011-08-04 | The Procter & Gamble Company | Threaded cap |
US20130166501A1 (en) * | 2011-12-22 | 2013-06-27 | David-Olivier Saban | Method and system for data filing systems |
US20130218811A1 (en) * | 2012-02-20 | 2013-08-22 | Zenex Technologies Limited | Method of providing heating to a user |
WO2020172116A1 (en) * | 2019-02-19 | 2020-08-27 | Christopher Dunbar | System to fix the unit price or cost of power while on a real time electricity plan |
CN112116152A (en) * | 2020-09-17 | 2020-12-22 | 北京中恒博瑞数字电力科技有限公司 | Line loss double-rate optimization method and system based on synchronous data |
US11410190B1 (en) * | 2019-07-31 | 2022-08-09 | Energy Enablement Llc | System for calculating pricing using at least one of time dependent variables and preconfigured profiles |
US20230243541A1 (en) * | 2022-02-02 | 2023-08-03 | Generac Power Systems, Inc. | Mpc for hvac with thermal model selection |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100292855A1 (en) * | 2009-05-14 | 2010-11-18 | Michael Kintner-Meyer | Battery Charging Control Methods, Electrical Vehicle Charging Methods, Battery Charging Control Apparatus, and Electrical Vehicles |
WO2013016699A2 (en) * | 2011-07-27 | 2013-01-31 | Ephare Llc | Systems. methods, and media for automatically adjusting the prices of products and services based on consumer demand |
WO2013034169A1 (en) * | 2011-09-09 | 2013-03-14 | Its Telekom Servisleri Ltd. Sti. Iyte Kampus Subesi | Bidirectional communication system |
JP6192907B2 (en) * | 2012-08-06 | 2017-09-06 | 京セラ株式会社 | Energy management device, energy management system, and energy management method |
US20150066792A1 (en) * | 2013-09-03 | 2015-03-05 | Samuel S. SPRAGUE | Matching professional service providers with employers having work assignments |
FR3089330B1 (en) | 2018-11-29 | 2022-06-10 | Electricite De France | Method and device for predictive modeling of a customer's energy consumption |
TWI763087B (en) * | 2020-10-21 | 2022-05-01 | 國立清華大學 | Method and apparatus for peer-to-peer energy sharing based on reinforcement learning |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030055677A1 (en) * | 2001-09-14 | 2003-03-20 | Automated Energy, Inc. | Utility monitoring and management system |
US20030061091A1 (en) * | 2001-09-25 | 2003-03-27 | Amaratunga Mohan Mark | Systems and methods for making prediction on energy consumption of energy-consuming systems or sites |
US20040128266A1 (en) * | 2001-08-16 | 2004-07-01 | International Business Machines Corporation | Method for optimizing energy consumption and cost |
US20040181492A1 (en) * | 2003-03-12 | 2004-09-16 | Andrew Rybakowski | Method and apparatus for managing utility usage |
US20050187888A1 (en) * | 2004-02-19 | 2005-08-25 | William Sherman | Method for associating information pertaining to a meter data acquisition system |
US20050246220A1 (en) * | 2004-04-30 | 2005-11-03 | Nrgen Inc. | System and method for optimizing the cost of buying and selling electrical energy |
US20050283346A1 (en) * | 2004-05-24 | 2005-12-22 | Elkins Harold E Ii | Distributed generation modeling system and method |
US20060167591A1 (en) * | 2005-01-26 | 2006-07-27 | Mcnally James T | Energy and cost savings calculation system |
US7941369B2 (en) * | 2006-10-25 | 2011-05-10 | Joseph James Juras | Method of assisting a business in acquiring merchant services |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100402228B1 (en) | 2001-02-13 | 2003-10-17 | 주식회사 젤파워 | method and system for power supply broker using communication network and power demand controller |
JP4584056B2 (en) | 2005-07-08 | 2010-11-17 | 株式会社日立製作所 | Electricity supply and demand forecast and control system |
-
2007
- 2007-09-14 US US11/856,001 patent/US8688506B2/en active Active
- 2007-09-14 US US11/856,005 patent/US20090063369A1/en not_active Abandoned
-
2008
- 2008-08-29 CA CA 2697842 patent/CA2697842A1/en not_active Abandoned
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040128266A1 (en) * | 2001-08-16 | 2004-07-01 | International Business Machines Corporation | Method for optimizing energy consumption and cost |
US20030055677A1 (en) * | 2001-09-14 | 2003-03-20 | Automated Energy, Inc. | Utility monitoring and management system |
US20030061091A1 (en) * | 2001-09-25 | 2003-03-27 | Amaratunga Mohan Mark | Systems and methods for making prediction on energy consumption of energy-consuming systems or sites |
US20040181492A1 (en) * | 2003-03-12 | 2004-09-16 | Andrew Rybakowski | Method and apparatus for managing utility usage |
US20050187888A1 (en) * | 2004-02-19 | 2005-08-25 | William Sherman | Method for associating information pertaining to a meter data acquisition system |
US20050246220A1 (en) * | 2004-04-30 | 2005-11-03 | Nrgen Inc. | System and method for optimizing the cost of buying and selling electrical energy |
US20050283346A1 (en) * | 2004-05-24 | 2005-12-22 | Elkins Harold E Ii | Distributed generation modeling system and method |
US20060167591A1 (en) * | 2005-01-26 | 2006-07-27 | Mcnally James T | Energy and cost savings calculation system |
US7941369B2 (en) * | 2006-10-25 | 2011-05-10 | Joseph James Juras | Method of assisting a business in acquiring merchant services |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110213689A1 (en) * | 2008-02-29 | 2011-09-01 | International Business Machines Corporation | System and method for generating optimal bill/payment schedule |
US20090222366A1 (en) * | 2008-02-29 | 2009-09-03 | International Business Machines Corporation | System and method for generating optimal bill/payment schedule |
US8180691B2 (en) * | 2008-02-29 | 2012-05-15 | International Business Machines Corporation | System and method for generating optimal bill/payment schedule |
US20090222319A1 (en) * | 2008-02-29 | 2009-09-03 | International Business Machines Corporation | System and method for calculating piecewise price and incentive |
US20090222311A1 (en) * | 2008-02-29 | 2009-09-03 | International Business Machines Corporation | System and method for calculating potential maximal price and share rate |
US20090222297A1 (en) * | 2008-02-29 | 2009-09-03 | International Business Machines Corporation | System and method for composite pricing of services to provide optimal bill schedule |
US7962357B2 (en) | 2008-02-29 | 2011-06-14 | International Business Machines Corporation | System and method for calculating potential maximal price and share rate |
US7979329B2 (en) * | 2008-02-29 | 2011-07-12 | International Business Machines Corporation | System and method for generating optimal bill/payment schedule |
US8055530B2 (en) | 2008-02-29 | 2011-11-08 | International Business Machines Corporation | System and method for composite pricing of services to provide optimal bill schedule |
US7853516B2 (en) * | 2008-03-03 | 2010-12-14 | Direct Energy Business, Llc | Method of energy procurement and system for employing |
US20090222371A1 (en) * | 2008-03-03 | 2009-09-03 | Arthur Miller | Method of energy procurement and system for employing |
WO2011094739A1 (en) | 2010-02-01 | 2011-08-04 | The Procter & Gamble Company | Threaded cap |
US20110226721A1 (en) * | 2010-02-01 | 2011-09-22 | Richard Lawrence Horstman | Threaded closure assembly |
WO2011094378A1 (en) | 2010-02-01 | 2011-08-04 | The Procter & Gamble Company | Threaded closure assembly |
US20130166501A1 (en) * | 2011-12-22 | 2013-06-27 | David-Olivier Saban | Method and system for data filing systems |
US8700565B2 (en) * | 2011-12-22 | 2014-04-15 | Amadeus S.A.S. | Method and system for data filing systems |
US20130218811A1 (en) * | 2012-02-20 | 2013-08-22 | Zenex Technologies Limited | Method of providing heating to a user |
WO2020172116A1 (en) * | 2019-02-19 | 2020-08-27 | Christopher Dunbar | System to fix the unit price or cost of power while on a real time electricity plan |
US11410190B1 (en) * | 2019-07-31 | 2022-08-09 | Energy Enablement Llc | System for calculating pricing using at least one of time dependent variables and preconfigured profiles |
CN112116152A (en) * | 2020-09-17 | 2020-12-22 | 北京中恒博瑞数字电力科技有限公司 | Line loss double-rate optimization method and system based on synchronous data |
US20230243541A1 (en) * | 2022-02-02 | 2023-08-03 | Generac Power Systems, Inc. | Mpc for hvac with thermal model selection |
Also Published As
Publication number | Publication date |
---|---|
US20090063367A1 (en) | 2009-03-05 |
CA2697842A1 (en) | 2009-03-05 |
US8688506B2 (en) | 2014-04-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8688506B2 (en) | Determining tailored pricing for retail energy market | |
US7873541B1 (en) | System and method for aggregating advertising pricing data | |
US8429019B1 (en) | System and method for scheduled delivery of shipments with multiple shipment carriers | |
US8423954B2 (en) | Interactive container of development components and solutions | |
US20100312691A1 (en) | Loan Quotation System and Method | |
US8175936B2 (en) | Method and system for identifying reusable development components | |
US7949555B2 (en) | Tariff generation, invoicing and contract management | |
US20120330759A1 (en) | Energy systems | |
JP6188839B2 (en) | Electronic market for hosted service image | |
US20140278807A1 (en) | Cloud service optimization for cost, performance and configuration | |
US20030216971A1 (en) | User interface for a system using digital processors and networks to facilitate, analyze and manage resource consumption | |
US20140172479A1 (en) | Integrated Customer Profiling, Service Provider Matching and Smart Order, Creation System and Method | |
US20020019802A1 (en) | System and methods for aggregation and liquidation of curtailment energy resources | |
US9892467B2 (en) | System and method for implementing charge centric billing | |
US8719081B1 (en) | Bid adjustment scheduling for electronic advertising | |
KR20140033209A (en) | Facilitating billing of embedded applications | |
US20130282511A1 (en) | System and method for estimating, scheduling, and purchasing project services | |
JP2014528605A (en) | Customizable uniformity control for hosted service images | |
US20170200238A1 (en) | Aggregation of bids from multiple energy providers | |
US20150081422A1 (en) | Service providing apparatus and service providing method | |
US20160180420A1 (en) | Vehicle transaction systems and methods | |
US20070083442A1 (en) | Method, system and program products for batch and real-time availability | |
JP5606214B2 (en) | Automatic power trading system | |
US20210166253A1 (en) | Table-Based Rate Determination | |
US20070239470A1 (en) | Method and system for managing development component metrics |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HUDSON ENERGY SERVICES LLC, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BROWN, DERYL K.;BRANNAN, MICHAEL R.;MARZUOLA, DANIEL;AND OTHERS;REEL/FRAME:020294/0684 Effective date: 20071221 |
|
AS | Assignment |
Owner name: BP CORPORATION NORTH AMERICA INC., TEXAS Free format text: SECURITY AGREEMENT;ASSIGNOR:HUDSON ENERGY SERVICES LLC;REEL/FRAME:022782/0677 Effective date: 20090604 Owner name: BP ENERGY COMPANY, TEXAS Free format text: SECURITY AGREEMENT;ASSIGNOR:HUDSON ENERGY SERVICES LLC;REEL/FRAME:022782/0677 Effective date: 20090604 |
|
AS | Assignment |
Owner name: CANADIAN IMPERIAL BANK OF COMMERCE, AS COLLATERAL Free format text: SECURITY AGREEMENT;ASSIGNOR:HUDSON ENERGY SERVICES LLC;REEL/FRAME:025705/0120 Effective date: 20100507 |
|
AS | Assignment |
Owner name: HUDSON ENERGY SERVICES, LLC, CANADA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BP ENERGY COMPANY AND BP CORPORATION NORTH AMERICA INC.;REEL/FRAME:026041/0207 Effective date: 20110329 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: NATIONAL BANK OF CANADA, AS AGENT, CANADA Free format text: CHANGE OF NAME;ASSIGNOR:CANADIAN IMPERIAL BANK OF COMMERCE;REEL/FRAME:048482/0851 Effective date: 20190301 |