DETAILED DESCRIPTION OF THE INVENTION

[0056] The following detailed description includes many specific details. The inclusion of such details is for the purpose of illustration only and should not be understood to limit the invention. Throughout this discussion, similar elements are referred to by similar numbers in the various figures for ease of reference. In addition, features in one embodiment may be combined with features in other embodiments of the invention.

[0057] Applying its state-of-the-art integrated information platform and metering technology, the present invention provides tools that collect and analyze total company energy and facility information. Using the generated information, the present invention diagnoses, recommends, and implements timely solutions to help manage facility energy requirements.

[0058] The present invention includes a complete range of energy and facility management tools:

[0059] Retriever Module:

[0060] Automated energy consumption data retrieval, archiving, and posting

[0061] Load data posting

[0062] Load analysis and comparison

[0063] Cost estimation based on tariff

[0064] News, weather, and technology links

[0065] Standard personalized branding of web site

[0066] Energy Analysis Module:

[0067] Load aggregation

[0068] Peak load analysis with trending and benchmarking tools

[0069] Cost estimation (“what-if” analysis)

[0070] Utility bill posting per existing tariff(s)

[0071] Automated notification with alarming and paging

[0072] Power Quality Module:

[0073] Data monitoring, event capture, and archiving

[0074] Web access to power quality information in various formats

[0075] Access to 24/7 Information Command Center

[0076] Personalized alarm triggering via pager, e-mail, cellular phone, or personal data assistant (PDA)

[0077] Harmonic analysis

[0078] Load Management Marketplace Module:

[0079] Automated posting of local and regional pricing

[0080] Benchmark load certification

[0081] Verification of load curtailment and payment amount

[0082] Bid notification and acceptance/rejection from supplier/ISO

[0083] Economic value calculation of load curtailment

[0084] Customer election to participate

[0085] Distributed Generation Dispatch Module:

[0086] Automated generator operation or load-shedding initiative

[0087] Verification of power generated and notification of curtailable event

[0088] Viewable data from any combination of assets

[0089] Real-time monitoring and alarming of all asset parameters.

[0090] Calculation of participation level and savings.

[0091] The present invention includes one or more of the following benefits:

[0092] Fast, secure access to information

[0093] Ability to differentiate loads/costs between buildings and/or equipment

[0094] Real-time access to system performance and control of energy assets

[0095] Enterprisewide access to information

[0096] 24/7 alarming and emergency response

[0097] Energy cost control

[0098] Increased reliability of equipment and systems

[0099] Reduced maintenance hours

[0100] Integration with existing equipment

[0101] Early warning of problems

[0102] Complete Scalability

[0103] Enhancement of existing building automation and control systems

[0104] State-of-the-art Information Command Center

[0105] The following specific areas of the present invention are further described herein:

[0106] Power Quality Functionality/Process

[0107] The present invention evaluates power quality to assess the operation of equipment and determining maintenance or repair needs. The evaluation consists of any or all of the following steps:

[0108] Design Analysis

[0109] Review facility and load performance objectives.

[0110] Identify locations where known deficiencies exist.

[0111] Identify pending renovations, expansions, or upgrades

[0112] Load Analysis

[0113] Monitor voltage and load variations at service entrance.

[0114] Measure distribution panel capacity.

[0115] Measure incoming currents and voltages.

[0116] Vulnerability Assessment

[0117] Inspect wiring and grounding.

[0118] Check for improper or missing neutral/ground connections.

[0119] Verify wiring and grounding practices.

[0120] Verify transformer configurations, grounding, and ratings.

[0121] Measure grounding system impedance.

[0122] Verify grounding practices of communication cabling.

[0123] Infrared Thermographic Inspection

[0124] Perform infrared scan of all accessible electrical panels, transformers, switchgear, and automatic transfer switches

[0125] Document equipment and locations showing abnormal heating and recommend corrective action.

[0126] Harmonic Analysis

[0127] Document facility harmonic voltage and current levels.

[0128] Surge Suppression Assessment

[0129] Verify surge suppresser installation practices.

[0130] Verify surge protective device energy ratings.

[0131] Uninterruptible Power Supply (UPS) Assessment

[0132] Preparation and Submittal of Report (including observations and recommendations for corrective action)

[0133] The present invention provides the following benefits for power quality functionality: methodology; increased system reliability; evaluation of power distribution system equipment according to all applicable industry standards; efficient and effective project coordination, requiring minimal customer time; reduction of system emergencies and costly downtime; availability of follow-up system repair and replacement services.

[0134] Retriever Module

[0135] The present invention provides information that enables a user to understand energy consumption data and helps formulate optimal strategies for energy procurement and use. By capturing energy data from metering devices, the present invention continuously updates information on facilities' energy consumption at the frequency selectable by the user. The present invention delivers this critical information via Internet- or network-based tools to make strategic, informed decisions that will increase system reliability and efficiency. The present invention provides the following features: automated retrieval of energy consumption data, archived in a data warehouse and posted to secure web pages; clear and understandable load data in various tabular and graphical formats; tools to analyze and compare energy load across time and facilities; accurate cost estimation based on existing tariffs.

[0136] The present invention provides the following benefits for the retiever module: optimize energy consumption decisions with actionable data; enable your internal energy management staff to make informed decisions; view and analyze your energy use for any single site or facility grouping you choose; gain information to shop for market-priced electricity on an hourly basis; nominate or change contracted natural gas quantities to gain optimal pricing; and calculate your estimated utility bill for any time period or billing cycle you select.

[0137] Energy Analysis Module

[0138] The present invention provides tools that will facilitate development of procurement and usage strategies. Building on information gathered by the Retriever module, the Energy Analysis Module generates signals that will assist in actually implementing an energy management strategy. The present invention includes the features of load aggregation; peak load analysis; trending and benchmarking; cost estimation (“what-if” analysis); utility bill posting per existing tariff(s); and automated alarming and paging based on software algorithms.

[0139] The present invention provides the following benefits: analyze energy power and load with electronic metering devices; manage energy usage patterns with effective visualization and historical trending tools; reduce future energy purchase costs by tracking usage over time; identify largest facility energy consumers by normalizing demand and usage data by a key variable; track the contribution of each facility and business line to overall consumption; generate utility bills for budgetary purposes and to verify accuracy; evaluate energy costs using alternative tariffs; and receive notification of current consumption behavior outside normal parameters.

[0140] Power Quality Module

[0141] The present invention provides an integrated approach to help minimize disruptions using the best metering technology and information. The Power Quality Module captures facility electrical disturbances that fall outside of industry-specified tolerance specifications established by the Computer and Business Equipment Manufacturers' Association CBEMA). This information, combined with monitoring and event notification, characterizes the integrity of the voltage and current waveforms at a specific point in the electrical power distribution system, permitting the assessment of its suitability for the reliable operation of connected equipment.

[0142] The present invention includes the features of: data monitoring, recording, and archiving; event capture; posting of power quality information on customized web site (tabular and graphical); access to 24×7 Information Command Center; alarm triggering (according to prespecified criteria); alarm notification via pager, e-mail, cellular phone, or personal data assistant (PDA); waveform capture; and harmonic analysis.

[0143] The present invention provides the benefits of: receive immediate notification of operating problems within sensitive electronic equipment; capture and analyze alarm trends to avoid unplanned shutdowns of vulnerable equipment; reduce downtime costs; accurately pinpoint electrical events not previously possible after the fact; evaluate auxiliary systems to ensure exceptional performance levels; and optimize operations with a single point of contact for system performance.

[0144] Load Management Marketplace Module

[0145] Once the user has the ability to manage your facility energy load actively, the Load Management Marketplace Module enables the user to capitalize on the volatility of the energy supply market. The ability to make smart business decisions regarding operating costs will increase as idle assets are turned into revenue generating opportunities.

[0146] The present invention includes the following features: automated posting of day-ahead and hour-ahead local and regional pricing; transaction platform that allows bid notification from energy supplier or ISO for voluntary load reduction including time period, total requirement, and price offered; economic value calculation of load curtailment (customer “self-serve”); customer election to participate, including amount of load curtailment and time period; bid acceptance/rejection by supplier/ISO; benchmark load certification; and verification of load curtailment and payment amount.

[0147] The present invention provides the following benefits: capitalize on revenue generation opportunities and maximize energy cost savings; optimize contributions to curtailment opportunities by aggregating multiple sites; maximize your load curtailment planning with automated notifications on energy price signals; and manage ongoing analysis of revenue generating opportunities.

[0148] Information Command Center (ICC)

[0149] Primary Domain Controller (PDC)—Used to provide authentication to all authorized uses of the ICC computer network domain. Also used to perform ICC network administrative taks.

[0150] Backup Domain Controller (BDC)—Routinely synchronized with the PDC. In the event that the PDC is offline, the BDC performs PDC functions. Also serves as a database server for the the MV90 communications database.

[0151] Application Server—Used to dispatch generation and accumulate detailed engine and generator operation-related data from systems with distributed generation.

[0152] Workstations—Equipped with modems, these units are used to perform support through remote interrogation of standalone energy management systems and/or field devices. Also used to perform routine functions for contract related services such as reports, alarm analysis and response, and power quality event analysis. The workstations are used to support internal system maintenance and upgrades. Workstations also monitor locational marginal price (Imp) in various regions around the United States to help determine when generator dispatching should be performed.

[0153] Television—Used to monitor weather conditions in and outside of the region to relate electrical system events to external conditions where appropriate.

[0154] 3 Zone Clocks—Used to track Local, Pacific, and Universal Time in order to relate events and or database information to appropriate regional times.

[0155] Audio System—Provides audible alerts due to event drive occurrences for immediate response by operators.

[0156] ICC Furniture—This fan-cooled console furniture is used to house servers and workstations. Constructed with dual position stations, it provides the users with access to multiple workstations from each position making it convenient to converse via phone with the customer while simultaneously addressing service related issues.

[0157] Uninterruptible Power Supply—Services as temporary backup power for the ICC in the event that an electrical power outage occurs.

[0158] HVAC system—Used to provide climate/humidity control for optimal PC performance.

[0159] In one embodiment of the invention, the billing engine is a C++ program that was written for the purpose of creating reports that will display a cost estimate of billing charges for a given customer based on a customer's tariff and time period. The report, in one embodiment, does not replicate a customer bill exactly, but provides a close estimation of charges over a period of time defined by the system user. All tariff information used by the billing engine is stored, for example, in one or more files.

[0160] The billing engine is invoked by clicking the Cost Estimate menu item from the Customer Electric Selection List web page. After the engine has been started, the user has the option of creating a new report or selecting from a previously saved report. If the user selects an existing report, the report criteria page is displayed. If a new report is selected, the user will have an option of providing filtering information for the currently selected customer before the report criteria page is displayed. On the report criteria page, the user will be required to enter the dates for which the report will apply, the tariff to be used in the calculation, and the site or sites to be viewed, if there are more than one. The user may also select the report type and can create a name under which the report will be saved. After all criteria have been entered or selected, the user can click on the View Results button to display the report information.

[0161] The billing engine source code includes debugging flags and trace directives. These flags use the C++ define mechanism. By uncommenting these define statements, the engine will display information in great detail on the report web page. When compiling the production version, these flags should all be commented out. The flags exist in the following modules as follows:

[0162] Web_rate.cpp

[0163] TRACE WEB BILL

[0164] TRACE_FAKE_CYCLES

[0165] Bill_calc.cpp

[0166] DEBUG BILL

[0167] DEBUG AND

[0168] TRACE_BILL

[0169] LEVEL TRACE

[0170] Paramlist. cpp

[0171] TRACE_PARAM_MUNGE

[0172] The flow of the billing calculation engine can be defined in four main modules. Each module and a brief description follows:

[0173] Web_rate. cpp

[0174] This module is the site abstraction layer and is responsible for all user interface functionality and retrieving the data.

[0175] Bill_calc.cpp

[0176] This module is the administrator that is responsible for looping through all of the charges and calculating these charges. This module also contains most of the main objects used in the billing engine. These objects are listed below with their methods and operators:

[0177] Billing-item

[0178] Operator=—This operator is used to assign the values from one billed item to another.

[0179] Billing engine

[0180] Read_from_file—This method reads each line from the .ini file, determines what kind of data has been read, and then calls the appropriate objects to process the line of data.

[0181] Init_period—This method is used to initialize specified periods and prepare them for processing.

[0182] And_period—This method is used for joining periods that need to be accessed for a given billing period defined by the user

[0183] Not_period—This method is used to filter out periods which will not be applies to the billing period specified.

[0184] Process_period expression—This method is used to process the periods information by evaluating the operators, if they exist and calling and-period and not-period to process.

[0185] Get_usage—This method will get the usage information from the database for a specified period of time. It will calculate the amount to bill for this period of time.

[0186] Calculate_bill—This method is and administrative method which calls the calc charges method which is responsible for calculating all charges for a given bill.

[0187] Calc_charges—This method is the primary method that is responsible for the calculating of all charges for a given bill.

[0188] Get_tariff_choices—This accumulates the list of tariffs that can be selected from.

[0189] Locate_tariff—This method finds a tariff from the tariff list object.

[0190] Get_tariff_name—Given a tariff, this method returns the tariff name that is to be displayed on the web page.

[0191] Identify_tariff_constants—Based on a given tariff constant, this method returns true if the tariff can be found and false if the tariff cannot be found.

[0192] Check_charge—This method determines if the tariff listed for a given charge actually exists in the tariff list.

[0193] Dump—This method is used to display all utility, tariff, period and charge information. This is only used for debugging purposes.

[0194] Evaluate—This method is used to evaluate all billing functions provided in the billing engine. These functions include billamt, billqty, billhrs, billhistqty, billdays, and billhistamt.

[0195] Calculate_historical_bill—This function is used to calculate an historical bill. It is called from the evaluate method when the .ini file specifies the usage of the functions billhistqty or billhistamt.

[0196] Utility—Stores and operates on utility information provided in the .ini file.

[0197] Parse—This method is used to parse a line from the [utilities] section of the .ini file and put the data into a utility object.

[0198] Operator=—This operator is used to assign the values from one utility to another.

[0199] Utility_list—Collection of utility objects

[0200] Find—Given the name of a utility, this method will find and return the utility object within the collection that contains the provided utility name

[0201] Append—This method will add a utility object to the collection.

[0202] Dump—This method will create standard output of all utilities in the utility list.

[0203] This method is used for debugging purposes.

[0204] Tariff—Stores and operates on tariff information provided in the .ini file

[0205] Parse—This method is used to parse a line from the [tariffs] section of the .ini file and put the data into a tariff object.

[0206] Operator=—This operator is used to assign the values from one tariff to another.

[0207] Tariff_list—An object storing a collection of tariff objects

[0208] Find—Given the name of a tariff and utility, this method will find and return the tariff object within the collection that contains the provided information.

[0209] Append—This method will add a tariff object to the collection.

[0210] Dump—This method will create standard output of all tariffs in the tariff_list. This method is used for debugging purposes.

[0211] Period—Stores and operates on period information provided in the .ini file.

[0212] Parse—This method is used to parse a line from the [periods] section of the .ini file and put the data into a period object.

[0213] Operator=—This operator is used to assign the values from one period to another.

[0214] Operator &=—This operator is used to combine multiple periods together.

[0215] Sort_times—This method checks if the start time for a given period is before the end time. If it is not, the start time becomes the end time and the end time becomes the start time.

[0216] Clip date_range—This method will process the clipped, notclipped, prorate and endonly options for the defined period.

[0217] Period-list—An object containing a collection of periods.

[0218] Find—Given the name of a period and utility, this method will find and return the period object within the collection that contains the provided information.

[0219] Append—This method will add a period object to the collection.

[0220] Dump—This method will create standard output of all periods in the period-list. This method is used for debugging purposes.

[0221] Charge—Stores and operates on charge information provided in the .ini file.

[0222] Parse—This method is used to parse a line from the [charges] section of the .ini file and put the data into a charge object.

[0223] Operator=—This operator is used to assign the values from one charge to another.

[0224] Is applicable—This method will determine if a charge is to be applied to a given bill.

[0225] Prorate_tariff_change—The method is used to calculate the proration coefficient where a charge is to be prorated.

[0226] Charge-list—An object containing a collection of charge objects.

[0227] Find—Given the name of a tariff and utility, this method will find and return the charge object within the collection that contains the provided information.

[0228] Append—This method will add a charge object to the collection.

[0229] Dump—This method will create standard output of all charges in the charge-list. This method is used for debugging purposes.

[0230] Tariff information is stored and manipulated in a file. The file is made up of four basic types of entry or sections. Each of these types identifies the beginning of that specific section of the file. These sections are identified as utilities, tariffs, periods and charges. Each type of entry has its own specific comma-delimited format, as follows:

[0231] Utilities

[0232] This section contains a list of the utilities who have rates stored in the file. The section format follows:

[0233] Wholesaler—The number of the utility in the EnerWise database. Currently, the values are 27 for Conectiv Power Delivery (CPD), I for SCE.

[0234] Name—The name of the utility as identified throughout this file.

[0235] Description—Long description of the utility name.

[0236] Regulated—‘Y’ for regulated, ‘N’ for not regulated.

[0237] Service identifier—Currently supports ew_eastern for EnerWise® customers and ami-pacific for Amicos customers.

[0238] Tariffs

[0239] This section contains a list of all of the tariffs in a file. The section format follows:

[0240] Utility name—The name of the utility as it corresponds to the [utilities] section of this file.

[0241] Utility Regulated Name—The regulated utility name.

[0242] Rate identifier—Rate identifier such as R—residencial, GS—general service.

[0243] Service Identifier—This corresponds to the rate identifier in the utility section.

[0244] Long Rate Name—This is the name for the rate as it is displayed on the web page.

[0245] Periods

[0246] This section is used to define the time periods for different utilities. These periods can be defined by specific dates to separate winter and summer billing periods, or by hours and days of the week to define off-peak, mid-peak, and on-peak times. The section format follows:

[0247] Utility—This defines the utility for which the period will apply. The value indicated corresponds to the utility name in the utilities section of the file.

[0248] Name—A brief name to describe the period. Examples of this name would be summer, winter, off-peak, on-peak, mid-peak.

[0249] Time zone—The time zone for which the period is defined. The system currently supports US/Eastern, US/Pacific, or GMT (Greenwich mean time).

[0250] Start date/time—This time indicates the time for which the period begins. The format of the date/time should be m/d/yyyy hh:mi.

[0251] End date/time—This time indicates the time for which the period ends. The format of the date/time should be m/d/yyyy hh:mi.

[0252] Bits—This field contains the days and hours for which the period applies. The format for hours is beginning hour—ending hour where beginning hour is the end of the hour for which the period is to begin and ending hour is the end of the ending hour. The hours are 1 to 24. The days are in a three character format. An example for this field would be Mon Tue Wed Thu Fri 1-8 to indicate weekdays from 12:00 AM to 8:00 AM.

[0253] Period qualifier—This field will either be notclipped, clipped, endonly, or prorate.

[0254] Charges

[0255] This section defines all of the specific charges for a given tariff. The section format follows:

[0256] Utility—The name of utility for this tariff as defined in the [utilities] section of this file.

[0257] Tariff—The name of the tariff as defined in the [tariffs] section of this file.

[0258] Group—The group for which this charge applies. This group is used for presentation purposed on the web page.

[0259] Name—The name of the charge as it will appear on the web page.

[0260] Period—The usage period for this charge as defined in the [periods] section of this file. Multiple periods can be entered by using the & character. An example of this would be summer & off-peak.

[0261] Time zone—The time zone for the applicability date of this charge. The system currently supports US/Eastern, US/Pacific, or GMT (Greenwich mean time).

[0262] Start date—The date for which the charge is effective. The format for the start date is m/d/yyyy.

[0263] End date—The end date of this charge. The format for the end date is m/d/yyyy.

[0264] Unit—The unit that is being used in the calculation. This field can be one of the following:

[0265] eval: term0 [*/+−] terml [*/+].. termn

[0266] max: term0, terml . . . termn

[0267] min: term0, terml . . . termn

[0268] A term is one of a number such as 234.23 or $kW, $kWHr, kVar, kVarhr, (see supporting data below) or billqty.item or billamt.item, where item is an item on the bill, or a total.

[0269] Operation identifier—The system supports max, min, avg, sum, count, max_slide. The common usage for this field is max for kw (demand) and sum for kwh (usage).

[0270] Minimum level—The minimum amount of usage for this charge to be applies. A value of zero should be the default.

[0271] Maximum level—The maximum amount of usage for this charge to be applied. A value of 0 should be the default to indicate no maximum.

[0272] Amount—The multiplier to be used in the calculation. This field is the cost per unit.

[0273] Charge qualifier—This column is can be used to indicate the criteria that must be met in order for this charge to apply. A value of 1 indicates that the charge will be always applied. An example of this field would be $service voltage<2000 to exclude all customers with a service voltage of greater than 2000. Data that can be used in qualifying calculations is listed below.

[0274] Prorate (optional)—If present, this optional field is used to indicate proratation across rate changes.

[0275] Level (optional)—If present, this optional field is used to indicate that the charge will use the average of multiple charges on the level, rather than the sum.

[0276] Summable (optional)—If present, this optional field is used to indicate that the item is considered a varying amount for purposes of charting.

[0277] Hidden (optional)—If present, this optional field is used to indicate that the charge will be used, but not presented on the web page.

[0278] Flatten (optional)—If present, this optional field. is used to indicate that hours are to be day aligned.

[0279] Data Support

[0280] The following data is supported in the unit and charge qualifier fields and can be identified in the file, as follows:

[0281] kW identified by $kw

[0282] kWh identified by $kwh

[0283] Service voltage identified by $service_voltage

[0284] kVAR identified by $kvar

[0285] kVARh identified by $kvarh

[0286] State tax identified by $state_tax

[0287] City tax identified by $city_tax

[0288] Timing identified by $timing

[0289] Phase identified by $phase

[0290] Excess tform identified by $excess_tform

[0291] Temperature identified by $temperature

[0292] Gas identified by $gas

[0293] Water identified by $water

[0294] Firm service identified by $firm_service

[0295] Air-conditioning cycling identified by $ac_cycling

[0296] Air-conditioning tons identified by $ac_tons

[0297] Standby kW identified by $standby

[0298] Limiter tariff identified by $limiter_tariff

[0299] Added facilities identified by $added_facilities

[0300] Controllable power identified by $control_power

[0301] Function Support

[0302] The billing engine provides built in functions for use in the file. These functions can be used to reference charges that have been previously listed in the file. An example of the syntax would be $billqty.charge. The following is a list of the functions:

[0303] $billqty—This function will produce the quantity of units used in the calculation of previously listed charge.

[0304] $billamt—This function will produce the billing amount of a previously listed charge.

[0305] $billhrs—This function will product the number of hours used for the calculation of a previously listed charge.

[0306] $billdays—The function will produce the number of days that applies to a given period.

[0307] $billhistqty—This function will produce the quantity of units used in the calculation for a previous period in history. This is used primarily for calculating ratchets.

[0308] $billhistamt—This function will produce the billing amount for a previous period in history for a given charge.

[0309] Note that one or more files or other means for accessing the data may alternatively be used.

[0310] In accordance with one embodiment of the invention, meter information regarding utility usage by a customer or other source that has been extracted from utility collection and/or billing meters is deposited into a database, and ultimately presented to an end user on behalf of a customer, such as on a web site over the World Wide Web, i.e., the Internet. The user may use the meter information to prepare various reports of utility billing information relating to actual and/or forecast utility usage and/or cost estimations for the customer. The reports may encompass any of the various variables such as user-defined billing periods, and may optionally include information not reflected in the standard billing statement. Advantageously, the present invention optionally allows the user on behalf of the customer to estimate their own energy usage responsive to estimated usage parameters, and further provides the customer the ability to define their usage requirements responsive to altering their usage parameters via the cost estimation of the present invention as described below is detail.

[0311] FIG. 4 provides an overview of an example network, encompassing utility billing meter collections, in connection with which the invention may be used. Although a number of elements are depicted in connection with the network, not all of the elements are required in order to operate the invention. As illustrated in FIG. 4 , such a system may include a billing engine 401 , data storage 403 , and optionally, a firewall 405 . The billing engine 401 stores and retrieves meter information into the data storage 403 , and transfers meter information in at least some embodiments through the firewall 405 . Similarly, meter information is received and stored in at least some embodiments via the firewall 405 into the data storage 403 . Such a network also includes means for communicating over a network, such as an FTP server and/or web server 407 , communicating with a World Wide Web 409 or other communications network. In the illustrated example, the billing engine 401 communicates with the World Wide Web 409 through the firewall 405 via the FTP server 407 . A customer browser 411 or other user interface may be connected to the World Wide Web 409 , or other appropriate communications medium, for communication of user queries and responses to and from the billing engine 401 . Optionally, the system may utilize any conventional communication system.

[0312] The billing engine 401 also receives meter information from a data acquisition server 413 or data verification process. The data acquisition server 413 receives meter information representative of utility readings from utility billing meters via communication lines 415 . The data acquisition server 413 uses the communication lines 415 to send commands, transmit requests and receive information to/from utility billing meters, such as the illustrated interval meters with modems 417 .

[0313] The interval meters with modems 417 , or other utility billing meters, receive and respond to manual and/or scheduled reading requests from a local distribution company's customer information system 419 by transmitting meter information for the interval(s). The meter information is stored locally at the customer information system 419 . The customer information system 419 may utilize locally stored meter information in order to generate printed energy billing statements 425 for various customers of a utility. The meter information from the customer information system 419 is also communicated to the billing engine 401 , optionally through a firewall 421 , to the World Wide Web 409 , via an FTP server 423 , or via other appropriate communications methods. The system may optionally receive meter information through other standard processes and/or systems.

[0314] As will be appreciated, there are several ways in which utility billing information, reflecting meter information, may be reviewed. One limited manner of reviewing utility billing information is via a standard printed energy billing statement 425 . Another manner in which a customer may review utility billing information is by electronically reviewing the billing statement. According to the invention, a customer may adjust variables affecting the billing statement and receive a report of utility billing information reflecting the adjusted variables. Also, some customers may prefer to receive more current and/or real time information. There are also a number of ways in which information concerning metered usage may be retrieved, either directly or indirectly, from utility billing meters. According to at least some embodiments, the meter information may be acquired by periodic polling, acquired on-demand, collected from the utility billing meter, and/or from some system that collects meter information (such as the customer information system 419 ).

[0315] Some systems may retrieve meter information from an existing utility billing meter 417 or other standard metering device. It may be desirable to have in place a device for remotely extracting meter information from the billing meter. Such a device could be, for example, a modem dial-up system and standard POTS lines 415 . Other remote communication devices and methods are possible, as well. By utilizing remote access, the billing engine 401 can access an existing or conventional utility billing meter that is ordinarily utilized for monthly billing by the utility. The billing engine 401 can extract meter information, such as interval data, as defined by the billing engine. Responsive to a user request, the billing engine may determine to collect real time meter information, or to extract some or all of the full range of utility usage information. Typically, a request to the utility billing meter for its current reading simply results in a response with the current reading. The retrieved meter information is then stored for further use in connection with the billing engine 401 in the data storage 403 . The billing engine 401 and data storage 403 may run on the same server, or may be distributed and run on one or more separate servers.

[0316] The stored meter information may then be referenced in connection with a query by the customer browser 411 or from an appropriate application server. The functions of the billing engine may optionally be distributed among separate servers, programmed devices and/or computer systems.

[0317] Meter information may be obtained on an as-needed basis from, for example, a standard remotely accessible utility billing meter. Therefore, remote access of a utility billing meter is particularly useful for customers who desire information more frequently than available in connection with the standard monthly billing statement. Remote access of a utility billing meter thus would be desirable for customers who prefer information at more frequent intervals such as hourly, quarter hourly, real time, or weekly.

[0318] Information that is not typically reflected in a billing statement, such as unprocessed and/or expanded meter power component information, may advantageously also be obtained from a utility billing meter in the present invention. Remote access, therefore, may be useful for customers who desire information beyond the conventionally available information on a billing statement. The typical information from a utility billing meter is limited to consumption and demand information, and perhaps some reactive power consumption information. Although some utilities generate utility billing statements based on apparent power, most utilities generate utility billing statements reflecting measured real power. By capturing at least two of the three power components in accordance with the present invention, however, all of the power components may be calculated. According to at least one embodiment of this invention, meter power component information, and/or other utility and usage information available from a utility billing meter, may be collected, manipulated and displayed as part of the reports of utility billing information, via the billing engine 401 .

[0319] In FIG. 4 , steps 417 through 423 illustrate a process which the utility, other customer and/or other third party utilizes for accessing and retrieving meter information from utility billing meters that reside outside of a customer's facility. The local distribution company's customer information system 419 optionally queries or polls the utility billing meters, typically on a periodic basis once a month, for meter information. The meter information is retrieved and stored, typically in the company's customer information system 419 . The configuration of the customer information system varies from customer to customer, and may be a distributed system or a single computer system, and may be of any size/capacity. The collected meter information is used by the customer information system to print energy bills 425 . The energy bills utilize the meter information that was retrieved from the utility billing meters. The meter information may be obtained by personnel utilizing handheld devices or transcribing the physical reading from the meter. The meter information thus manually entered is stored in the customer information system. It would be preferable to utilize an electronic meter with a modem, in order that the meter information may readily be retrieved remotely, without requiring manual intervention.

[0320] The meter information from the local distribution company's customer information system is transmitted to the billing engine 401 . In the illustrated method, the meter information is transmitted to the World Wide Web 409 , via a firewall 421 and an FTP server 423 . The billing engine then receives the meter information from the World Wide Web 409 via its own FTP server or web server 407 , through the firewall 405 , and then stores the received meter information in the data storage 403 . The meter information may be transmitted from the customer information system 419 to the billing engine 401 in any of several standard ways, including for example standard polling techniques or a specific request from the billing engine. Other standard communication protocols could be utilized in order to retrieve the meter information. For example, the customer information system 419 could initiate a transfer of the meter information to the billing engine 401 at the time that the customer information system has new meter information.

[0321] Hence, meter information coming into the billing engine 401 may be received coincident with the monthly billing cycle, or at a more or less frequent interval. The meter information can be processed in the same processing path, regardless of the interval frequency or the retrieval technique.

[0322] The illustrated system shows a file transfer protocol (“FTP”) server 423 used to transfer data representing the meter information which is stored in a file. Some utilities might prefer to utilize FTP for communication of data. Alternatively, the data representing the meter information may be transferred using any appropriate communication protocol. As another alternative, the customer information system 419 stores the meter information in a remote database such as on a hard drive of a personal computer (PC) a mainframe, or other standard database, to be retrieved by the billing engine. Ultimately, the meter information which is received or retrieved is utilized by the billing engine.

[0323] Reference is now made to FIG. 5 , illustrating one potential architecture for the billing engine shown in FIG. 4 . The billing engine includes various ways to enter information and/or variables affecting or relating to utility billing statements and/or used in preparing reports of actuals, forecasts and cost estimates for utility billing information. In the illustrated example, the information entry concerns meter rates 505 via a standard file 503 . The billing engine also includes a database and report generators 507 for storing, processing, and presenting meter information, utility billing information, and variables.

[0324] Rates are entered via an appropriate standard user interface via standard inputs. The rates are indicative of calculations which ultimately result in the fees shown in a utility billing statement. Rates are discussed by way of example herein.

[0325] The database and report generators 507 include some means for generating user interfaces, inputting information specified by a user, making appropriate calculations and presenting utility billing reports. In this particular example, the billing engine generates user interfaces via a typical method for generating hypertext markup language (HTML) pages 509 . However, any other appropriate method may be used to generate user interfaces and input user responses.

[0326] Also illustrated in FIG. 5 are data driven rates storage 511 , for rates which in at least some embodiments have the rate logic embedded in the rate data. Such rates may include related procedures or methods for determining the rate, riders and/or other components that impact a utility billing statement or report of other actual or forecast billing information and cost estimates. Various fees in utility billing statements are based on specific rates. The data driven rates storage 511 accumulates utilities' rules for determining rates. Advantageously, the various rules utilized for calculating rates are stored in a rules library, and may be accessed for use in making calculations.

[0327] The billing engine in the data driven rate storage 511 optionally includes a feature manager that allows the billing engine to determine which variables may be adjusted. FIGS. 6 A-C, described below, illustrate an example feature manager for the present billing engine which allows a change to certain attributes. The feature manager provides the user with the ability to change variables that are utilized in preparing utility billing statements, and in preparing reports of actual usage, forecast usage, and cost estimates. According to at least some embodiments, the feature manager has embedded logic for standard calculations relating to variables described below.

[0328] Interval data storage 515 is provided for retaining meter data, including interval data, utility usage data, utility demand data and any other data retrieved as part of the meter information from the utility billing meters. Power utility data typically is expressed as kilowatt hours and normally is associated with a measure of usage. Demand data typically is defined in smaller intervals, and defines the maximum amount of energy used in some pre-defined interval. Various utilities utilize different periods, including for example 15 minutes or 30 minutes, as the pre-defined interval for which interval data is collected. Demand data is able to measure periods of time when there is an increase in energy usage. Usage data reflects an overall accumulated usage.

[0329] The billing engine also includes a section for providing a data driven HTML bill report presentation, block 517 . The bill report presentation 517 provides for the presentation of bills. The reports are data driven, that is, the information and/or variables affecting or relating to utility billing statements and/or used in preparing reports of actual usage, forecast usage and cost estimates, as modified by the user, are automatically plugged into or displayed via an HTML report which automatically generates a report in accordance with the user-provided information, collected meter information, and rate information.

[0330] Reference is now made to FIGS. 6 A-C, illustrating an exemplary user interface for reports of actual usage, forecast usage and cost estimates for utility billing information from the billing engine. The user interface permits the user to alter variables, and thus to display actual usage, forecast usage and/or estimates of cost. According to at least some embodiments, as in this example, the variables which may be altered include time (billing) period 601 , and site tariff 602 - 607 . For each site/tariff 602 , in at least some embodiments, a user may adjust the type of tariff 611 , kW(Hr) 613 , kW 615 , kVar(Hr) 617 , state tax 619 , and city tax 621 . Any combination of variables affecting the utility billing information may be used. Indeed, in other embodiments, other standard variables may be provided in addition to, or in place of, the variables in this example. Such standard variables might include, for example, best and worst case scenarios based on this year's pricing and/or cost estimate fluctuation and/or previous years' historical pricing and/or cost estimate fluctuation.

[0331] In the example shown in FIG. 6 B, the user is altering the time period 601 to be utilized for the estimation period. Here, the billing engine is defaulting to the standard billing cycle of February 1997. Alternate billing cycles or specific dates may be selected or specified, if preferred. The user interface will take into consideration that the billing cycle varies depending on the utility by referring to the rules for billing cycles for that utility. For example, the “August” billing cycle may encompass July 25 through August 15.

[0332] The user may select particular sites and/or tariffs 602 to be included in reports of actual usage, forecast usage, and/or cost estimates. In this example, the sites for this particular customer include Agriculture Production 602 , Boiler 603 , College 604 , Lrg Indstrl 605 , Lt. Mfg 606 , and Process Line 607 , illustrated in FIGS. 6 B-C.

[0333] Variables affecting the fees may be adjusted by the user: various applicable tariffs may be selected and applied to a particular site, the state or city taxes may be altered. The energy usage may be altered as well. Any or all of these and/or other variable attributes affecting reports of actual usage, forecast usage and/or cost estimates may be displayed and altered, if preferred, by the user. In the illustrated example, these variables are specified and applied within a particular site. However, it may be desirable to provide that a user may apply one or more variables globally to a set of sites for a customer.

[0334] By utilizing the user interface and the ability to adjust variables, the user may provide an estimated forecast of its utility billing statement in specific scenarios. For example, a scenario might include a reduction of consumption by 40%. The cost estimate report displays results derived from a calculation of how such a reduction would impact the utility billing statement. In another example, a forecast estimate report is made by adjusting state tax to reflect a 20% increase. The results of the cost estimate report display show how that adjustment will impact the customer's billing statement.

[0335] In the example illustrated in FIG. 6 A, one of the rates that may be adjusted by selecting the tariff 611 includes general service transmission (GST) rate. A customer who has a GST rate is subject to certain rates per kilowatt hours used. A particular rate is applied to the first amount of kilowatt hours. Customers who have a GST rate will have an alternate rate which applies when the first minimum amount is exceeded. Other standard rules are utilized in determining rates. These rules may be specific to a particular utility. Even within each utility, these rules may be changed based on a customer's contractual rights. Based on the location of the customer and the utility utilized by the customer, the system selects and applies the correct standard calculation from amongst the stored rules in providing the report of actual usage, forecast usage and/or cost estimates.

[0336] Reference is now made to FIG. 6B . Here, for one of the sites, the user is specifying a billing cycle 605 which is non-standard. In this example, the user does so by entering start date and end date 605 to determine or specify the period of interest.

[0337] Consider, in this particular example, that the customer has five facilities under its care, including the three illustrated 602 , 603 , 604 . The user selects the particular facility, for example by clicking on the tab associated with the facility. The user may select and change particular attributes, such as to select a different rate. As illustrated in connection with the Process Line Facility 607 , in this example, the two possible rates for this facility are the GST and the General Service Primary (GSP) rates.

[0338] Once the user has altered the variables as desired, the user should in some way indicate that the alterations are complete, such as by indicating “finished” 609 . Upon an indication that the variables have been adjusted, the billing engine makes the indicated calculations utilizing the adjusted variables, meter information, and stored rules.

[0339] The system then produces a utility information report incorporating the altered variables, as illustrated in FIGS. 7A through 7B . FIGS. 7 A-B display one exemplary format for the utility information report providing calculated results. Typically, the utility information report will include results for a customer covering multiple sites and thus the report may be spread over multiple pages. It is therefore advantageous for the report to include a summary such as an optional table of contents 701 or index.

[0340] Where the utility information report covers multiple sites or facilities, it is preferable for the report to be represented independently for each site or facility. A user may page through the utility information report by selecting a particular facility and any subcategory within that facility. In the illustrated example, the utility information report for each facility is further divided into subcategories by time period. Optionally, the present invention also contemplates a consolidated report for multiple sites and/or facilities.

[0341] In accordance with well known procedures for HTML displays, selecting a site from the table of contents automatically displays the details of the utility information report for that selected site. In the illustrated example, the selected site is “Agriculture Production.” The billing engine displays the utility information report for the selected site 703 A through 703 B, as well as the site totals 705 .

[0342] The utility information report for each selected site and/or combination thereof optionally includes line items. Advantageously, line items which are detailed in the utility information report are those normally included in the printed utility billing statement for that customer. The utility information report preferably resembles a printed utility billing statement, in order to be familiar to a customer and therefore user friendly. In this example, the line items in the report for the Agriculture Production site 703 A-B are subdivided into “Delivery Charges,” “Supply Service Charges” and “Transmission Charges”. The Delivery Charges include, for example, a customer charge, a distribution charge based on a demand rate, a computer transmission based on a demand rate, a computer transmission charge based on an energy rate, an environmental fund rate, a low-income fund rate, and a power factor adjustment. The utility billing statement for this customer would typically group these changes as a “total delivery charge”, and thus the utility information report also optionally includes a display of subtotal delivery charges. In this example, line items which are subdivided into “Supply Service Charges” include, for example, a supply service charge for demand, a supply service charge for on-peak energy, and a supply charge for off-peak energy. In accordance with the usual billing statement format for this customer, the supply service charges are also totaled and the subtotal is displayed. The subdivision of line items for Transmission Charges includes, for example, a transmission demand charge and an ancillary service charge. This subdivision is also totaled, and the subtotal is displayed. In accordance with the typical format of the printed utility billing statement, optionally the total utility charges are then displayed in the utility information report.

[0343] Note that the utility information report optionally includes a display of the summary of the subtotals 705 . In this case, the subtotals include the delivery charge subtotal, the supply charge subtotal, and the transmission charge subtotal.

[0344] Utilizing the utility information reports, a user may adjust particular information, do an analysis, and obtain an estimate of a forecast or actual billing statement for a particular time period. Also, by utilizing the utility information report, a customer can determine if it is currently over or under or on target for its budget for energy. The customer may also run different hypothetical scenarios, such as moving a facility to a different state, to determine whether it is more cost effective to have a facility in an area with a particular rate versus a different area with a different rate.

[0345] Reference is now made to FIG. 8 , illustrating data flow relating to cost estimation utility information reports. This figure illustrates the data flow between various components relating to the billing engine, including cost estimation 801 , exception reporting 803 , forecasting 805 , curtailment 807 , benchmarking engine 809 , market price 811 , and an analytical package 813 . One or more of these components may, if preferred, be used in connection with the cost estimation 801 feature of the billing engine, discussed above.

[0346] The exception reporting component 803 provides an exception report to the customer or user when the customer or user has exceeded some predetermined amount of energy utilization or demand. This could be based on, for example a rolling average over a period of time utilized as a baseline, or perhaps a forecasted number. The exception report could include information on energy utilization. It also could include information on costs. The exception report could also include information extrapolating the current meter information and advising the customer of the forecast estimated utility billing statement for a particular time period, if the current usage continues.

[0347] The forecasting component 805 may forecast load and may also optionally forecast cost associated with that load. This will allow a customer to anticipate and perhaps curtail load in order to maintain a particular budget.

[0348] Also illustrated is the curtailment component 807 . This is another optional component. Curtailment includes the calculation of fees, based on a customer's anticipated reduction of a load. Certain utilities may provide an opportunity for financial revenue based on participation in a curtailment program. Curtailment can include voluntary or involuntary participation in a curtailment program. In order to decide whether or not to participate in an optional curtailment program, the customer may review cost estimation, in order to determine if it is feasible for the customer to reduce its utility usage. The customer can then determine if it will participate in a particular curtailment program, and what the effect would be for curtailing during a particular time period specified by the utility for curtailment. The curtailment system implemented by utility optionally includes a settlement process, during which the utility verifies that the customer did indeed curtail a load. The curtailment component 807 also provides for the utility to confirm that the curtailment occurred. Hence, the billing engine is optionally by the utility in order to confirm that the customer curtailed a load in accordance with its commitment, by comparing actual usage to any agreed-upon curtailment program. Optionally, the curtailment component 807 may be utilized to transmit a message to the customer announcing an invitation to participate in a curtailment event, and for the customer to respond to the invitation. Utilizing the cost estimation component 801 , the customer itself may determine how much was saved based on the curtailment by comparing the usage applying the curtailment rates to usage without curtailment rates.

[0349] The system optionally includes a benchmarking component 809 . The benchmarking component provides the ability to compare facilities to other facilities. For example, a customer may select a particular facility as its benchmark. Additional facilities of the customer can be compared against the benchmark. The comparison would generate a benchmark report. Preferably, such a report would reflect the differences from the benchmark facility. Any of the variables affecting utility billing information can be compared in the benchmark. Typically, one would prepare a benchmark report in connection with a comparison of utility usage.

[0350] Optionally, the system also includes a market price component 811 . Many utilities tend to use a hybrid model to determine pricing, utilizing real time pricing rates together with location marginal prices, as an alternative to standard tariff rates. Some utilities use a combination of both market price and tariff rates. Accordingly, the market price component 811 obtains and integrates the information for those utilities that are utilizing market pricing, and incorporates that information into the cost estimation calculation 801 . Utilization of the market price 811 is an alternative to applying the tariff rule that would ordinarily be applied by the cost estimation component 801 . The market price component 811 provides the flexibility to utilize the tariff rate, or alternatively the market pricing rate, or a combination thereof. For example, a customer may use a fixed rate; once a particular load is exceeded, the customer may be billed at a locational marginal price. Thus, the customer would experience savings as long as its usage remains below some finite number for a load. Once the load is exceeded, the utility may bill the customer based on a market price. Thus, the market price component accommodates roof changes in utility billing statement.

[0351] The system optionally includes an analytical package component 813 . The analytical package component was previously described in connection with FIGS. 6 A-C and FIGS. 7 A-B. The analytical package component provides the ability for a user to adjust variables, thereby providing “what-if” scenarios.

[0352] Reference is now made to FIG. 9 , illustrating one example process flow diagram for the billing engine. At block 901 , the user invokes the billing engine on behalf of the customer. This may be done by the user interacting with the user interface. Typically, once the billing engine is invoked, it would display a user interface, or other means for allowing entry of information and/or adjusting variables, block 903 . The user may adjust variables at its discretion. At block 90