US20090187501A1 - Method and system for facilitating, coordinating and managing a competitive marketplace - Google Patents

Method and system for facilitating, coordinating and managing a competitive marketplace Download PDF

Info

Publication number
US20090187501A1
US20090187501A1 US12/397,192 US39719209A US2009187501A1 US 20090187501 A1 US20090187501 A1 US 20090187501A1 US 39719209 A US39719209 A US 39719209A US 2009187501 A1 US2009187501 A1 US 2009187501A1
Authority
US
United States
Prior art keywords
component
market
settlement
electric power
bid
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
Application number
US12/397,192
Inventor
Larry A. Winter
Francis X. Shields
Robert L. Northcutt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Accenture Global Services Ltd
Original Assignee
Accenture LLP
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Accenture LLP filed Critical Accenture LLP
Priority to US12/397,192 priority Critical patent/US20090187501A1/en
Publication of US20090187501A1 publication Critical patent/US20090187501A1/en
Assigned to ANDERSEN CONSULTING LLP reassignment ANDERSEN CONSULTING LLP ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NORTHCUTT, ROBERT L., SHIELDS, FRANCIS X., WINTER, LARRY A.
Assigned to ACCENTURE LLP reassignment ACCENTURE LLP CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: ANDERSEN CONSULTING LLP
Assigned to ACCENTURE GLOBAL SERVICES GMBH reassignment ACCENTURE GLOBAL SERVICES GMBH CONFIRMATORY ASSIGNMENT Assignors: ACCENTURE LLP
Assigned to ACCENTURE GLOBAL SERVICES LIMITED reassignment ACCENTURE GLOBAL SERVICES LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ACCENTURE GLOBAL SERVICES GMBH
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0283Price estimation or determination
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/04Billing or invoicing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/08Auctions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/06Electricity, gas or water supply
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/18Legal services; Handling legal documents
    • G06Q50/188Electronic negotiation

Definitions

  • the present invention is directed to a method and system for facilitating, coordinating and managing a competitive marketplace and, more particularly, a method and system for facilitating, coordinating and managing a competitive energy market using the Internet.
  • FIG. 1 illustrates the separation of physical and financial flows concerning electricity in the new competitive marketplace. It can be seen from FIG. 1 that while the physical flow of electricity remains unchanged, the financial flow is now from the consumers to the energy merchant and onto the producers.
  • a central operator is a broad term grouping a variety of organizations that lie at the center of the value chain, as shown in FIG. 2 . It describes the collective functions that facilitate, coordinate and manage the activities of participants in the electricity marketplace.
  • the traditional central operator's role has been to operate the transmission system, usually as a small division of a large utility or power pool (e.g., New England Power Pool). This is sometimes known as a system operator function.
  • the system operator is responsible for planning, scheduling and dispatching generation; managing the interconnected transmission grid; and ensuring short-term and long-term system reliability.
  • power pools, reliability councils, and traditional vertically integrated utilities have handled these tasks through coordinated efforts.
  • the central operator has emerged as a leading alternative to support the combined roles and responsibilities of these traditional organizations.
  • the central operator may be responsible for conducting an auction of energy and accepting and managing competitive bids and contracts for energy and ancillary services. It provides for the financial settlement of energy and ancillary service markets, including billing and clearance for market trading.
  • a method of facilitating, managing and coordinating the operation of a competitive marketplace using the Internet includes the steps of collecting bids for market services from a plurality of customers over the Internet, calculating a clearing price for a market service and calculating settlement information based upon the clearing price calculated and the bids collected.
  • the system includes a power system component that represents a network model of a physical power system including generating units, load facilities, transmission lines, and network areas.
  • the system includes a customer component that manages all information about entities that have a business relationship with a market operator.
  • the power system component and customer component are operatively coupled to a market operator to receive data from the market operator.
  • the system includes a bid component that enables customers to submit bids for energy services and a meter reading component that stores meter readings submitted by customers.
  • the bid component and meter reading component are operatively coupled to customers.
  • a settlement component financially settles all markets based upon meter readings, operational information, bids and clearing prices.
  • the settlement component is operatively coupled to the power system, customer, bid and meter reading components to receive data therefrom.
  • a bill component operatively coupled to receive data from the customer and settlement components summarizes the financial activity for each customer to be used on an invoice for services provided and/or received.
  • a method of facilitating, managing and coordinating the operation of a competitive marketplace using the Internet includes the steps of collecting bid and contract information for market services from a plurality of customers. The operation of units is then scheduled to provide the market services according to the bid and contract information collected. The operation of the units scheduled is next deployed and meter reading information from the units scheduled is collected. The market then settled in accordance with the bid, contract and meter reading information collected.
  • a computer program embodied on a computer readable medium for interfacing with a competitive marketplace.
  • the computer program includes code for collecting bids for market services from a plurality of customers over the Internet, code for calculating a clearing price for a market service, and code for calculating settlement information based upon the clearing price calculated and the bids collected.
  • an article of manufacture for facilitating the operation of a competitive marketplace.
  • the article of manufacture includes a computer readable medium having a management interface for collecting bids for market services from a plurality of customers over the Internet, calculating a clearing price for a market service, and calculating settlement information based upon the clearing price calculated and the bids collected.
  • the market publishing component includes two independent components, a database population component and a report generation component.
  • the database population component reorganizes data from many different sources into a common repository designed to suit customers' needs.
  • the report generation component is then called upon whenever a customer requires a pre-defined report wherein the report generation component takes data from the database population component.
  • FIG. 1 is a schematic illustrating the separation of physical and financial flows in a competitive electricity marketplace.
  • FIG. 2 is a schematic illustrating the participants in a competitive marketplace.
  • FIG. 3 is a schematic of a business model that implements the present invention according to a preferred embodiment of the present invention.
  • FIG. 4 is the home page display screen according to a preferred embodiment of the present invention.
  • FIGS. 5-19 are various display screens for the bid component according to a preferred embodiment of the present invention.
  • FIGS. 20-31 are various display screens for the contract component according to a preferred embodiment of the present invention.
  • FIGS. 32-40 are various display screens for the customer component according to a preferred embodiment of the present invention.
  • FIGS. 41-53 are various display screens for the power system component according to a preferred embodiment of the present invention.
  • FIGS. 54-59 are various display screens for the batch scheduler component according to a preferred embodiment of the present invention.
  • FIGS. 60-69 are various display screens associated with the settlement component according to a preferred embodiment of the present invention.
  • FIGS. 70-72 are various display screens associated with the bill component according to a preferred embodiment of the present invention.
  • FIGS. 73-76 are various display screens associated with the meter reading component according to a preferred embodiment of the present invention.
  • FIGS. 77-78 are schematics illustrating the technical architecture according to a preferred embodiment of the present invention.
  • FIGS. 79-82 are schematics illustrating various features of the application architecture according to a preferred embodiment of the present invention.
  • Facilitating, coordinating and managing the day-to-day operations of a competitive marketplace is a complex task. While the present invention will be described in the context of managing an electricity marketplace, the present invention is not limited to such a market and may be applied to manage other competitive markets, such as a natural gas market.
  • the facilitation, coordination and management of the day-to-day operation of the market are, for the most part, performed by a market operator and a system operator.
  • the market operator conducts an auction for energy and ancillary services, collects contracts and bids for energy and ancillary services and provides for the financial settlement of the markets, including billing and clearance for market trading.
  • the market is settled in hourly or even sub-hourly trading intervals and the market operator must collect, coordinate, and distribute a vast amount of market information.
  • the system operator takes information provided by the market operator and creates a dispatch schedule. The system operator uses the dispatch schedule to direct generators to operate their units accordingly.
  • the market operator is typically operating a spot market.
  • the spot market is the core of a competitive electricity marketplace.
  • the spot market is the mechanism responsible for setting the value of electricity or some ancillary service in an interval of time and facilitates the efficient operation of the physical power system.
  • the actual operation of the spot market will vary depending on the prevailing market rules and procedures. However, in a pool model, the context in which the present invention will be described, the market will typically operate as follows.
  • a bid In a pool model, generally, all producers generate into a common pool of energy and all customers take out of the same pool. Generators decide for themselves when they would like to commit their plant to generate electricity and bid each day for the opportunity to run their plant.
  • a bid consists of several bid blocks, including a price and a quantity for each trading interval of the day.
  • bids can be submitted for ancillary services such as energy reserve or capability.
  • the bid process can be generalized for any market service or commodity.
  • Bids may also be submitted by consumers of electricity. These demand-side bids of price and quantity represent the amount of load the consumer is willing to shed based on price. For example, a large industrial consumer may see economic benefits by reducing production levels at a large manufacturing plant if the spot price for electricity is high. Loads that bid their demand are often called dispatchable loads because the load is dispatched based on price. Additionally, customers submit other relevant forecasts about the characteristics and behavior of their units or dispatchable loads during the bidding process. Examples include high and low operating limits, the seasonal capability of units and scheduled maintenance outages.
  • the system operator addresses reliability concerns and often publishes a dispatch schedule that also takes into consideration additional information such as historical power system performance, weather forecasts, projected supply shortages, system maintenance and fuel costs, for example.
  • the system operator uses the schedule to direct generators to load their units accordingly.
  • the generator with the lowest price bid will be dispatched first, with each subsequent generator dispatched as required until supply matches demand.
  • Ancillary services are also designated as required to maintain real-time system reliability and stability.
  • the spot price, or clearing price is equal to the lowest possible price at which supply meets demand.
  • the spot price is determined “ex-post”, i.e., after the dispatch process.
  • the final clearing prices in the pool are determined by what actually happens on the trading day, not what was projected at the time the original schedule was published.
  • the spot price can be determined at the time the original schedule is published.
  • This pricing information is shared with the market operator for settlement purposes. More particularly, once bids have been submitted and the bid deadline has passed, the system operator performs a unit commitment process. Unit commitment involves taking all of the bids, stacking them from lowest price to highest price and determining an economic merit order that should be followed at the time of dispatch. For example, Table 1, shown below, illustrates a bid stack for hour 10 of the next day.
  • the day ahead of the trading day the system operator forecasts that for the next day the total system load for hour 10 will be 500 MWh based on historical data, the weather forecast, external contract sales to other power pools, etc. It can be seen from Table 1 that for supply to match demand, the 500th MWh will be provided by Unit B at a cost of $15. This forecasted clearing price allows customers to guess what their position might be in the market and hedge their risk with short-notice contracts, for example.
  • the system operator also publishes a schedule of economic merit order for the units. This commits Unit A to run 150 MWh, Unit B to run 300 MWh, and Unit C to run 50 MWh. In some markets, this day ahead clearing price is used to settle the market.
  • the system operator determines that the real-time load is actually 600 MWh instead of 500 MWh. Perhaps there are more people running their air conditioner than this time last year or, perhaps, Gen Unit C has been shut down for emergency maintenance. This means that the system operator orders Gen Unit A to provide 150 MWh, and Gen Unit B 450 MWh.
  • the actual load sets the clearing price at $20/MWh since the most expensive MWh was provided by Gen Unit B at its bid of $20/MWh. In most markets, this is the clearing price used for market settlement. It reflects the actual cost of the market service during the actual trading interval. While a particular example has been set forth, the clearing price may be determined either before or after the actual dispatch of the units, depending on the market rules. In either case, the price is used by the market operator in the settlement process to determine charges and payments as will be described hereinafter.
  • Clearing prices for each trading interval can be extremely volatile.
  • customers in a market may create contracts for the purchase or sale of a market service to or from other customers or from an external source such as a neighboring control area.
  • contracts are negotiated bilaterally between customers, a great deal of the contract information is captured by the system operator for scheduling and by the market operator for use in settlement of the marketplace.
  • these contracts can be for assets that transfer a percentage of a unit or load to another customer, or they can be system contracts that are simply a quantity of electricity or other market service.
  • PDCs pre-determined conditions
  • the PDCs can be based on a unit's availability or actual performance of a generating unit, or it can be based on the scheduled or available quantity of another contract. Contracts can also be dispatchable based on clearing price, thus taking on a different percentage or value depending on the clearing price. Each percentage and clearing price or value and clearing price pair is known as a contract block.
  • generating unit #1 is dispatched at 100 MWh.
  • the clearing price for that trading interval is also determined to be $15/MWh. If the contract were not active (i.e. generating unit #1 was only used for 10 MWh), Customer A would be entitled to the entire MWh output of generating unit #1 times the clearing price (e.g. $1500). However, the contract is active, so Customer A only retains 50% entitlement on generating unit #1 and Customer B retains the other 50%.
  • the market operator determines during settlement that the contract is worth 50 MWh (i.e., 50% of generating unit A), so Customer A receives a $750 payment and Customer B receives a $750 payment.
  • customers submit meter readings for the unit, loads, and tie lines for which they are the responsible party.
  • the system operator also shares meter data, bid re-declarations, pricing, contract schedules, reserve designations, ancillary service requirements, and other data with the market operator.
  • the market operator acts as the central clearing house for the information associated with the actual operation of the marketplace on the trading day.
  • the marketplace is settled.
  • everyone providing energy or ancillary services has to be paid, and everyone consuming has to be charged.
  • the market operator uses the information about the operation of the power system and pricing information to determine charges and payments on an asset by asset or customer by customer basis. The results of this financial settlement are then made available to the marketplace customers.
  • invoice information may be preferably shared with financial systems external to the market operator. These external financial systems may include invoicing systems, general ledgers, and electronic fund transfer software.
  • the present invention preferably employs a secure, Java-based, distributed component or object application which runs on an architecture composed of servers supported by a relational database, Java just-in-time compilers, and an object-request broker (ORB).
  • ORB object-request broker
  • the present invention is partially implemented utilizing a set of distributed components deployed in a multi-tiered network-centric architecture collectively providing the services needed to effectively facilitate, coordinate and manage a competitive marketplace preferably via the Internet.
  • the description of the system can be broken down by its business components, technical architecture, and application architecture.
  • the market operator provides a full set of business components to facilitate bidding, contract management, meter-reading submission, market settlement, and billing in addition to managing an enterprise wide solution to customer information and power system modeling. These functions are scalable, easily interfaced to other systems, designed to be highly reliable and secure, and constructed with the data and audit needs of the customer in mind.
  • An object-oriented design approach which utilizes object-based techniques such as inheritance, encapsulation and polymorphism is used to make the application flexible. Thus, new classes can be rapidly designed or modified if new market rules and procedures dictate the need.
  • the object-oriented design also uses standard messages and methods so that components can be added or removed from the application with minimal change to existing components.
  • FIG. 3 is a schematic of a business model 200 that implements the present invention and includes major component-to-component interactions, interfaces, and links to customers as well as other software packages.
  • the key components include a customer component 202 , a bid component 204 , a contract component 206 , a meter reading component 208 , a settlement component 210 , a billing component 212 , and a power system component 214 .
  • the business model 200 shown in FIG. 3 is a generalized model and may be different depending upon the market operator's scope of responsibility. For example, pricing may or may not be integrated into the market function, but might instead be part of the system operator function (not shown). The exact dynamics of the market operator will vary for each implementation.
  • a component-based object-oriented system In response to this need for an integrated, dynamic, and robust market operator capability, a component-based object-oriented system has been developed that provides the core functions required to coordinate and facilitate the market activities of customers in a competitive marketplace.
  • the settlement component 210 receives information from the power system component 214 , customer component 202 , bid component 204 , meter reading component 208 and contract component 206 . In addition, it receives scheduling, pricing and dispatch information 216 from the system operator through an interface module 218 .
  • the bill component 212 receives information from the customer component 202 and settlement component 210 and outputs information to external financial systems 220 through an interface 222 . These external financial systems 220 may include invoicing systems, general ledgers and electronic fund transfer software.
  • the bill component 212 also outputs information to customers 224 through an invoice interface 226 .
  • the bid, meter reading and contract components receive information from customers 224 preferably through a graphical user interface 228 .
  • the power system and customer components 202 and 214 receive information from customers 230 through graphical user interface 232 .
  • Customers 230 are preferably internal to the market operator.
  • the power system component 214 represents a network model of the physical power system, including the generating units, load facilities, transmission lines (tie lines), network nodes and network areas. It is adaptable to multiple pricing and/or bidding zones and maintains generation characteristics including operating limits, ramp rates, and black start capability.
  • the customer component 202 manages all information about entities that have a business relationship with the market operator. It retains data on customers, including market eligibility, equity ownership in generation and load, contact information, bidding responsibilities, and meter-reading responsibilities.
  • the bid component 204 enables customers to submit, view, modify, and validate bids via a graphical user interface or through a bulk file upload facility. It applies physical limit checks on bid offers for each generator and allows for bidding through multiple price-quantity bands, potentially different for each trading interval. It provides for varied types of energy bids including support for fuel constrained and self-scheduled generation and accepts updates during the open bidding period to accommodate changes in generating unit or dispatchable load characteristics. It contains user interfaces to allow the market operator to vary bid submission deadlines. It maintains information about customer offers to provide market services such as energy, ancillary services, or capability service and provides a full audit log, including user access information to facilitate statistical analysis on bidding practices.
  • the meter reading component 208 stores meter readings submitted by customers for all metered generation, load, and tie flows and allows for validated bulk meter reading submission. It offers helper functions that allow customers to enter information quickly and efficiently and identifies missing or incomplete metering data.
  • the contract component 206 allows for the creation of contracts and accepts contracts for a wide range of market offerings (energy, ancillary services, etc.) and contract definitions (system, asset-specific, etc.). It offers user-friendly web interfaces for placing transactions into the system and a file upload mechanism for high-volume users, all with real-time validation. It provides the facility to submit a contract schedule, slicing the contract into several price bands with each band evaluated separately against the market clearing price, and it determines contract activity based upon conditions to be evaluated post-dispatch, such as unit availability or physical contract activity.
  • the settlement component 210 manages the financial settlement of all markets based upon meter-readings, operational information, bids, contracts, and clearing prices. It determines clearing prices through economic stacking of bids as previously described. It performs reconciliation to account for accurate, month-end metering data. It contains an extensive versioning mechanism that allows for the re-settlement of any given period based on new or changed input data.
  • the bill component 212 summarizes the financial activity for each customer on an invoice for the service provided or received. It performs differential billing for trading intervals re-settled with corrected input data but previously billed on a historical invoice. It provides for flexible bill processing periods. It can be supplied with an interface to enter manual line items such as registration fees or special charges and interfaces with third party systems, such as tariff billing systems. It preferably communicates with third party accounting software to provide general ledger and activity accounting updates.
  • the market information server is a data warehousing tool designed to service a variety of internal and external customer informational needs.
  • the heart of the market information server is a database which acts as a central repository for data elements from a variety of informational sources within the market operator.
  • the market information server associates transactional input, such as bids, contracts, and metering data, with market activity data, such as clearing prices and generator operational flags.
  • the market information server then ties this set of information to each market customer's individual settlement.
  • market information server reporting tools on the data warehouse reports are created and distributed to each customer according to security level. Additionally, high level studies and drill-down details for internal market operator functions such as market administration, market power monitoring, auditing, and billing are easily performed on the same data set.
  • the market information server application is composed of two independent components: database population component and report generation component.
  • the database population component performs all of the data gathering steps and runs periodically, either through a batch process or through special-case market operator user execution. With each execution of the database population component, the data is re-organized from many different sources, each tailored to their respective applications, into a common repository design to suit customers' needs. After this stage, the report generation component is called upon whenever a user requires a pre-defined report.
  • third party tools may be used for ad-hoc queries.
  • Customer's interaction with the market operator is based on a transactional system: individual customers' browsers connect with the market operator and the customers enter bids for the output of their generators and for ancillary services as well as bilateral contracts. Additionally, metering parties submit generation, consumption, and tie flow values used in the determination of market settlement.
  • the nature of transactional data is fragmented in that data enters the system through the course of each day.
  • the market information server selects data elements which have financial implication to each trading interval settlement, collects them, and updates the market information data warehouse. For example, only final metering data is selected for retention even though multiple meter submittals had been performed for the same asset during the same trading interval.
  • Operational information from the system operator is also gathered into the market information database.
  • This data while also transactional, has the added characteristic of being time critical. Whereas market operator transactions are correlated post-dispatch, operation data is collected and reported in near real-time. Near real-time reporting is achieved by polling the system operator's energy management system several times per hour and making the information received from this query available to users with access rights to review it.
  • This data set includes, but is not limited to, instantaneous clearing prices, generator operational flags, and pool reserve designations. While quantities may be overridden by market administrators during the settlement process, this information provides timely feedback to those customers directly affected by the dispatch characteristics.
  • the third source of information for the market information server is the market operator's settlement database.
  • the market operator provides performance information for each customer and, ultimately, billing data. With this data selected and correlated to the transactional and operational data, a complete snapshot of each trading interval's activity is created.
  • the market information data warehouse generates reports designed with customer requirements, rather than specific application requirements, in mind.
  • the table structures are constructed such that customers and asset information are easily tied to each market. This design serves three major purposes: fast querying capability, multiple delivery options, and report writing flexibility.
  • Data warehousing enables fast database access which facilitates reporting the data itself.
  • High speed report creation becomes increasingly more important as energy markets become more open and more customers actively query the system.
  • the sheer number of data elements for each trading interval coupled with the volume of customers making informational requests may result in a system that is burdened with preparing data sets on the order of Gigabytes per day. Rapid turn-around of these requests, especially if an on-line request-based method is used, is a key to the market information server's potential success.
  • a variety of methods may be chosen for publication of the data.
  • data may be posted directly to the Internet. Again using third party Web reporting tools, trend analyses such as clearing price history, can be shown right on the Web with only minor additional effort.
  • trend analyses such as clearing price history
  • a special list of customers that are enabled to view the data would be created and the market operator may opt to make these reports available either through a secure Web server or through a traditional file transfer protocol server.
  • the market information server application has a built-in architecture used to create standard comma delimited files, along with error handling and file maintenance tracking tools. To facilitate users who choose the spreadsheet import method, templates are created for the customer to download and use.
  • Another strength of the market information server is its ability to empower internal market operator staff with the ability to easily create ad-hoc reports.
  • Market administrators will choose to create very detailed reports for a given trading interval in order to perform check-and-balance type operations.
  • Market monitors will tend to create detailed reports as well, but on the customer or asset level to study trends in bidding, metering, and contract writing.
  • Auditors and billing staff will run summary type reports which aggregate many customers and many trading intervals over monthly or annual time frames. Regardless of the type of report designed, the time between report design request and report delivery is shortened because of the data warehouse.
  • FIG. 4 illustrates the home page 300 as seen in Netscape browser on a customer's graphical user interface.
  • the components shown in FIG. 3 and discussed above, as well as some additional components are displayed.
  • the user can access a component by selecting the desired component with a device such as a mouse or a key stroke, for example.
  • the bid component 204 preferably provides the bidding capabilities required for a supply-side auction of energy services.
  • the bid component provides many primary services which will be described below.
  • the bid component enables customers to submit, view, modify and validate bid and resource characteristics via an effective graphical user interface or bulk file upload for a plurality of market services such as energy, automatic generation control (AGC), ten minute spinning and non spinning reserve, thirty minute operating reserve, installed capability and operable capability.
  • AGC automatic generation control
  • FIG. 5 is a display screen for the bid component according to a preferred embodiment of the present invention that can be displayed on a customer's workstation. As can be seen at the top of the screen, tabs 501 are provided that allow the user to display various screens of the bid component.
  • the screen shown in FIG. 5 is the bid information tab.
  • the bid information screen provides information to the user concerning submission deadlines and date ranges for bid entries. The user can also perform a search for a particular customer by entering either a customer name or identification number on the right side of the screen.
  • FIG. 6 is a display screen of the energy tab of the bid component according to a preferred embodiment of the present invention. From this screen, the customer can begin the bidding process. On the left side of the screen a start screen is displayed where the customer can enter bidding information as shown. In this particular example, a new bid is to be created from scratch for the Avalanche Gas unit. After the customer has entered the requested information, the “Next” radio button is activated and a helper screen as well as a bidding grid of the energy panel is displayed as shown in FIG. 7 . From this screen the customer can enter information as to the parameters of the bid. The bidding grid on the right side of the screen will be filled with the parameters the customer selects.
  • Energy bids preferably consist of blocks of price and MW amount for each trading interval within a scheduled dispatch period. Energy bids may also contains a self-scheduled MW amount 701 , a high operating limit 702 , and a low operating limit 703 for each trading interval. As seen in FIG. 7 , the scheduled dispatch periods are listed and the user can enter the amount and price for each trading interval either directly in the grid or by using the helper. Once the bidding information is entered, the customer can submit, clear or reset the bid information. After the customer submits the bid a confirmation screen is displayed on the customer's work station as shown in FIG. 8 indicating confirmation of the bid. In a preferred embodiment, the customer is notified of the date and the time that the bid was accepted, its effective date and unit name.
  • FIG. 9 illustrates the display screen for the AGC market. Again, a start panel is displayed on the left side of the screen so that the customer can enter information. This information is submitted by activating the “Next” radio button which then displays the screen shown in FIG. 10 . On the left side of the screen is a helper panel that prompts the customer for bid information. In this particular example, the bid price has been selected at $22 per hour as shown on the right side of the display.
  • the customer is also able to edit the characteristics of the unit by selecting the “Edit AGC Characteristics” tab 1001 at the bottom of the right side of the display.
  • FIG. 11 illustrates the “Edit AGC Characteristics” panel. Again, a helper panel on the left side of the screen allows the customer to enter data quickly, if desired, otherwise the customer can enter information directly on the right side of the display.
  • FIGS. 12-15 illustrate the display screens for the other market services, i.e., reserve and capability, and are similar to those already described and thus need not be described in further detail.
  • FIG. 16 illustrates the resource characteristics panel of the bid component.
  • the customer has selected to edit the characteristics of an existing unit, the Avalanche Gas unit.
  • the display screen shown in FIG. 17 is displayed and from that screen the customer can change existing parameters such as minimum run time, minimum shutdown time, etc.
  • various tabs will be enabled or disabled.
  • the maintenance tab of the bid component is preferably enabled only for market operator internal users, i.e., customers that make up the market operator.
  • FIG. 18 illustrates the maintenance tab of the bid component. From this screen, the market operator can edit existing parameters or enter new parameters. In this example, the market operator chooses to edit existing parameters.
  • the display screen shown in FIG. 19 is displayed. As can be seen, the market operator can edit various parameters, that control the bidding process such as bid submission deadlines and the number of bids that can be entered in advance.
  • the bid component allows customers to enter bids up to a daily trading deadline applicable for the market. In addition, it also allows customers to enter bids up to a predefined number of days in advance and allows customers to create a new bid using an existing bid for a day up to a predefined number of days prior. Furthermore, the bid component provides the market operator the ability to enter bids on behalf of customers. This provides a contingency measure if customers experience communication or hardware problems.
  • the bid component records the bid entry type for each bid submitted.
  • the bid entry types include bids entered by customer, default bids generated by the bid component and bids entered for the customer by the market operator.
  • the bid component is also responsible for creating default bids for each market service other than operable capability and installed capability. For each active unit without a bid submitted for the scheduled dispatch period, a default bid is created. The default bid is a replica of a bid from a previous scheduled dispatch period bid for that unit. If an active unit exists in the market but a bid for the previous scheduled dispatch period does not (i.e., a new customer has not submitted a valid bid) then an ERROR is logged and no default bid is created.
  • Bids can be either on a customer by customer basis or an asset by asset basis, depending on the prevailing business rules.
  • the bid component itself is not limited in any way to a fixed number or type of market services, and the bids need not be only for electricity or ancillary services.
  • the bid component could readily accommodate bidding for natural gas or some other commodity.
  • the bid component could also incorporate demand-side bidding, giving the bid component complete bidding capability for any commodity auction. From any screen the customer can select a component either from the icons located at the bottom of the screen that are always displayed or by returning to the home page shown in FIG. 4 .
  • the contract component 206 supports the ability to create various contracts including external system, external unit, internal system, internal assets and internal obligation contracts.
  • the contract component enables a customer, an agent for the customer or the market operator to submit contracts via a bulk upload facility.
  • FIG. 20 illustrates the beginning screen of the contract component where the customer selects the contract type, market service and duration of the contact as shown. After that information is entered, a general information panel is displayed on the right side of the screen as shown in FIG. 21 . The general information screen indicates the parties to the contract and identification information. The customer can view details of a contract by selecting the “Details” tab at the bottom of the right side of the display.
  • FIG. 22 is a display screen of the details panel.
  • FIG. 23 is a display screen of the predetermined conditions panel. It can be seen from FIG. 23 that the unit's availability is a predetermined condition of the example contract.
  • the customer submits the contract by activating the “Submit” radio button and a confirmation screen as shown in FIG. 24 is displayed confirming that the contract was received as well as particular parameters of the contract.
  • the contract illustrated in FIGS. 21-24 was for an internal contract type. Next, an external contract type will be described with reference to FIGS. 25-28 .
  • FIG. 25 illustrates a display screen for entering contract information for an external contract.
  • FIG. 25 illustrates a display screen for entering contract information for an external contract.
  • FIG. 26 illustrates the “General Info” tab for the external contract and indicates the parties to the contract as well as identification information.
  • FIG. 27 illustrates the details panel for the external contract where the customer can enter the contract information either directly on the right side of the screen or through the helper panel on the left side of the screen. In the particular example shown, the customer has contracted for 50 MW. The customer activates the “Fill” radio button and, as shown in FIG. 28 , that information is filled on the right side of the screen. The customer can also view whether there are any predetermined conditions associated with the external contract by selecting the “Pre-Determined Cond” tab.
  • FIG. 29 is a display screen of the predetermined conditions panel. The customer can also search for existing contract information through the search panel on the left side of the display as shown in FIG. 30 .
  • FIG. 31 is a display of the results of the search.
  • FIGS. 32-40 illustrate display screens associated with the customer component.
  • FIG. 32 illustrates a display screen showing general information for an existing customer. As shown, a search was entered for customer names that begin with the letter “C”. The Cadillac Generator Company was retrieved and on the right side of the screen, information concerning the Cadillac Generator Company is displayed. In particular, the type of customer, its status in the pool and its settlement status are displayed. Additional information concerning a customer can be viewed by selecting a tab 3201 from the bottom of the right side of the display.
  • FIGS. 33-40 show the various display screens, that can be viewed.
  • These display screens provide information concerning a customer's address, contact information, DUNS information, any related information, asset information, governance information and user profile which dictates what rights the customer has to view or modify particular information, and agent maintenance information.
  • the customer component is preferably accessible only by market operator internal users, i.e., the market operator.
  • the power system component 214 maintains the model of the power system as it exists for physical and financial market settlement.
  • the power system includes three primary elements: assets (generating units, loads, and tie lines), network nodes (a grouping of assets), and network areas (a grouping of network nodes).
  • assets generating units, loads, and tie lines
  • network nodes a grouping of assets
  • network areas a grouping of network nodes.
  • the power system component entitles the entry and maintenance of generating unit, load facility, tie line, network node, network area characteristics. These characteristics describe various aspects of each element.
  • the power system component 214 enables the entry and maintenance of asset data and the relationships between assets.
  • FIGS. 41-53 illustrate the display screens associated with the power system component. Preferably only market operator internal users have access to this component.
  • the customer can select display screens for the network area, network node, generating unit, load facility and tie line.
  • FIG. 41 is a display screen of search results for a network area. As can be seen on the right side of the screen, the network nodes that are inside and outside the network area are displayed.
  • FIG. 42 is a display screen for an existing network node indicating the network areas associated with that node.
  • FIGS. 43-45 are display screens of the generating units, load facility and the tie lines associated with the node, respectively.
  • FIGS. 46-49 are display screens indicating information concerning a generating unit. The screens are self explanatory and thus need not be described in greater detail.
  • FIGS. 50-53 are display screens associated with a load facility and tie line respectively. Thus, through the power system component, the entire marketplace is modeled.
  • the batch scheduler 201 provides a mechanism for the submission of batch jobs, and the prioritization of batch job submissions.
  • the initiation of batch jobs according to the prioritization is supplied by a commercially available tool. It also provides the ability to submit dynamic parameters for a batch job and provides the ability to support unique billing functionality involving the submission of bill parameters. In addition, it provides a facility to view the status of batch jobs submitted through the batch schedule user interface.
  • a batch scheduler tool such as Maestro which initiates the jobs as scheduled.
  • FIGS. 54-59 illustrate display screens associated with the batch scheduler component.
  • FIG. 54 is a general display screen from which a customer, preferably an market operator internal user, can select a batch job such as settling an hourly market for the energy market, as shown.
  • FIGS. 55-56 are display screens for selecting other batch jobs such as printing an invoice or calculating voting shares, respectively.
  • FIGS. 57-58 are display screens for the billing panel. As can be seen, the customer can select to process bills or roll back bills.
  • FIG. 59 illustrates the log panel where the status of each selected batch job can be viewed.
  • FIGS. 60-69 are display screens associated with the settlement component.
  • FIGS. 60-61 are display screens that indicate the clearing price for the energy and AGC markets respectively for a particular interval. The customer can update information if necessary.
  • FIGS. 62-69 are display screens where various settlement parameters can be viewed and updated as is clear from the display screens.
  • the settlement component 210 is responsible for the physical and financial settlement of all the hourly and monthly markets. In addition, the settlement component is responsible for the monthly meter adjustment settlement for meter reading. Various settlement-related parameters can be entered through the user interface and file upload services of the settlement component.
  • the settlement component highlights any data that was identified as having validation or availability problems in any trading interval and confirms that data necessary to complete settlement for a trading interval is available including, meter readings (MWh energy readings) and clearing prices (for each market service).
  • the settlement component supports the ability to accept the different types of administered price including data correction and market suspension which will override the clearing price for a specific market service and trading interval.
  • FIGS. 70-72 are display screens associated with the bill component.
  • the bill component 212 provides flexible bill processing so that each billed service can be billed for a distinct bill period.
  • the market operator has the ability to disable the bill process for one or more billed services, to update the end date of the bill period for each billed service (the system will generate the next bill period begin date based on updates), and to roll back a bill period for a billed service.
  • the bill component allows the initiation of bill processing by manually triggering a batch calendar event which will be described hereinafter.
  • the bill component provides a mechanism for the entry and maintenance of balanced and unbalanced adjustments to a customer's bills through a user interface or a file upload.
  • the following information may be captured: customer identifier, the amount of the debit/credit per customer, the reason for the adjustment and a description of adjustment, for example.
  • FIG. 70 illustrates the adjustment tab of the bill component. As can be seen from FIG. 70 , the type of adjustment made and the reason for the adjustment is captured.
  • the bill component provides a mechanism to view a summarization of all bills processed. All calculated summary line item and net amount totals will be saved to a database so that external reports can be produced.
  • FIG. 71 illustrates the market system details tab of bill component which displays summary information for each customer, including their net position in each market for the selected bill period and accounts payable and receivable.
  • FIG. 72 illustrates a display screen accessed by the customer invoice tab.
  • the customer invoice display uses a collapsible tree structure with each child node of the tree structure representing more and more details about a customer.
  • the bill component is also responsible for preparing an invoice for each customer.
  • the bill component initiates invoice printing by manually triggering a batch calendar event. It also formats a file that includes all information to be printed on the invoice.
  • the bill component creates statements that are payable to the customer and market operator.
  • the bill component preferably creates a flat file to provide information to format a summary report.
  • FIG. 73-76 are display screens associated with the meter reading component.
  • FIGS. 73-74 are directed to hourly meter reading data and
  • FIGS. 75-76 are directed to monthly meter reading data.
  • the hourly or monthly meter readings for a particular asset can be entered via these display screens by customers that are responsible for meter reading.
  • the overall technical architecture provides a flexible system that is easily and economically adaptable to changing environments.
  • the technical architecture is designed to provide the system with several important benefits. These include a fault tolerant server/LAN combination, redundant communication interfaces, multiple distributed user interfaces, and archival storage media to ensure high system reliability as well as a plan for survivability in the event of a failure.
  • the system is composed of a robust, highly secure network infrastructure and scaleable components to allow it to easily meet expected market operator transaction volume demands and to economically adapt to future ones.
  • FIGS. 77-78 illustrate the major physical components of the system's technical architecture. With reference to FIG.
  • the system's architecture 100 preferably includes a plurality of external customer workstations 102 , of which only one is shown, a Web server 104 , an authentication token server/firewall 106 , at least one market operator internal user workstation 108 , preferably utilized by the market operator, at least one developer workstation 110 and at least one application server 112 .
  • the external user workstations 102 are coupled to the Web server 104 via the Internet 114 .
  • the Web server 104 communicates with the application server 112 , internal user workstation 108 and developer workstation 110 over an Intranet 116 , preferably a LAN, although other structures can be used.
  • the system shares key information and resources among many users throughout different organizations. Therefore, the ability of the system's network infrastructure to prevent unauthorized access to information is important.
  • the system preferably employs a multi-tier network security architecture.
  • each customer, external and internal, as well as the developer workstation have both a challenge token used to reveal a ‘challenge’ password based upon personal login information as well as an industry standard digital certificate, a unique digital signature issued and managed by the market operator itself.
  • Challenge routers authenticate only customers who have valid credentials, consisting of the access code along with a digital certificate installed on the customer's workstation, thereby protecting sensitive resources and information attached to an Internet network from unauthorized access.
  • Proxy services mediate traffic between the protected network and the Internet by establishing a screening server address, shielding outsiders from knowing (and later targeting) the specific addresses of servers within the private network. This level of security is totally transparent to the customer with the exception of needing to use a security card at the beginning of each session.
  • the external customers 102 , market operator internal users 108 and developer workstations 110 are all equipped with Web browsers.
  • components of the system can be automatically loaded into the web browser of the customer's workstation 102 .
  • customers need not coordinate to update their software packages when enhanced versions of the application are released.
  • new software to accommodate updated market rules or procedures is simple to release.
  • Data is entered in and validated though graphical user interfaces at the workstations, while the transactions are entered in a database maintained by the application server 112 .
  • Customers internal to the system access the system in the same way as external customers, however additional functions are enabled as menu options as previously described.
  • market operator internal users can initiate a settlement process or update a customer's information, for example, whereas external customers would preferably not be provided with this capability. Developers utilize Java development tools to maintain and enhance the architecture and application as necessary.
  • FIG. 78 illustrates a typical hardware configuration implementing a portion of the architecture shown in FIG. 77 .
  • the application servers 112 are DEC 8400 Alpha servers on which Oracle's Version 8 Relational Database Management System runs in parallel mode to provide access to the database and maintain its integrity.
  • the entire system communicates using TCP/IP, messaging protocol. As the principle method for transmitting data over the Internet today, this protocol is responsible for ensuring that data packets sent over the network arrive at the destination and are properly sequenced.
  • HTTPS Secure Hypertext Transfer Protocol
  • ORB Object Request Broker
  • IIOP Internet Inter-ORB Protocol
  • CORBA Common Object Request Broker Architecture
  • Services provided by the application architecture are: presentation services, information services, communication services, environment services, transaction services and business logic.
  • the implementation of application architecture services is delivered using a network-centric architecture framework.
  • the net-centric architecture framework is a common architecture that supports multiple electronic access channels to disparate sources of information reachable by customers using technologies that employ open, commonly accepted standards.
  • FIG. 79 illustrates an example of the application architecture services according to a preferred embodiment of the present invention.
  • the communication fabric and web services are considered part of the technical architecture.
  • the presentation services enable the application to manage the human-computer interface. This includes capturing user actions and generating resulting events, presenting data to the user, and assisting in the management of the dialog flow of processing.
  • the major presentation services include a window system, a desktop manager, a web browser, and an input device.
  • FIG. 80 illustrates the basic user interface design.
  • the user interface is divided into three hypertext markup language (HTML) frames.
  • the top frame 602 contains a header applet, the middle, “main” frame 604 contains the main user interface applet, where component applets are displayed.
  • the main frame 606 also contains a JavaScript function which can be invoked by the applets from the other frames.
  • the bottom frame contains the MainMenu user interface applet which contains a menu to select a component to be displayed in the main user interface.
  • FIG. 5 shows the application of this framework to the bid component user interface.
  • the user interface is preferably constructed using the Abstract Windowing Toolkit (AWT) available from Java 1.1.
  • Applets are preferably constructed from core AWT classes (e.g. Canvas, Panel, and Label) as well as third party products (e.g., Tab Panel from Symantec) where necessary.
  • AKT Abstract Windowing Toolkit
  • Applets are preferably constructed from core AWT classes (e.g. Canvas, Panel, and Label) as well as third party products (e.g., Tab Panel from Symantec) where necessary.
  • AKT Abstract Windowing Toolkit
  • Netscape's 4.5 web browser is used on the workstations. All functional areas are accessed through the web browser, however, Microsoft's Internet Explorer may be used. Some Netscape specific pieces related to security and software delivery would have to be altered before a full production deployment on Internet Explorer is possible.
  • the presentation layer is separated from the business logic and validation by the user interface/activity framework implementation.
  • the user interface layer captures and handles the user-initiated events and displays the results of the event.
  • the activity layer is responsible for validating the user's input and invoking services on the business components to process the transactions. That is, services to read data from a user interface and translate them into their corresponding data types and then validate the data types are handled by the user interface/activity framework implementation.
  • the graphical user interface such as that shown in FIG. 7 , demonstrates many of the common user interface features of a component. As described above, the user is able to access the desired grouping of information using a tab panel metaphor. By clicking a tab, the user is shown a panel designed for the input and display of information related to the component.
  • each panel of the user interface may contain any number of graphical user interface components or “widgets” such as editable text fields, list boxes, tables, sliders, combo boxes, and date spinners.
  • Each graphic user interface component can capture events such as a click or key press and initiate some activity within the user interface's corresponding activity class. The activity is responsible for interpreting the event and initiating the correct business logic or validation.
  • Information services manages information assets and enables the application to access and manipulate data from documents, databases or other external data sources stored locally or remotely. It minimizes an application's dependence on physical storage and location within a network.
  • the primary storage services utilized in the present invention is provided by Oracle's Version 8.0 Relational Database Management System (RDBMS) resident on an application server. All persistent data is stored in relational tables within Oracle.
  • RDBMS Relational Database Management System
  • Oracle provides data security and access services for database administration personnel. Database user accounts are protected with a password, and data/table access is governed by access rights established by database administration personnel.
  • FIG. 81 illustrates a schematic of a portion of the application architecture according to a preferred embodiment of the present invention.
  • Oracle's Java Database Connectivity (JDBC) ThinDriver provides the Java-based application program interface needed to access the database from within the system. All common database transaction services are accessed through the JDBC. Since JDBC is independent of the particular database management system, the system has the added benefit of being isolated from the particular database implementation.
  • the application architecture also provides a layer of separation from the JDBC API with the Persistence framework. This framework provides mapping from an object-oriented implementation to a relational database model, as well as services for generating SQL statements.
  • Communication services enable an application to transparently interact with other applications regardless of whether they reside on the same computer or on a remote computer.
  • the application architecture preferably implements a version of the “Proxy-Skeleton” pattern. This pattern defines two objects to act as the communication handlers between components.
  • FIG. 82 illustrates component interaction overview.
  • a Proxy is a version of the interface that exists in the client's space. This object has a method for each service on the interface that the component wishes to be public.
  • a Skeleton is what a proxy communicates with.
  • a Proxy sends a message across the ORB which is captured by a Skeleton. The Skeleton then forwards the message on to the component.
  • the system also provides customers the ability to upload files from their workstations.
  • File upload services provide an alternative to entering information through a component's user interface.
  • component's user interfaces are implemented using applets. Since there are security restrictions imposed on downloaded applets by the browser, it is necessary to implement the Netscape Capabilities application program interfaces (APIs) to upload files. This requires the following: (1) all applets needing access to client files will be signed with a digital signature; (2) applets will utilize the Netscape Capabilities APIs to grant read privileges on the client hard drive; and (3) customers will be given a digital signing certificate and, using Netscape Security, file read permissions will be granted to the certificate.
  • APIs application program interfaces
  • a VeriSign class 3 object signing digital id is preferably used. All applets that will be downloaded to client workstations are packaged in a “.jar” file and signed with this digital id.
  • Netscape Capabilities API's need to be installed on the web server to support object signing security.
  • the SecurityManager class is used to grant file read permissions within applet code.
  • all customers are provided with a digital signature so that the identity of downloaded applets can be verified.
  • ORB is the foundation for a distributed component solution. At its most basic level, an ORB is used to enable components to communicate with each other regardless of physical location, operating system, and programming language. ORB vendors implement these services using the Common Object Request Broker Architecture (CORBA) as defined by the Object Management Group (OMG). In a preferred embodiment, Inprise's Visibroker ORB product is used.
  • CORBA Common Object Request Broker Architecture
  • OMG Object Management Group
  • the application needs to work within Java's security standards.
  • One of these security standards is that a customer can only establish and accept network connections from the host that served the applet. This is known as the Java Sandbox.
  • the application architecture uses Visigenic's Gatekeeper product.
  • the Gatekeeper acts as an initial point of connection for all requests.
  • the Gatekeeper knows where to forward requests.
  • application components can be distributed without regard to Java Sandbox security restrictions.
  • the Gatekeeper is enhanced with Inprise's SSL Pack. This enables the gatekeeper to encrypt communications between clients and the gatekeeper using the Secured Socket Layer protocol. By using the SSL Pack, all encryption logic is encapsulated and hidden away from the application architecture.
  • the environment services provide miscellaneous application and system level services that do not deal directly with managing the user-interface, communicating with other programs, or accessing data. These services are divided into operating system services, runtime services, system services, application services, component framework services, batch scheduling services, and report distribution services which need not be described herein.
  • the system requires a batch architecture as previously described that will support both manual and automated execution of batch processes.
  • the system's batch architecture is preferably comprised of the following products/objects: “Maestro Batch Scheduler, a third party batch scheduler used for the automated kickoff of batch processes according to predefined timetables”; Batch Driver, a Java executable that acts as the interface between Maestro and the batch scheduler component. The driver connects to the batch scheduler component and calls an operation on the component to execute a batch job.
  • the environment services also includes Java's Virtual Machine (JVM) which translates Java bytecodes into machine language commands.
  • JVM Java's Virtual Machine
  • Java code is compiled from Java syntax into Java bytecode.
  • Bytecode is a protocol that JVM's read at runtime.
  • the JVM translates bytecode at runtime into machine specific commands.
  • DEC's JVM for the DEC application servers, Sun's JVM for Windows NT for the NT server, Sun's JVM for Solaris for the web servers, and Netscape's JVM for the customers.
  • the transaction services provide the transaction integrity mechanism for the application. This allows all data activities within a single business event to be grouped as a single, logical unit of work. These transaction managers provide sharing of server processes across a large community of customers and can be more efficient than the DBMS.
  • Key transaction services include: transaction monitor services, resource management services, transaction management services and transaction partitioning services.
  • a transaction (or unit of work) is a collection of steps that accomplish a particular business function, such as creating a new customer or settling a market.
  • An object-based application is comprised of smaller, more cohesive modules (objects) than procedural-based applications. While this makes for better software characteristics, it makes the job of transaction management more difficult.
  • a transaction management framework for an object-based application should be able to manage multiple transactions, each associated with one to many objects. Each transaction should manage the state of the objects in its domain whether they are new, persisted, changed, or deleted. Finally, the transaction management framework should isolate the functional developer from the technical details of the framework.
  • the business logic provides the expression of business rules and procedures (e.g., the steps and rules that govern how a sales order is fulfilled).
  • the business logic includes the control structure that specifies the flow for processing business events and user requests.
  • rules based e.g., object-oriented, component, structured programming, etc.
  • object-oriented architectures like traditional architectures, use layering to isolate different types of functionality. This simplifies the development environment by shielding complexity, enabling reuse, and sustaining greater consistency, i.e., separation of concern.
  • a common way to separate the concern of the application is to separate the user interface from the business logic.
  • a user interface object is used to capture user events, translate them into business messages, and trigger changes to the interface itself. Any business messages that the interface objects needs to send are directed towards its activity object.
  • the activity object models a business unit of work. It exists on a client machine near the user interface objects, captures messages from interface and other activity objects, and either processes those messages or delegates the responsibility to the business components. This “separation of concern” allows the business logic (activity) to be separated from the presentation (user interface, file upload), which enables the reuse of business logic across multiple electronic access channels.
  • a component In the context of object-oriented programming and distributed object technology, a component is a reusable software building block that can interact with other components on the same computer or a distributed network of computers to form a complete application.
  • a component encapsulates all of the data and behavior associated with a business entity or process. Its public attributes and behaviors are accessible to other components in the federated network. Components are much like large-grained objects. They share many of features of traditional objects, but on a larger scale. Objects are the basis of object-oriented technology.
  • the business objects (instances of classes) and components of the system encapsulate the business logic specific to a given implementation of the system; in this case, the rules and procedures of a particular electricity marketplace.
  • a component or object effectively hides the details of the business logic and the underlying database structure from other components and objects.
  • the process flow and the business logic associated with a given business entity or process are completely encapsulated within the component, as is the data related to the business entity or process.
  • There are many commercially available components on the market commonly implemented using Microsoft's ActiveX or Java's Enterprise Java Bean technology.
  • Each component is preferably implemented as object-oriented classes.
  • classes encapsulate all of the data and behavior associated with finer-grained processes or entities within the business model.
  • An instance of a class is called an object.
  • An instance of the customer class might be labeled as the “ABC Energy Traders Inc.” object.
  • Components are implemented by a collection of classes that have been coded and compiled into bytecode. This bytecode is interpreted at run time by a Java Virtual MachineTM (JVM) or some other just-in-time compiler and translated into instructions that can be interpreted by the processor running the JVM.
  • JVM Java Virtual MachineTM
  • Java has been selected as the preferred embodiment of this invention for example purposes only. Components can be further packaged in a single file that can be easily administered and distributed, such as a Java Archive (JAR, i.e., “.jar” file).
  • JAR Java Archive
  • Business object instances in the system represent critical information relating to the operation of a competitive physical and financial marketplace. Given this high-risk environment, changes in the state of the system will need to be logged for auditing purposes. In addition to audit logging, certain operations will be required to be performed on the system as it existed in a given point in time. This will require some objects to be versioned in a way that they can be reconstructed as they once existed at a specified time.
  • the versioning needs of business objects in the system can be broken into four separate categories: audit enabled, effectivity-enabled, versioned inputs, and versioned outputs. Audit enabled business objects will trigger an entry to an external audit log whenever their state changes. Effectivity-enabled business objects represent the state of some entity over a specified time interval.
  • Versioned input business objects are those that will need to be recreated as they existed at a given point in time. These objects describe a system state that is used as an input to processes that are meant to perform on the system as it existed at some past time. This is different from effectively enabled objects in that objects that are versioned inputs represent different versions of entities that describe the same thing but are described with varying degrees of accuracy at any given point in time.
  • Versioned output objects are those that need to be recreated as they existed in a given point in time and need to provide a basis for how they were created. These objects are created based on a system state that could have existed in the past.

Abstract

A system and method for facilitating, coordinating and managing the operation of a competitive marketplace via the Internet. The system and method collect bids for market services from a plurality of customers, calculators a clearing piece for the market service and calculates settlement information based on the clearing piece calculated and the bids collected.

Description

    FIELD OF THE INVENTION
  • The present invention is directed to a method and system for facilitating, coordinating and managing a competitive marketplace and, more particularly, a method and system for facilitating, coordinating and managing a competitive energy market using the Internet.
  • BACKGROUND OF THE INVENTION
  • In recent years, the Federal Energy Regulatory Commission and other regulators have been mandating the deregulation and restructuring of the electricity industry in the United States. This follows a similar restructuring of the telecommunications industry and other regulated industries over the last two decades. It has become apparent to consumers, regulators, and industry experts alike that the electricity industry no longer fits the natural monopoly model that has thus far existed in this country, and that a new competitive model is necessary for the continued growth and health of this industry.
  • The restructuring of the electricity industry has driven significant change within the industry. Most significant of these changes are the separation of the physical flow of electricity from its financial flow, and the introduction of retail and wholesale competition. With the introduction of new types of transactions, the establishment of new markets, and the emergence of new market players, there is a growing need for a system and method to coordinate and manage this competitive marketplace.
  • The physical flow of electricity remains substantially unchanged from the traditional utility model. Electricity is still generated, transmitted over transmission and distribution wires, and consumed by end-users. In the traditional model of the electric industry, the money is routed through the same organizations as the electricity itself. In the new marketplace, however, transactions become considerably more complex. Money may trade hands several times and there may be any number of financial instruments related to a single physical delivery of energy. This suggests a need for additional capabilities to facilitate, coordinate and manage the increasing number and complexity of these financial transactions. FIG. 1 illustrates the separation of physical and financial flows concerning electricity in the new competitive marketplace. It can be seen from FIG. 1 that while the physical flow of electricity remains unchanged, the financial flow is now from the consumers to the energy merchant and onto the producers.
  • With ownership of physical infrastructure no longer a prerequisite for entering the energy marketplace, many new entities have begun to participate in the electricity trade. Also, utilities have begun to divest and separate their generation from their transmission and distribution. As a result, with reference to FIG. 2, the electricity marketplace must now accommodate producers such as generation companies; deliverers such as transmission distribution companies, and regional transmission groups; energy merchants such as energy traders, power marketers; and other new entities. Each organization within the industry may have any number of customers, but only in some cases is this customer the end-user or “consumer” of the electricity. In all cases, however, the various organizations must exchange information, money, energy, and energy-related services. The industry faces many challenges in facilitating, coordinating and managing the interactions of all of these new and transformed entities.
  • From this perspective, the area that has probably seen the most dramatic change over the last few years is the central operator. A central operator is a broad term grouping a variety of organizations that lie at the center of the value chain, as shown in FIG. 2. It describes the collective functions that facilitate, coordinate and manage the activities of participants in the electricity marketplace.
  • The traditional central operator's role has been to operate the transmission system, usually as a small division of a large utility or power pool (e.g., New England Power Pool). This is sometimes known as a system operator function. The system operator is responsible for planning, scheduling and dispatching generation; managing the interconnected transmission grid; and ensuring short-term and long-term system reliability. In the past, power pools, reliability councils, and traditional vertically integrated utilities have handled these tasks through coordinated efforts. In the competitive marketplace, however, the central operator has emerged as a leading alternative to support the combined roles and responsibilities of these traditional organizations.
  • Under deregulation, the roles played by central operators have expanded from coordinating the safe and reliable operation of a power system to implementing market rules, facilitating physical and financial transactions, and serving as a gatherer and central coordinator of market information. This is sometimes referred to as a market operator function.
  • As a market operator, the central operator may be responsible for conducting an auction of energy and accepting and managing competitive bids and contracts for energy and ancillary services. It provides for the financial settlement of energy and ancillary service markets, including billing and clearance for market trading.
  • To address the changing face of the energy marketplace, it is desirable to provide a system and method of facilitating, coordinating and managing the operation of that marketplace that is simple to use, manages competitive bids and contracts and financially settles the marketplace.
  • It is also desirable to provide a system that is flexible and can be modified to accommodate market growth and changing business rules.
  • SUMMARY OF THE INVENTION
  • According to a first aspect of the present invention there is provided a method of facilitating, managing and coordinating the operation of a competitive marketplace using the Internet. The method includes the steps of collecting bids for market services from a plurality of customers over the Internet, calculating a clearing price for a market service and calculating settlement information based upon the clearing price calculated and the bids collected.
  • According to a second aspect of the invention there is provided a system for managing and coordinating the operation of a competitive energy marketplace. The system includes a power system component that represents a network model of a physical power system including generating units, load facilities, transmission lines, and network areas. In addition, the system includes a customer component that manages all information about entities that have a business relationship with a market operator. The power system component and customer component are operatively coupled to a market operator to receive data from the market operator. The system includes a bid component that enables customers to submit bids for energy services and a meter reading component that stores meter readings submitted by customers. The bid component and meter reading component are operatively coupled to customers. A settlement component financially settles all markets based upon meter readings, operational information, bids and clearing prices. The settlement component is operatively coupled to the power system, customer, bid and meter reading components to receive data therefrom. A bill component operatively coupled to receive data from the customer and settlement components summarizes the financial activity for each customer to be used on an invoice for services provided and/or received.
  • According to a third aspect of the invention, there is provided a method of facilitating, managing and coordinating the operation of a competitive marketplace using the Internet. The method includes the steps of collecting bid and contract information for market services from a plurality of customers. The operation of units is then scheduled to provide the market services according to the bid and contract information collected. The operation of the units scheduled is next deployed and meter reading information from the units scheduled is collected. The market then settled in accordance with the bid, contract and meter reading information collected.
  • According to a fourth aspect of the present invention, there is provided a computer program embodied on a computer readable medium for interfacing with a competitive marketplace. The computer program includes code for collecting bids for market services from a plurality of customers over the Internet, code for calculating a clearing price for a market service, and code for calculating settlement information based upon the clearing price calculated and the bids collected.
  • According to a fifth aspect of the present invention, there is provided an article of manufacture for facilitating the operation of a competitive marketplace. The article of manufacture includes a computer readable medium having a management interface for collecting bids for market services from a plurality of customers over the Internet, calculating a clearing price for a market service, and calculating settlement information based upon the clearing price calculated and the bids collected.
  • According to a sixth aspect of the present invention, there is provided a market information publishing component that supplies a variety of internal and external customer informational needs. More particularly, the market publishing component includes two independent components, a database population component and a report generation component. The database population component reorganizes data from many different sources into a common repository designed to suit customers' needs. The report generation component is then called upon whenever a customer requires a pre-defined report wherein the report generation component takes data from the database population component.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a schematic illustrating the separation of physical and financial flows in a competitive electricity marketplace.
  • FIG. 2 is a schematic illustrating the participants in a competitive marketplace.
  • FIG. 3 is a schematic of a business model that implements the present invention according to a preferred embodiment of the present invention.
  • FIG. 4 is the home page display screen according to a preferred embodiment of the present invention.
  • FIGS. 5-19 are various display screens for the bid component according to a preferred embodiment of the present invention.
  • FIGS. 20-31 are various display screens for the contract component according to a preferred embodiment of the present invention.
  • FIGS. 32-40 are various display screens for the customer component according to a preferred embodiment of the present invention.
  • FIGS. 41-53 are various display screens for the power system component according to a preferred embodiment of the present invention.
  • FIGS. 54-59 are various display screens for the batch scheduler component according to a preferred embodiment of the present invention.
  • FIGS. 60-69 are various display screens associated with the settlement component according to a preferred embodiment of the present invention.
  • FIGS. 70-72 are various display screens associated with the bill component according to a preferred embodiment of the present invention.
  • FIGS. 73-76 are various display screens associated with the meter reading component according to a preferred embodiment of the present invention.
  • FIGS. 77-78 are schematics illustrating the technical architecture according to a preferred embodiment of the present invention.
  • FIGS. 79-82 are schematics illustrating various features of the application architecture according to a preferred embodiment of the present invention.
  • DETAILED DESCRIPTION
  • Facilitating, coordinating and managing the day-to-day operations of a competitive marketplace, such as the electricity market, is a complex task. While the present invention will be described in the context of managing an electricity marketplace, the present invention is not limited to such a market and may be applied to manage other competitive markets, such as a natural gas market. The facilitation, coordination and management of the day-to-day operation of the market are, for the most part, performed by a market operator and a system operator. The market operator conducts an auction for energy and ancillary services, collects contracts and bids for energy and ancillary services and provides for the financial settlement of the markets, including billing and clearance for market trading. Often, the market is settled in hourly or even sub-hourly trading intervals and the market operator must collect, coordinate, and distribute a vast amount of market information. The system operator takes information provided by the market operator and creates a dispatch schedule. The system operator uses the dispatch schedule to direct generators to operate their units accordingly.
  • The market operator is typically operating a spot market. The spot market is the core of a competitive electricity marketplace. The spot market is the mechanism responsible for setting the value of electricity or some ancillary service in an interval of time and facilitates the efficient operation of the physical power system. The actual operation of the spot market will vary depending on the prevailing market rules and procedures. However, in a pool model, the context in which the present invention will be described, the market will typically operate as follows.
  • In a pool model, generally, all producers generate into a common pool of energy and all customers take out of the same pool. Generators decide for themselves when they would like to commit their plant to generate electricity and bid each day for the opportunity to run their plant. In general, a bid consists of several bid blocks, including a price and a quantity for each trading interval of the day. In addition, bids can be submitted for ancillary services such as energy reserve or capability. The bid process can be generalized for any market service or commodity.
  • Bids may also be submitted by consumers of electricity. These demand-side bids of price and quantity represent the amount of load the consumer is willing to shed based on price. For example, a large industrial consumer may see economic benefits by reducing production levels at a large manufacturing plant if the spot price for electricity is high. Loads that bid their demand are often called dispatchable loads because the load is dispatched based on price. Additionally, customers submit other relevant forecasts about the characteristics and behavior of their units or dispatchable loads during the bidding process. Examples include high and low operating limits, the seasonal capability of units and scheduled maintenance outages.
  • The system operator addresses reliability concerns and often publishes a dispatch schedule that also takes into consideration additional information such as historical power system performance, weather forecasts, projected supply shortages, system maintenance and fuel costs, for example. The system operator uses the schedule to direct generators to load their units accordingly. At the actual time of dispatch, the generator with the lowest price bid will be dispatched first, with each subsequent generator dispatched as required until supply matches demand. Ancillary services are also designated as required to maintain real-time system reliability and stability.
  • The spot price, or clearing price, is equal to the lowest possible price at which supply meets demand. Preferably, the spot price is determined “ex-post”, i.e., after the dispatch process. The final clearing prices in the pool are determined by what actually happens on the trading day, not what was projected at the time the original schedule was published. Alternatively, the spot price can be determined at the time the original schedule is published. This pricing information is shared with the market operator for settlement purposes. More particularly, once bids have been submitted and the bid deadline has passed, the system operator performs a unit commitment process. Unit commitment involves taking all of the bids, stacking them from lowest price to highest price and determining an economic merit order that should be followed at the time of dispatch. For example, Table 1, shown below, illustrates a bid stack for hour 10 of the next day.
  • TABLE 1
    QUANTITY PRICE ASSET
    100 MWh $50/MWh Gen. Unit C
    200 MWh $20/MWh Gen. Unit B
    150 MWh $15/MWh Gen. Unit B
     50 MWh $10/MWh Gen. Unit C
     50 MWh $10/MWh Gen. Unit A
    200 MWh  $0/MWh Gen. Unit B
    100 MWh  $0/MWh Gen. Unit A
  • The day ahead of the trading day, the system operator forecasts that for the next day the total system load for hour 10 will be 500 MWh based on historical data, the weather forecast, external contract sales to other power pools, etc. It can be seen from Table 1 that for supply to match demand, the 500th MWh will be provided by Unit B at a cost of $15. This forecasted clearing price allows customers to guess what their position might be in the market and hedge their risk with short-notice contracts, for example. The system operator also publishes a schedule of economic merit order for the units. This commits Unit A to run 150 MWh, Unit B to run 300 MWh, and Unit C to run 50 MWh. In some markets, this day ahead clearing price is used to settle the market. Everyone that consumed energy is charged at $15/MWh. For example, Gen Unit A would be paid $15*150=$2250, Gen Unit B $15*300=$4500, and Gen Unit C $15*50 MWh=$750. In other markets, there is no financial settlement ahead of the trading day.
  • On hour 10 of the actual trading day, the system operator determines that the real-time load is actually 600 MWh instead of 500 MWh. Perhaps there are more people running their air conditioner than this time last year or, perhaps, Gen Unit C has been shut down for emergency maintenance. This means that the system operator orders Gen Unit A to provide 150 MWh, and Gen Unit B 450 MWh. The actual load sets the clearing price at $20/MWh since the most expensive MWh was provided by Gen Unit B at its bid of $20/MWh. In most markets, this is the clearing price used for market settlement. It reflects the actual cost of the market service during the actual trading interval. While a particular example has been set forth, the clearing price may be determined either before or after the actual dispatch of the units, depending on the market rules. In either case, the price is used by the market operator in the settlement process to determine charges and payments as will be described hereinafter.
  • Clearing prices for each trading interval can be extremely volatile. In order to provide some certainty, customers in a market may create contracts for the purchase or sale of a market service to or from other customers or from an external source such as a neighboring control area. Although most contracts are negotiated bilaterally between customers, a great deal of the contract information is captured by the system operator for scheduling and by the market operator for use in settlement of the marketplace. In a preferred embodiment, these contracts can be for assets that transfer a percentage of a unit or load to another customer, or they can be system contracts that are simply a quantity of electricity or other market service. For either type of contract, buyers and sellers can attach pre-determined conditions (PDCs) to the contract that stipulate additional conditions that make the contract active or inactive. The PDCs can be based on a unit's availability or actual performance of a generating unit, or it can be based on the scheduled or available quantity of another contract. Contracts can also be dispatchable based on clearing price, thus taking on a different percentage or value depending on the clearing price. Each percentage and clearing price or value and clearing price pair is known as a contract block.
  • The following is an example of an asset contract. Customer A owns 100% of Generating Unit #1. However, Customer A has previously reported to the market operator that Customer A and Customer B have entered into a contract where Customer B has purchased a dispatchable unit contract with two dispatchable blocks. One block is for 25% of generating unit #1 if the clearing price reaches $10, and the other block is for an additional 25% of generating unit #1 if the clearing price reaches $15. There is also a pre-determined condition on the contract indicating that generating unit #1 must be dispatched for at least 50 MWh before the contract becomes active. In the contract, Customer A and B agree that Customer B would pay $50,000/year to Customer A for the duration of the contract. This part of the transaction is not handled by the market operator. However, the conditions and terms of the contract are reported to the market operator. During an actual trading interval within the duration of this contract, generating unit #1 is dispatched at 100 MWh. The clearing price for that trading interval is also determined to be $15/MWh. If the contract were not active (i.e. generating unit #1 was only used for 10 MWh), Customer A would be entitled to the entire MWh output of generating unit #1 times the clearing price (e.g. $1500). However, the contract is active, so Customer A only retains 50% entitlement on generating unit #1 and Customer B retains the other 50%. The market operator then determines during settlement that the contract is worth 50 MWh (i.e., 50% of generating unit A), so Customer A receives a $750 payment and Customer B receives a $750 payment.
  • The following is an example of a system contract. Customer A owns 100% of generating unit # 1 and 100% generating unit #2, and Customer B owns 100% of load facility #3. Customer A agrees to sell a 50 MWh system contract to Customer B. This contract is submitted to the market operator. During the trading interval of interest, generating unit #1 is metered as producing 100 MWh as is generating unit #2, and load facility #3 is metered as consuming 100 MWh. The clearing price is $15. Before the contract is taken into account, Customer A would be entitled to 200 MWh resulting in a $3000 payment. Customer B would be obligated for 100 MWh, or a $1500 charge. However, the contract is determined to be active and valued at 50 MWh. As a result, Customer A has a net entitlement of 150 MWh and gets a $2,250 payment. Customer B offsets their 100 MWh obligation with the 50 MWh contract, resulting in a 50 MWh net obligation and a $750 charge.
  • After the trading day, customers submit meter readings for the unit, loads, and tie lines for which they are the responsible party. The system operator also shares meter data, bid re-declarations, pricing, contract schedules, reserve designations, ancillary service requirements, and other data with the market operator. The market operator acts as the central clearing house for the information associated with the actual operation of the marketplace on the trading day.
  • Once the market operator has acquired pricing and power system information about the trading day from the system operator and the customers, the marketplace is settled. Everyone providing energy or ancillary services has to be paid, and everyone consuming has to be charged. The market operator uses the information about the operation of the power system and pricing information to determine charges and payments on an asset by asset or customer by customer basis. The results of this financial settlement are then made available to the marketplace customers.
  • Eventually, the results of market settlement must be cleared in the form of a bill. The market operator aggregates the settlement results for a bill period and creates a bill for each customer. The bill reflects not only the customer's activity in the market, but also additional charges and payments applied by the market operator to cover imbalances, operating expenses, transmission tariffs, and the like. Additional adjustments can be made to a customer's bill when necessary. A final invoice can then be prepared for each customer. Finally, invoice information may be preferably shared with financial systems external to the market operator. These external financial systems may include invoicing systems, general ledgers, and electronic fund transfer software.
  • In general, using Internet technologies, the present invention preferably employs a secure, Java-based, distributed component or object application which runs on an architecture composed of servers supported by a relational database, Java just-in-time compilers, and an object-request broker (ORB). Customers access the system through standard browser-equipped personal computers with Internet access.
  • Turning to a more detailed description, the present invention is partially implemented utilizing a set of distributed components deployed in a multi-tiered network-centric architecture collectively providing the services needed to effectively facilitate, coordinate and manage a competitive marketplace preferably via the Internet. Overall, the description of the system can be broken down by its business components, technical architecture, and application architecture.
  • Business Components
  • The market operator provides a full set of business components to facilitate bidding, contract management, meter-reading submission, market settlement, and billing in addition to managing an enterprise wide solution to customer information and power system modeling. These functions are scalable, easily interfaced to other systems, designed to be highly reliable and secure, and constructed with the data and audit needs of the customer in mind. An object-oriented design approach which utilizes object-based techniques such as inheritance, encapsulation and polymorphism is used to make the application flexible. Thus, new classes can be rapidly designed or modified if new market rules and procedures dictate the need. The object-oriented design also uses standard messages and methods so that components can be added or removed from the application with minimal change to existing components.
  • FIG. 3 is a schematic of a business model 200 that implements the present invention and includes major component-to-component interactions, interfaces, and links to customers as well as other software packages. The key components include a customer component 202, a bid component 204, a contract component 206, a meter reading component 208, a settlement component 210, a billing component 212, and a power system component 214. The business model 200 shown in FIG. 3 is a generalized model and may be different depending upon the market operator's scope of responsibility. For example, pricing may or may not be integrated into the market function, but might instead be part of the system operator function (not shown). The exact dynamics of the market operator will vary for each implementation. As the marketplace evolves, there will likely be many rule changes, regulatory mandates, new entrants into the marketplace, and fundamental changes to the business model. A system implementing market functions must be adaptable, quickly deployable, and flexible enough to change as business needs change. Ideally, each core function would encapsulate its own information and behavior so that one capability could be modified or replaced with minimal impact on other market operator capabilities.
  • In response to this need for an integrated, dynamic, and robust market operator capability, a component-based object-oriented system has been developed that provides the core functions required to coordinate and facilitate the market activities of customers in a competitive marketplace.
  • With reference to FIG. 3, the components of the business model 200 communicate with one another in the following fashion. The settlement component 210 receives information from the power system component 214, customer component 202, bid component 204, meter reading component 208 and contract component 206. In addition, it receives scheduling, pricing and dispatch information 216 from the system operator through an interface module 218. The bill component 212 receives information from the customer component 202 and settlement component 210 and outputs information to external financial systems 220 through an interface 222. These external financial systems 220 may include invoicing systems, general ledgers and electronic fund transfer software. The bill component 212 also outputs information to customers 224 through an invoice interface 226. The bid, meter reading and contract components receive information from customers 224 preferably through a graphical user interface 228. The power system and customer components 202 and 214 receive information from customers 230 through graphical user interface 232. Customers 230 are preferably internal to the market operator.
  • The power system component 214 represents a network model of the physical power system, including the generating units, load facilities, transmission lines (tie lines), network nodes and network areas. It is adaptable to multiple pricing and/or bidding zones and maintains generation characteristics including operating limits, ramp rates, and black start capability.
  • The customer component 202 manages all information about entities that have a business relationship with the market operator. It retains data on customers, including market eligibility, equity ownership in generation and load, contact information, bidding responsibilities, and meter-reading responsibilities.
  • The bid component 204 enables customers to submit, view, modify, and validate bids via a graphical user interface or through a bulk file upload facility. It applies physical limit checks on bid offers for each generator and allows for bidding through multiple price-quantity bands, potentially different for each trading interval. It provides for varied types of energy bids including support for fuel constrained and self-scheduled generation and accepts updates during the open bidding period to accommodate changes in generating unit or dispatchable load characteristics. It contains user interfaces to allow the market operator to vary bid submission deadlines. It maintains information about customer offers to provide market services such as energy, ancillary services, or capability service and provides a full audit log, including user access information to facilitate statistical analysis on bidding practices.
  • The meter reading component 208 stores meter readings submitted by customers for all metered generation, load, and tie flows and allows for validated bulk meter reading submission. It offers helper functions that allow customers to enter information quickly and efficiently and identifies missing or incomplete metering data.
  • The contract component 206 allows for the creation of contracts and accepts contracts for a wide range of market offerings (energy, ancillary services, etc.) and contract definitions (system, asset-specific, etc.). It offers user-friendly web interfaces for placing transactions into the system and a file upload mechanism for high-volume users, all with real-time validation. It provides the facility to submit a contract schedule, slicing the contract into several price bands with each band evaluated separately against the market clearing price, and it determines contract activity based upon conditions to be evaluated post-dispatch, such as unit availability or physical contract activity.
  • The settlement component 210 manages the financial settlement of all markets based upon meter-readings, operational information, bids, contracts, and clearing prices. It determines clearing prices through economic stacking of bids as previously described. It performs reconciliation to account for accurate, month-end metering data. It contains an extensive versioning mechanism that allows for the re-settlement of any given period based on new or changed input data.
  • The bill component 212 summarizes the financial activity for each customer on an invoice for the service provided or received. It performs differential billing for trading intervals re-settled with corrected input data but previously billed on a historical invoice. It provides for flexible bill processing periods. It can be supplied with an interface to enter manual line items such as registration fees or special charges and interfaces with third party systems, such as tariff billing systems. It preferably communicates with third party accounting software to provide general ledger and activity accounting updates.
  • Also shown in FIG. 3 a market information server 221 may be included. The market information server is a data warehousing tool designed to service a variety of internal and external customer informational needs. The heart of the market information server is a database which acts as a central repository for data elements from a variety of informational sources within the market operator. The market information server associates transactional input, such as bids, contracts, and metering data, with market activity data, such as clearing prices and generator operational flags. The market information server then ties this set of information to each market customer's individual settlement. Using market information server reporting tools on the data warehouse, reports are created and distributed to each customer according to security level. Additionally, high level studies and drill-down details for internal market operator functions such as market administration, market power monitoring, auditing, and billing are easily performed on the same data set.
  • The market information server application is composed of two independent components: database population component and report generation component. The database population component performs all of the data gathering steps and runs periodically, either through a batch process or through special-case market operator user execution. With each execution of the database population component, the data is re-organized from many different sources, each tailored to their respective applications, into a common repository design to suit customers' needs. After this stage, the report generation component is called upon whenever a user requires a pre-defined report. In addition, third party tools may be used for ad-hoc queries.
  • Customer's interaction with the market operator is based on a transactional system: individual customers' browsers connect with the market operator and the customers enter bids for the output of their generators and for ancillary services as well as bilateral contracts. Additionally, metering parties submit generation, consumption, and tie flow values used in the determination of market settlement.
  • The nature of transactional data is fragmented in that data enters the system through the course of each day. The market information server selects data elements which have financial implication to each trading interval settlement, collects them, and updates the market information data warehouse. For example, only final metering data is selected for retention even though multiple meter submittals had been performed for the same asset during the same trading interval.
  • Operational information from the system operator is also gathered into the market information database. This data, while also transactional, has the added characteristic of being time critical. Whereas market operator transactions are correlated post-dispatch, operation data is collected and reported in near real-time. Near real-time reporting is achieved by polling the system operator's energy management system several times per hour and making the information received from this query available to users with access rights to review it. This data set includes, but is not limited to, instantaneous clearing prices, generator operational flags, and pool reserve designations. While quantities may be overridden by market administrators during the settlement process, this information provides timely feedback to those customers directly affected by the dispatch characteristics. By developing a secure, reliable, and informative link between market operators and market customers, communication between the parties will eliminate problems which would potentially need to be handled through dispute resolution.
  • The third source of information for the market information server is the market operator's settlement database. The market operator provides performance information for each customer and, ultimately, billing data. With this data selected and correlated to the transactional and operational data, a complete snapshot of each trading interval's activity is created.
  • The market information data warehouse generates reports designed with customer requirements, rather than specific application requirements, in mind. The table structures are constructed such that customers and asset information are easily tied to each market. This design serves three major purposes: fast querying capability, multiple delivery options, and report writing flexibility.
  • Data warehousing enables fast database access which facilitates reporting the data itself. High speed report creation becomes increasingly more important as energy markets become more open and more customers actively query the system. The sheer number of data elements for each trading interval coupled with the volume of customers making informational requests may result in a system that is burdened with preparing data sets on the order of Gigabytes per day. Rapid turn-around of these requests, especially if an on-line request-based method is used, is a key to the market information server's potential success.
  • A variety of methods may be chosen for publication of the data. For public information, data may be posted directly to the Internet. Again using third party Web reporting tools, trend analyses such as clearing price history, can be shown right on the Web with only minor additional effort. In the case of confidential data, a special list of customers that are enabled to view the data would be created and the market operator may opt to make these reports available either through a secure Web server or through a traditional file transfer protocol server.
  • In any case, some customers will require data to be prepared for easy import into analysis tools, such as spreadsheets and desktop databases. The market information server application has a built-in architecture used to create standard comma delimited files, along with error handling and file maintenance tracking tools. To facilitate users who choose the spreadsheet import method, templates are created for the customer to download and use.
  • Another strength of the market information server is its ability to empower internal market operator staff with the ability to easily create ad-hoc reports. Market administrators will choose to create very detailed reports for a given trading interval in order to perform check-and-balance type operations. Market monitors will tend to create detailed reports as well, but on the customer or asset level to study trends in bidding, metering, and contract writing. Auditors and billing staff will run summary type reports which aggregate many customers and many trading intervals over monthly or annual time frames. Regardless of the type of report designed, the time between report design request and report delivery is shortened because of the data warehouse.
  • Returning to the components shown in FIG. 3 each component described above, as well as some others, will now be described in further detail. Of course, the details of each component may change depending on the marketplace in which the present invention is implemented and the particular business rules developed for each market. For illustration purposes, the present invention is applied to the electricity marketplace.
  • FIG. 4 illustrates the home page 300 as seen in Netscape browser on a customer's graphical user interface. The components shown in FIG. 3 and discussed above, as well as some additional components are displayed. The user can access a component by selecting the desired component with a device such as a mouse or a key stroke, for example.
  • The bid component 204, preferably provides the bidding capabilities required for a supply-side auction of energy services. The bid component provides many primary services which will be described below. The bid component enables customers to submit, view, modify and validate bid and resource characteristics via an effective graphical user interface or bulk file upload for a plurality of market services such as energy, automatic generation control (AGC), ten minute spinning and non spinning reserve, thirty minute operating reserve, installed capability and operable capability.
  • FIG. 5 is a display screen for the bid component according to a preferred embodiment of the present invention that can be displayed on a customer's workstation. As can be seen at the top of the screen, tabs 501 are provided that allow the user to display various screens of the bid component. The screen shown in FIG. 5 is the bid information tab. The bid information screen provides information to the user concerning submission deadlines and date ranges for bid entries. The user can also perform a search for a particular customer by entering either a customer name or identification number on the right side of the screen.
  • FIG. 6 is a display screen of the energy tab of the bid component according to a preferred embodiment of the present invention. From this screen, the customer can begin the bidding process. On the left side of the screen a start screen is displayed where the customer can enter bidding information as shown. In this particular example, a new bid is to be created from scratch for the Avalanche Gas unit. After the customer has entered the requested information, the “Next” radio button is activated and a helper screen as well as a bidding grid of the energy panel is displayed as shown in FIG. 7. From this screen the customer can enter information as to the parameters of the bid. The bidding grid on the right side of the screen will be filled with the parameters the customer selects. Energy bids preferably consist of blocks of price and MW amount for each trading interval within a scheduled dispatch period. Energy bids may also contains a self-scheduled MW amount 701, a high operating limit 702, and a low operating limit 703 for each trading interval. As seen in FIG. 7, the scheduled dispatch periods are listed and the user can enter the amount and price for each trading interval either directly in the grid or by using the helper. Once the bidding information is entered, the customer can submit, clear or reset the bid information. After the customer submits the bid a confirmation screen is displayed on the customer's work station as shown in FIG. 8 indicating confirmation of the bid. In a preferred embodiment, the customer is notified of the date and the time that the bid was accepted, its effective date and unit name.
  • Bids for other market services may also be entered. FIG. 9 illustrates the display screen for the AGC market. Again, a start panel is displayed on the left side of the screen so that the customer can enter information. This information is submitted by activating the “Next” radio button which then displays the screen shown in FIG. 10. On the left side of the screen is a helper panel that prompts the customer for bid information. In this particular example, the bid price has been selected at $22 per hour as shown on the right side of the display. The customer is also able to edit the characteristics of the unit by selecting the “Edit AGC Characteristics” tab 1001 at the bottom of the right side of the display. FIG. 11 illustrates the “Edit AGC Characteristics” panel. Again, a helper panel on the left side of the screen allows the customer to enter data quickly, if desired, otherwise the customer can enter information directly on the right side of the display.
  • FIGS. 12-15 illustrate the display screens for the other market services, i.e., reserve and capability, and are similar to those already described and thus need not be described in further detail.
  • FIG. 16 illustrates the resource characteristics panel of the bid component. In this example, the customer has selected to edit the characteristics of an existing unit, the Avalanche Gas unit. In response to this action, the display screen shown in FIG. 17 is displayed and from that screen the customer can change existing parameters such as minimum run time, minimum shutdown time, etc. Depending on the access provided to the customer, various tabs will be enabled or disabled. For example, the maintenance tab of the bid component is preferably enabled only for market operator internal users, i.e., customers that make up the market operator. FIG. 18 illustrates the maintenance tab of the bid component. From this screen, the market operator can edit existing parameters or enter new parameters. In this example, the market operator chooses to edit existing parameters. In response, the display screen shown in FIG. 19 is displayed. As can be seen, the market operator can edit various parameters, that control the bidding process such as bid submission deadlines and the number of bids that can be entered in advance.
  • Thus, the bid component allows customers to enter bids up to a daily trading deadline applicable for the market. In addition, it also allows customers to enter bids up to a predefined number of days in advance and allows customers to create a new bid using an existing bid for a day up to a predefined number of days prior. Furthermore, the bid component provides the market operator the ability to enter bids on behalf of customers. This provides a contingency measure if customers experience communication or hardware problems. The bid component records the bid entry type for each bid submitted. The bid entry types include bids entered by customer, default bids generated by the bid component and bids entered for the customer by the market operator.
  • The bid component is also responsible for creating default bids for each market service other than operable capability and installed capability. For each active unit without a bid submitted for the scheduled dispatch period, a default bid is created. The default bid is a replica of a bid from a previous scheduled dispatch period bid for that unit. If an active unit exists in the market but a bid for the previous scheduled dispatch period does not (i.e., a new customer has not submitted a valid bid) then an ERROR is logged and no default bid is created.
  • Bids can be either on a customer by customer basis or an asset by asset basis, depending on the prevailing business rules. However, the bid component itself is not limited in any way to a fixed number or type of market services, and the bids need not be only for electricity or ancillary services. For example, the bid component could readily accommodate bidding for natural gas or some other commodity. Additionally, the bid component could also incorporate demand-side bidding, giving the bid component complete bidding capability for any commodity auction. From any screen the customer can select a component either from the icons located at the bottom of the screen that are always displayed or by returning to the home page shown in FIG. 4.
  • The contract component 206 supports the ability to create various contracts including external system, external unit, internal system, internal assets and internal obligation contracts. In addition, the contract component enables a customer, an agent for the customer or the market operator to submit contracts via a bulk upload facility. FIG. 20 illustrates the beginning screen of the contract component where the customer selects the contract type, market service and duration of the contact as shown. After that information is entered, a general information panel is displayed on the right side of the screen as shown in FIG. 21. The general information screen indicates the parties to the contract and identification information. The customer can view details of a contract by selecting the “Details” tab at the bottom of the right side of the display. FIG. 22 is a display screen of the details panel. In addition, the customer can view whether there are any predetermined conditions associated with a unit by selecting the “Pre-Determined Cond” tab. FIG. 23 is a display screen of the predetermined conditions panel. It can be seen from FIG. 23 that the unit's availability is a predetermined condition of the example contract. The customer submits the contract by activating the “Submit” radio button and a confirmation screen as shown in FIG. 24 is displayed confirming that the contract was received as well as particular parameters of the contract. The contract illustrated in FIGS. 21-24 was for an internal contract type. Next, an external contract type will be described with reference to FIGS. 25-28. FIG. 25 illustrates a display screen for entering contract information for an external contract. FIG. 26 illustrates the “General Info” tab for the external contract and indicates the parties to the contract as well as identification information. FIG. 27 illustrates the details panel for the external contract where the customer can enter the contract information either directly on the right side of the screen or through the helper panel on the left side of the screen. In the particular example shown, the customer has contracted for 50 MW. The customer activates the “Fill” radio button and, as shown in FIG. 28, that information is filled on the right side of the screen. The customer can also view whether there are any predetermined conditions associated with the external contract by selecting the “Pre-Determined Cond” tab. FIG. 29 is a display screen of the predetermined conditions panel. The customer can also search for existing contract information through the search panel on the left side of the display as shown in FIG. 30. FIG. 31 is a display of the results of the search.
  • As previously described, the customer component 202 manages all information about the entities i.e., customers, that have a business relationship with the market operator. FIGS. 32-40 illustrate display screens associated with the customer component. FIG. 32 illustrates a display screen showing general information for an existing customer. As shown, a search was entered for customer names that begin with the letter “C”. The Cadillac Generator Company was retrieved and on the right side of the screen, information concerning the Cadillac Generator Company is displayed. In particular, the type of customer, its status in the pool and its settlement status are displayed. Additional information concerning a customer can be viewed by selecting a tab 3201 from the bottom of the right side of the display. FIGS. 33-40 show the various display screens, that can be viewed. These display screens provide information concerning a customer's address, contact information, DUNS information, any related information, asset information, governance information and user profile which dictates what rights the customer has to view or modify particular information, and agent maintenance information. The customer component is preferably accessible only by market operator internal users, i.e., the market operator.
  • As previously described, the power system component 214 maintains the model of the power system as it exists for physical and financial market settlement. The power system includes three primary elements: assets (generating units, loads, and tie lines), network nodes (a grouping of assets), and network areas (a grouping of network nodes). The power system component entitles the entry and maintenance of generating unit, load facility, tie line, network node, network area characteristics. These characteristics describe various aspects of each element. In addition, the power system component 214 enables the entry and maintenance of asset data and the relationships between assets.
  • FIGS. 41-53 illustrate the display screens associated with the power system component. Preferably only market operator internal users have access to this component. As can be seen in FIG. 41, from the top tab line 4101 the customer can select display screens for the network area, network node, generating unit, load facility and tie line. FIG. 41 is a display screen of search results for a network area. As can be seen on the right side of the screen, the network nodes that are inside and outside the network area are displayed. FIG. 42 is a display screen for an existing network node indicating the network areas associated with that node. FIGS. 43-45 are display screens of the generating units, load facility and the tie lines associated with the node, respectively. FIGS. 46-49 are display screens indicating information concerning a generating unit. The screens are self explanatory and thus need not be described in greater detail. FIGS. 50-53 are display screens associated with a load facility and tie line respectively. Thus, through the power system component, the entire marketplace is modeled.
  • The batch scheduler 201 provides a mechanism for the submission of batch jobs, and the prioritization of batch job submissions. The initiation of batch jobs according to the prioritization is supplied by a commercially available tool. It also provides the ability to submit dynamic parameters for a batch job and provides the ability to support unique billing functionality involving the submission of bill parameters. In addition, it provides a facility to view the status of batch jobs submitted through the batch schedule user interface. A batch scheduler tool such as Maestro which initiates the jobs as scheduled. FIGS. 54-59 illustrate display screens associated with the batch scheduler component. FIG. 54 is a general display screen from which a customer, preferably an market operator internal user, can select a batch job such as settling an hourly market for the energy market, as shown. FIGS. 55-56 are display screens for selecting other batch jobs such as printing an invoice or calculating voting shares, respectively. FIGS. 57-58 are display screens for the billing panel. As can be seen, the customer can select to process bills or roll back bills. FIG. 59 illustrates the log panel where the status of each selected batch job can be viewed.
  • FIGS. 60-69 are display screens associated with the settlement component. FIGS. 60-61 are display screens that indicate the clearing price for the energy and AGC markets respectively for a particular interval. The customer can update information if necessary. FIGS. 62-69 are display screens where various settlement parameters can be viewed and updated as is clear from the display screens. The settlement component 210 is responsible for the physical and financial settlement of all the hourly and monthly markets. In addition, the settlement component is responsible for the monthly meter adjustment settlement for meter reading. Various settlement-related parameters can be entered through the user interface and file upload services of the settlement component.
  • The settlement component highlights any data that was identified as having validation or availability problems in any trading interval and confirms that data necessary to complete settlement for a trading interval is available including, meter readings (MWh energy readings) and clearing prices (for each market service). The settlement component supports the ability to accept the different types of administered price including data correction and market suspension which will override the clearing price for a specific market service and trading interval.
  • FIGS. 70-72 are display screens associated with the bill component. The bill component 212 provides flexible bill processing so that each billed service can be billed for a distinct bill period. The market operator has the ability to disable the bill process for one or more billed services, to update the end date of the bill period for each billed service (the system will generate the next bill period begin date based on updates), and to roll back a bill period for a billed service. In addition, the bill component allows the initiation of bill processing by manually triggering a batch calendar event which will be described hereinafter.
  • The bill component provides a mechanism for the entry and maintenance of balanced and unbalanced adjustments to a customer's bills through a user interface or a file upload. The following information may be captured: customer identifier, the amount of the debit/credit per customer, the reason for the adjustment and a description of adjustment, for example. FIG. 70 illustrates the adjustment tab of the bill component. As can be seen from FIG. 70, the type of adjustment made and the reason for the adjustment is captured.
  • The bill component provides a mechanism to view a summarization of all bills processed. All calculated summary line item and net amount totals will be saved to a database so that external reports can be produced. FIG. 71 illustrates the market system details tab of bill component which displays summary information for each customer, including their net position in each market for the selected bill period and accounts payable and receivable. FIG. 72 illustrates a display screen accessed by the customer invoice tab. The customer invoice display uses a collapsible tree structure with each child node of the tree structure representing more and more details about a customer.
  • The bill component is also responsible for preparing an invoice for each customer. The bill component initiates invoice printing by manually triggering a batch calendar event. It also formats a file that includes all information to be printed on the invoice. The bill component creates statements that are payable to the customer and market operator. The bill component preferably creates a flat file to provide information to format a summary report.
  • FIG. 73-76 are display screens associated with the meter reading component. FIGS. 73-74 are directed to hourly meter reading data and FIGS. 75-76 are directed to monthly meter reading data. The hourly or monthly meter readings for a particular asset can be entered via these display screens by customers that are responsible for meter reading.
  • Technical Architecture
  • The overall technical architecture provides a flexible system that is easily and economically adaptable to changing environments. The technical architecture is designed to provide the system with several important benefits. These include a fault tolerant server/LAN combination, redundant communication interfaces, multiple distributed user interfaces, and archival storage media to ensure high system reliability as well as a plan for survivability in the event of a failure. The system is composed of a robust, highly secure network infrastructure and scaleable components to allow it to easily meet expected market operator transaction volume demands and to economically adapt to future ones. FIGS. 77-78 illustrate the major physical components of the system's technical architecture. With reference to FIG. 77, the system's architecture 100 preferably includes a plurality of external customer workstations 102, of which only one is shown, a Web server 104, an authentication token server/firewall 106, at least one market operator internal user workstation 108, preferably utilized by the market operator, at least one developer workstation 110 and at least one application server 112. The external user workstations 102 are coupled to the Web server 104 via the Internet 114. The Web server 104 communicates with the application server 112, internal user workstation 108 and developer workstation 110 over an Intranet 116, preferably a LAN, although other structures can be used.
  • The system shares key information and resources among many users throughout different organizations. Therefore, the ability of the system's network infrastructure to prevent unauthorized access to information is important. For enhanced security, the system preferably employs a multi-tier network security architecture. To access the system, each customer, external and internal, as well as the developer workstation have both a challenge token used to reveal a ‘challenge’ password based upon personal login information as well as an industry standard digital certificate, a unique digital signature issued and managed by the market operator itself. Challenge routers authenticate only customers who have valid credentials, consisting of the access code along with a digital certificate installed on the customer's workstation, thereby protecting sensitive resources and information attached to an Internet network from unauthorized access. Proxy services mediate traffic between the protected network and the Internet by establishing a screening server address, shielding outsiders from knowing (and later targeting) the specific addresses of servers within the private network. This level of security is totally transparent to the customer with the exception of needing to use a security card at the beginning of each session. The external customers 102, market operator internal users 108 and developer workstations 110 are all equipped with Web browsers.
  • With a secure connection established between the customer's workstation 102 and the web server 104, components of the system can be automatically loaded into the web browser of the customer's workstation 102. As a benefit of this technique, customers need not coordinate to update their software packages when enhanced versions of the application are released. In this way, new software to accommodate updated market rules or procedures is simple to release. Data is entered in and validated though graphical user interfaces at the workstations, while the transactions are entered in a database maintained by the application server 112. Customers internal to the system access the system in the same way as external customers, however additional functions are enabled as menu options as previously described. Thus, market operator internal users can initiate a settlement process or update a customer's information, for example, whereas external customers would preferably not be provided with this capability. Developers utilize Java development tools to maintain and enhance the architecture and application as necessary.
  • FIG. 78 illustrates a typical hardware configuration implementing a portion of the architecture shown in FIG. 77. Of course, other implementations can be used and the present invention is not limited to the particular embodiment shown. In this preferred embodiment, the application servers 112 are DEC 8400 Alpha servers on which Oracle's Version 8 Relational Database Management System runs in parallel mode to provide access to the database and maintain its integrity. Dual Silicon Graphics web servers, providing load balancing and fail-over protection, run Netscape Enterprise Server. The entire system communicates using TCP/IP, messaging protocol. As the principle method for transmitting data over the Internet today, this protocol is responsible for ensuring that data packets sent over the network arrive at the destination and are properly sequenced. Secure Hypertext Transfer Protocol (HTTPS) running on top of the TCP/IP layer is used as a light-weight file transfer protocol optimized for transferring these small files. Additionally, the system's execution environment is implemented using an Object Request Broker (ORB) to provide a mechanism that enables objects to transparently make requests of and receive responses from other objects located locally or remotely. The ORB uses Internet Inter-ORB Protocol (IIOP) based on Common Object Request Broker Architecture (CORBA) to send information across the network.
  • Application Architecture
  • Services provided by the application architecture are: presentation services, information services, communication services, environment services, transaction services and business logic.
  • The implementation of application architecture services is delivered using a network-centric architecture framework. The net-centric architecture framework is a common architecture that supports multiple electronic access channels to disparate sources of information reachable by customers using technologies that employ open, commonly accepted standards. FIG. 79 illustrates an example of the application architecture services according to a preferred embodiment of the present invention. For purposes of this description, the communication fabric and web services are considered part of the technical architecture.
  • Presentation Services
  • The presentation services enable the application to manage the human-computer interface. This includes capturing user actions and generating resulting events, presenting data to the user, and assisting in the management of the dialog flow of processing. The major presentation services include a window system, a desktop manager, a web browser, and an input device. FIG. 80 illustrates the basic user interface design. The user interface is divided into three hypertext markup language (HTML) frames. The top frame 602 contains a header applet, the middle, “main” frame 604 contains the main user interface applet, where component applets are displayed. The main frame 606 also contains a JavaScript function which can be invoked by the applets from the other frames. The bottom frame contains the MainMenu user interface applet which contains a menu to select a component to be displayed in the main user interface. FIG. 5 shows the application of this framework to the bid component user interface.
  • The user interface is preferably constructed using the Abstract Windowing Toolkit (AWT) available from Java 1.1. Applets are preferably constructed from core AWT classes (e.g. Canvas, Panel, and Label) as well as third party products (e.g., Tab Panel from Symantec) where necessary. In a preferred embodiment of the present invention Netscape's 4.5 web browser is used on the workstations. All functional areas are accessed through the web browser, however, Microsoft's Internet Explorer may be used. Some Netscape specific pieces related to security and software delivery would have to be altered before a full production deployment on Internet Explorer is possible.
  • The presentation layer is separated from the business logic and validation by the user interface/activity framework implementation. The user interface layer captures and handles the user-initiated events and displays the results of the event. The activity layer is responsible for validating the user's input and invoking services on the business components to process the transactions. That is, services to read data from a user interface and translate them into their corresponding data types and then validate the data types are handled by the user interface/activity framework implementation. The graphical user interface, such as that shown in FIG. 7, demonstrates many of the common user interface features of a component. As described above, the user is able to access the desired grouping of information using a tab panel metaphor. By clicking a tab, the user is shown a panel designed for the input and display of information related to the component. Button clicks and other user-initiated events are handled using standard object-oriented event handling implemented in the application architecture. Additionally, each panel of the user interface may contain any number of graphical user interface components or “widgets” such as editable text fields, list boxes, tables, sliders, combo boxes, and date spinners. Each graphic user interface component can capture events such as a click or key press and initiate some activity within the user interface's corresponding activity class. The activity is responsible for interpreting the event and initiating the correct business logic or validation.
  • Information Services
  • Information services manages information assets and enables the application to access and manipulate data from documents, databases or other external data sources stored locally or remotely. It minimizes an application's dependence on physical storage and location within a network. The primary storage services utilized in the present invention is provided by Oracle's Version 8.0 Relational Database Management System (RDBMS) resident on an application server. All persistent data is stored in relational tables within Oracle. In addition, Oracle provides data security and access services for database administration personnel. Database user accounts are protected with a password, and data/table access is governed by access rights established by database administration personnel.
  • FIG. 81 illustrates a schematic of a portion of the application architecture according to a preferred embodiment of the present invention. Oracle's Java Database Connectivity (JDBC) ThinDriver provides the Java-based application program interface needed to access the database from within the system. All common database transaction services are accessed through the JDBC. Since JDBC is independent of the particular database management system, the system has the added benefit of being isolated from the particular database implementation. The application architecture also provides a layer of separation from the JDBC API with the Persistence framework. This framework provides mapping from an object-oriented implementation to a relational database model, as well as services for generating SQL statements.
  • Communication Services
  • Communication services enable an application to transparently interact with other applications regardless of whether they reside on the same computer or on a remote computer. Once a component has been created and its services defined, a method must be established for customers to communicate with the component. The application architecture preferably implements a version of the “Proxy-Skeleton” pattern. This pattern defines two objects to act as the communication handlers between components. FIG. 82 illustrates component interaction overview. A Proxy is a version of the interface that exists in the client's space. This object has a method for each service on the interface that the component wishes to be public. A Skeleton is what a proxy communicates with. A Proxy sends a message across the ORB which is captured by a Skeleton. The Skeleton then forwards the message on to the component.
  • The system also provides customers the ability to upload files from their workstations. File upload services provide an alternative to entering information through a component's user interface. As previously described, component's user interfaces are implemented using applets. Since there are security restrictions imposed on downloaded applets by the browser, it is necessary to implement the Netscape Capabilities application program interfaces (APIs) to upload files. This requires the following: (1) all applets needing access to client files will be signed with a digital signature; (2) applets will utilize the Netscape Capabilities APIs to grant read privileges on the client hard drive; and (3) customers will be given a digital signing certificate and, using Netscape Security, file read permissions will be granted to the certificate.
  • To implement the first requirement, a VeriSign class 3 object signing digital id is preferably used. All applets that will be downloaded to client workstations are packaged in a “.jar” file and signed with this digital id. For the second requirement, Netscape Capabilities API's need to be installed on the web server to support object signing security. The SecurityManager class is used to grant file read permissions within applet code. For the last requirement, all customers are provided with a digital signature so that the identity of downloaded applets can be verified.
  • As previously described, the system's execution environment is implemented using an ORB. The ORB is the foundation for a distributed component solution. At its most basic level, an ORB is used to enable components to communicate with each other regardless of physical location, operating system, and programming language. ORB vendors implement these services using the Common Object Request Broker Architecture (CORBA) as defined by the Object Management Group (OMG). In a preferred embodiment, Inprise's Visibroker ORB product is used.
  • Assuming the system is implemented using the Java programming language, the application needs to work within Java's security standards. One of these security standards is that a customer can only establish and accept network connections from the host that served the applet. This is known as the Java Sandbox. In order to have successful customer—server communication in a distributed component environment within the Java Sandbox, the application architecture uses Visigenic's Gatekeeper product. The Gatekeeper acts as an initial point of connection for all requests. The Gatekeeper knows where to forward requests. Using the Gatekeeper, application components can be distributed without regard to Java Sandbox security restrictions. The Gatekeeper is enhanced with Inprise's SSL Pack. This enables the gatekeeper to encrypt communications between clients and the gatekeeper using the Secured Socket Layer protocol. By using the SSL Pack, all encryption logic is encapsulated and hidden away from the application architecture.
  • Environment Services
  • The environment services provide miscellaneous application and system level services that do not deal directly with managing the user-interface, communicating with other programs, or accessing data. These services are divided into operating system services, runtime services, system services, application services, component framework services, batch scheduling services, and report distribution services which need not be described herein.
  • The system requires a batch architecture as previously described that will support both manual and automated execution of batch processes. The system's batch architecture is preferably comprised of the following products/objects: “Maestro Batch Scheduler, a third party batch scheduler used for the automated kickoff of batch processes according to predefined timetables”; Batch Driver, a Java executable that acts as the interface between Maestro and the batch scheduler component. The driver connects to the batch scheduler component and calls an operation on the component to execute a batch job.
  • The environment services also includes Java's Virtual Machine (JVM) which translates Java bytecodes into machine language commands. At compile time, Java code is compiled from Java syntax into Java bytecode. Bytecode is a protocol that JVM's read at runtime. The JVM translates bytecode at runtime into machine specific commands. The system in this example uses DEC's JVM for the DEC application servers, Sun's JVM for Windows NT for the NT server, Sun's JVM for Solaris for the web servers, and Netscape's JVM for the customers.
  • Transaction Services
  • The transaction services provide the transaction integrity mechanism for the application. This allows all data activities within a single business event to be grouped as a single, logical unit of work. These transaction managers provide sharing of server processes across a large community of customers and can be more efficient than the DBMS. Key transaction services include: transaction monitor services, resource management services, transaction management services and transaction partitioning services. A transaction (or unit of work) is a collection of steps that accomplish a particular business function, such as creating a new customer or settling a market.
  • In terms of a procedural-based application, a single module or program would represent a single transaction. An object-based application is comprised of smaller, more cohesive modules (objects) than procedural-based applications. While this makes for better software characteristics, it makes the job of transaction management more difficult. A transaction management framework for an object-based application should be able to manage multiple transactions, each associated with one to many objects. Each transaction should manage the state of the objects in its domain whether they are new, persisted, changed, or deleted. Finally, the transaction management framework should isolate the functional developer from the technical details of the framework.
  • Business Logic
  • The business logic provides the expression of business rules and procedures (e.g., the steps and rules that govern how a sales order is fulfilled). As such, the business logic includes the control structure that specifies the flow for processing business events and user requests. There are many ways in which to organize business logic, including: rules based, object-oriented, component, structured programming, etc.
  • As is well known, object-oriented architectures, like traditional architectures, use layering to isolate different types of functionality. This simplifies the development environment by shielding complexity, enabling reuse, and sustaining greater consistency, i.e., separation of concern.
  • A common way to separate the concern of the application is to separate the user interface from the business logic. In this framework, a user interface object is used to capture user events, translate them into business messages, and trigger changes to the interface itself. Any business messages that the interface objects needs to send are directed towards its activity object. The activity object models a business unit of work. It exists on a client machine near the user interface objects, captures messages from interface and other activity objects, and either processes those messages or delegates the responsibility to the business components. This “separation of concern” allows the business logic (activity) to be separated from the presentation (user interface, file upload), which enables the reuse of business logic across multiple electronic access channels.
  • In the context of object-oriented programming and distributed object technology, a component is a reusable software building block that can interact with other components on the same computer or a distributed network of computers to form a complete application. A component encapsulates all of the data and behavior associated with a business entity or process. Its public attributes and behaviors are accessible to other components in the federated network. Components are much like large-grained objects. They share many of features of traditional objects, but on a larger scale. Objects are the basis of object-oriented technology.
  • The business objects (instances of classes) and components of the system encapsulate the business logic specific to a given implementation of the system; in this case, the rules and procedures of a particular electricity marketplace. A component or object effectively hides the details of the business logic and the underlying database structure from other components and objects. Components and objects “see” only the interfaces offered by other components or objects, not the objects that realize the component. As a result, the process flow and the business logic associated with a given business entity or process are completely encapsulated within the component, as is the data related to the business entity or process. There are many commercially available components on the market, commonly implemented using Microsoft's ActiveX or Java's Enterprise Java Bean technology.
  • The business components of the present invention share many common features. Each component is preferably implemented as object-oriented classes. In the context of object-oriented technology, classes encapsulate all of the data and behavior associated with finer-grained processes or entities within the business model. An instance of a class is called an object. For example, an instance of the customer class might be labeled as the “ABC Energy Traders Inc.” object. Components are implemented by a collection of classes that have been coded and compiled into bytecode. This bytecode is interpreted at run time by a Java Virtual Machine™ (JVM) or some other just-in-time compiler and translated into instructions that can be interpreted by the processor running the JVM.
  • Those skilled in the art may also realize classes using another object-oriented programming language such as C++ or SmallTalk. Java has been selected as the preferred embodiment of this invention for example purposes only. Components can be further packaged in a single file that can be easily administered and distributed, such as a Java Archive (JAR, i.e., “.jar” file).
  • Business object instances in the system represent critical information relating to the operation of a competitive physical and financial marketplace. Given this high-risk environment, changes in the state of the system will need to be logged for auditing purposes. In addition to audit logging, certain operations will be required to be performed on the system as it existed in a given point in time. This will require some objects to be versioned in a way that they can be reconstructed as they once existed at a specified time. The versioning needs of business objects in the system can be broken into four separate categories: audit enabled, effectivity-enabled, versioned inputs, and versioned outputs. Audit enabled business objects will trigger an entry to an external audit log whenever their state changes. Effectivity-enabled business objects represent the state of some entity over a specified time interval. This time interval may be past, present, or future. These objects allow the system state to be programmed for future times. Versioned input business objects are those that will need to be recreated as they existed at a given point in time. These objects describe a system state that is used as an input to processes that are meant to perform on the system as it existed at some past time. This is different from effectively enabled objects in that objects that are versioned inputs represent different versions of entities that describe the same thing but are described with varying degrees of accuracy at any given point in time. Versioned output objects are those that need to be recreated as they existed in a given point in time and need to provide a basis for how they were created. These objects are created based on a system state that could have existed in the past.
  • The above specification, examples and data provide a complete description of the present invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims (25)

1-41. (canceled)
42. An automated method for the management of an electric power market, comprising:
implementing a set of inter-related automated components relating to the electric power market, the set of automated components comprising a bid component, a settlement component, and a billing component;
implementing a plurality of automated processes for each component contained in the set of inter-related components, the bid component serving as input to the settlement component, the settlement component serving as input to the billing component, the settlement component and billing component having: (i) automated inputs; (ii) automated activities; (iii) and automated outputs;
implementing an automated component flow for each component; and
utilizing the components to automatically manage the electric power market, including: managing bids from buyers and sellers of electric power; calculating settlement positions of the buyers and sellers of electric power; and billing the buyers and sellers of electric power based on the settlement positions.
43. A method according to claim 42, wherein the electric power market comprises multiple markets;
wherein the bid, settlement, and billing components are utilized to automatically manage the multiple markets including managing the bids from buyers and sellers of electric power in the multiple markets; calculating the settlement positions of the buyers and sellers of electric power in the multiple markets; and billing the buyers and sellers of electric power based on the settlement positions in the multiple markets.
44. A method according to claim 42, wherein the bid component comprises bids for a day ahead market.
45. A method according to claim 44, wherein users input the bids to the day ahead market, the bids comprising offers to sells or offers to buy electric power.
46. A method according to claim 45, wherein the bids are for at least one of a plurality of electric power services, the electric power services selected from the group consisting of energy, automatic generation control (AGC), ten minute spinning and non spinning reserve, thirty minute operating reserve, installed capability and operable capability.
47. A method according to claim 42, wherein the settlement component receives scheduling, pricing, and dispatch information from an electrical system operator in order to calculate at least one clearing price.
48. A method according to claim 47, wherein the bid component comprises bids for a day ahead market; and
wherein the settlement component calculates a one day ahead clearing price for the day ahead market.
49. A method according to claim 47, wherein the settlement component calculates a real time clearing price.
50. A method according to claim 47, further comprising a meter reading component for storing meter readings; and
wherein the meter readings from the meter reading component are input to the settlement component in order to calculate the at least one clearing price.
51. A method according to claim 47, further comprising accessing an electrical power market model, the electrical power market model modeling assets, network nodes, and network areas of the electrical power market; and
wherein the settlement component accesses the electrical power market model in order to calculate the at least one clearing price.
52. A method according to claim 42, wherein the billing component outputs information to external financial systems regarding the settlement positions of the buyers and sellers of the electric power.
53. A method according to claim 42, wherein the billing component outputs information to the buyers and sellers of the electric power.
54. An apparatus for the management of an electric power market, the apparatus comprising:
a memory; and
a processor in communication with the memory, the processor configured to
implement a set of inter-related automated components relating to the electric power market, the set of automated components comprising a bid component, a settlement component, and a billing component;
implement a plurality of automated processes for each component contained in the set of inter-related components, the bid component serving as input to the settlement component, the settlement component serving as input to the billing component, the settlement component and billing component having:
(i) automated inputs; (ii) automated activities; (iii) and automated outputs;
implement an automated component flow for each component; and
utilize the components to automatically manage the electric power market, including: managing bids from buyers and sellers of electric power; calculating settlement positions of the buyers and sellers of electric power; and billing the buyers and sellers of electric power based on the settlement positions.
55. An apparatus according to claim 54, wherein the electric power market comprises multiple markets;
wherein the bid, settlement, and billing components are utilized to automatically manage the multiple markets including managing the bids from buyers and sellers of electric power in the multiple markets; calculating the settlement positions of the buyers and sellers of electric power in the multiple markets; and billing the buyers and sellers of electric power based on the settlement positions in the multiple markets.
56. An apparatus according to claim 54, wherein the bid component comprises a day ahead market.
57. An apparatus according to claim 56, wherein users input bids to the day ahead market, the bids comprising offers to sells or offers to buy electric power.
58. An apparatus according to claim 57, wherein the bids are for at least one of a plurality of electric power services, the electric power services selected from the group consisting of energy, automatic generation control (AGC), ten minute spinning and non spinning reserve, thirty minute operating reserve, installed capability and operable capability.
59. An apparatus according to claim 54, wherein the settlement component receives scheduling, pricing, and dispatch information from an electrical system operator in order to calculate at least one clearing price.
60. An apparatus according to claim 59, wherein the bid component comprises a day ahead market; and
wherein the settlement component calculates a one day ahead clearing price.
61. An apparatus according to claim 59, wherein the settlement component calculates a real time clearing price.
62. An apparatus according to claim 59, further comprising a meter reading component for storing meter readings; and
wherein the meter readings from the meter reading component are input to the settlement component in order to calculate the at least one clearing price.
63. An apparatus according to claim 59, further comprising accessing an electrical power market model, the electrical power market modeling assets, network nodes, and network areas of the electrical power market; and
wherein the settlement component accesses the electrical power market model in order to calculate the at least one clearing price.
64. An apparatus according to claim 42, wherein the billing component outputs information to external financial systems regarding the settlement positions of the buyers and sellers of the electric power.
65. An apparatus according to claim 54, wherein the billing component outputs information to the buyers and sellers of the electric power.
US12/397,192 1999-10-20 2009-03-03 Method and system for facilitating, coordinating and managing a competitive marketplace Abandoned US20090187501A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/397,192 US20090187501A1 (en) 1999-10-20 2009-03-03 Method and system for facilitating, coordinating and managing a competitive marketplace

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/421,713 US7085739B1 (en) 1999-10-20 1999-10-20 Method and system for facilitating, coordinating and managing a competitive marketplace
US11/494,089 US8032461B2 (en) 1999-10-20 2006-07-27 Method and system for facilitating, coordinating and managing a competitive marketplace
US12/397,192 US20090187501A1 (en) 1999-10-20 2009-03-03 Method and system for facilitating, coordinating and managing a competitive marketplace

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/494,089 Continuation US8032461B2 (en) 1999-10-20 2006-07-27 Method and system for facilitating, coordinating and managing a competitive marketplace

Publications (1)

Publication Number Publication Date
US20090187501A1 true US20090187501A1 (en) 2009-07-23

Family

ID=36710653

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/421,713 Expired - Lifetime US7085739B1 (en) 1999-10-20 1999-10-20 Method and system for facilitating, coordinating and managing a competitive marketplace
US11/494,089 Expired - Fee Related US8032461B2 (en) 1999-10-20 2006-07-27 Method and system for facilitating, coordinating and managing a competitive marketplace
US12/397,192 Abandoned US20090187501A1 (en) 1999-10-20 2009-03-03 Method and system for facilitating, coordinating and managing a competitive marketplace

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US09/421,713 Expired - Lifetime US7085739B1 (en) 1999-10-20 1999-10-20 Method and system for facilitating, coordinating and managing a competitive marketplace
US11/494,089 Expired - Fee Related US8032461B2 (en) 1999-10-20 2006-07-27 Method and system for facilitating, coordinating and managing a competitive marketplace

Country Status (1)

Country Link
US (3) US7085739B1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090222371A1 (en) * 2008-03-03 2009-09-03 Arthur Miller Method of energy procurement and system for employing
US20130080552A1 (en) * 2005-04-04 2013-03-28 Jay D. Logue Federated Challenge Credit System
US8949943B2 (en) 2003-12-19 2015-02-03 Facebook, Inc. Messaging systems and methods
US9633357B2 (en) 2010-09-29 2017-04-25 Hewlett Packard Enterprise Development Lp Net utility determination based on product replacement and service plan coverage decisions
US20170200238A1 (en) * 2016-01-08 2017-07-13 Avion Energy, Inc. Aggregation of bids from multiple energy providers
US11574348B2 (en) * 2019-06-07 2023-02-07 Mitel Networks Corporation Job-specific contact center generation

Families Citing this family (112)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6598029B1 (en) * 1997-02-24 2003-07-22 Geophonic Networks, Inc. Bidding for energy supply with request for service
US7835973B2 (en) * 1999-10-20 2010-11-16 Accenture Global Services Limited Spot market clearing
US7085739B1 (en) * 1999-10-20 2006-08-01 Accenture Llp Method and system for facilitating, coordinating and managing a competitive marketplace
US6700590B1 (en) * 1999-11-01 2004-03-02 Indx Software Corporation System and method for retrieving and presenting data using class-based component and view model
AU762794B2 (en) 1999-12-22 2003-07-03 Bgc Partners, Inc. Systems and methods for providing a trading interface
US7165052B2 (en) * 2001-03-31 2007-01-16 First Data Corporation Payment service method and system
US20040210541A1 (en) * 2001-05-04 2004-10-21 Jeremy Epstien User interface for a rules engine and methods therefor
US7584425B2 (en) * 2001-07-31 2009-09-01 Verizon Business Global Llc Systems and methods for generating reports
US7127271B1 (en) 2001-10-18 2006-10-24 Iwao Fujisaki Communication device
US7107081B1 (en) 2001-10-18 2006-09-12 Iwao Fujisaki Communication device
US10354322B2 (en) * 2001-10-18 2019-07-16 Bgc Partners, Inc. Two sided trading orders
US7466992B1 (en) 2001-10-18 2008-12-16 Iwao Fujisaki Communication device
US20040049518A1 (en) * 2001-10-22 2004-03-11 Finlab Sa Historical data recording and visualizing system and method
US7324977B2 (en) * 2001-12-07 2008-01-29 Siemens Power Transmission & Distribution, Inc. Historical database system for resolving energy imbalance requirements in real-time
US20030110118A1 (en) * 2001-12-11 2003-06-12 Jan Tilfors Method and a system for trading energy contracts in an exchange
US8046238B2 (en) * 2001-12-20 2011-10-25 Accenture Global Services Limited Business transaction management
US7783529B2 (en) * 2002-04-10 2010-08-24 Combinenet, Inc. Market clearability in combinatorial auctions and exchanges
US9569797B1 (en) 2002-05-30 2017-02-14 Consumerinfo.Com, Inc. Systems and methods of presenting simulated credit score information
US7610229B1 (en) 2002-05-30 2009-10-27 Experian Information Solutions, Inc. System and method for interactively simulating a credit-worthiness score
US7593891B2 (en) 2003-05-30 2009-09-22 Experian Scorex Llc Credit score simulation
WO2003105010A1 (en) 2002-06-06 2003-12-18 Neoteris, Inc. Method and system for providing secure access to private networks
US7409360B1 (en) * 2002-10-08 2008-08-05 Public Service Electric & Gas Company Method and system for computer-based auctioning of basic generation services
US8229512B1 (en) 2003-02-08 2012-07-24 Iwao Fujisaki Communication device
US8241128B1 (en) 2003-04-03 2012-08-14 Iwao Fujisaki Communication device
US7321810B2 (en) * 2003-05-13 2008-01-22 Siemens Power Transmission & Distribution, Inc. Method of dynamic economic dispatch
US7454270B2 (en) * 2003-05-13 2008-11-18 Siemens Power Transmission & Distribution, Inc. Dynamic economic dispatch for the management of a power distribution system
US7437323B1 (en) * 2003-06-25 2008-10-14 Pros Revenue Management; L.P. Method and system for spot pricing via clustering based demand estimation
US7580817B2 (en) * 2003-08-20 2009-08-25 New Energy Options, Inc. Method and system for predicting solar energy production
US7873602B2 (en) * 2003-09-03 2011-01-18 International Business Machines Corporation Apparatus and method for maintaining databases on application servers
US8090402B1 (en) 2003-09-26 2012-01-03 Iwao Fujisaki Communication device
US7917167B1 (en) 2003-11-22 2011-03-29 Iwao Fujisaki Communication device
US8041348B1 (en) 2004-03-23 2011-10-18 Iwao Fujisaki Communication device
US8732004B1 (en) 2004-09-22 2014-05-20 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
US8208954B1 (en) 2005-04-08 2012-06-26 Iwao Fujisaki Communication device
US8296649B2 (en) * 2005-05-31 2012-10-23 Sorenson Media, Inc. Method, graphical interface and computer-readable medium for generating a preview of a reformatted preview segment
US7975219B2 (en) * 2005-05-31 2011-07-05 Sorenson Media, Inc. Method, graphical interface and computer-readable medium for reformatting data
US7885979B2 (en) * 2005-05-31 2011-02-08 Sorenson Media, Inc. Method, graphical interface and computer-readable medium for forming a batch job
US7908243B2 (en) * 2005-11-25 2011-03-15 Oracle International Corporation Considering transient data also in reports generated based on data eventually stored in a data-warehouse
WO2007065135A2 (en) * 2005-11-30 2007-06-07 Alternative Energy Systems Consulting, Inc. Agent based auction system and method for allocating distributed energy resources
US7711636B2 (en) 2006-03-10 2010-05-04 Experian Information Solutions, Inc. Systems and methods for analyzing data
EP1850245A1 (en) * 2006-04-28 2007-10-31 Sap Ag Systems and methods for providing a generic audit trail service
US8799148B2 (en) 2006-08-31 2014-08-05 Rohan K. K. Chandran Systems and methods of ranking a plurality of credit card offers
US11887175B2 (en) 2006-08-31 2024-01-30 Cpl Assets, Llc Automatically determining a personalized set of programs or products including an interactive graphical user interface
US8036979B1 (en) 2006-10-05 2011-10-11 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US8606666B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US8606626B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US8559983B1 (en) 2007-05-03 2013-10-15 Iwao Fujisaki Communication device
US7890089B1 (en) 2007-05-03 2011-02-15 Iwao Fujisaki Communication device
US10395288B2 (en) 2007-07-03 2019-08-27 Collabra Technology, Inc. Methods and systems for a private market: facilitating connections between buyers and sellers or exchangers of products and services while maintaining privacy
US8676273B1 (en) 2007-08-24 2014-03-18 Iwao Fujisaki Communication device
US8805552B2 (en) 2007-08-28 2014-08-12 Causam Energy, Inc. Method and apparatus for actively managing consumption of electric power over an electric power grid
US9177323B2 (en) 2007-08-28 2015-11-03 Causam Energy, Inc. Systems and methods for determining and utilizing customer energy profiles for load control for individual structures, devices, and aggregation of same
US9130402B2 (en) 2007-08-28 2015-09-08 Causam Energy, Inc. System and method for generating and providing dispatchable operating reserve energy capacity through use of active load management
US8806239B2 (en) 2007-08-28 2014-08-12 Causam Energy, Inc. System, method, and apparatus for actively managing consumption of electric power supplied by one or more electric power grid operators
BRPI0705569A2 (en) * 2007-09-11 2009-05-05 Univ Minas Gerais method for measurement and monitoring
EP2188879A1 (en) * 2007-09-21 2010-05-26 Siemens Aktiengesellschaft Decentralized energy system and method for distributing energy in a decentralized energy system
US9690820B1 (en) 2007-09-27 2017-06-27 Experian Information Solutions, Inc. Database system for triggering event notifications based on updates to database records
US20090089430A1 (en) * 2007-09-28 2009-04-02 Jamie Serra Alternative fuels resource allocation system
US8639214B1 (en) 2007-10-26 2014-01-28 Iwao Fujisaki Communication device
US8472935B1 (en) 2007-10-29 2013-06-25 Iwao Fujisaki Communication device
US7996521B2 (en) 2007-11-19 2011-08-09 Experian Marketing Solutions, Inc. Service for mapping IP addresses to user segments
US7676424B2 (en) * 2007-11-20 2010-03-09 Dc Energy Llc Auction for financially settled contracts
US7873564B1 (en) 2007-11-20 2011-01-18 Dc Energy Llc Computer system for an auction exchange for financially settled contracts
US7991686B1 (en) 2007-11-20 2011-08-02 Dc Energy Llc Computer system for an auction exchange for financially settled contracts
US8744720B1 (en) 2007-12-27 2014-06-03 Iwao Fujisaki Inter-vehicle middle point maintaining implementer
US8543157B1 (en) 2008-05-09 2013-09-24 Iwao Fujisaki Communication device which notifies its pin-point location or geographic area in accordance with user selection
KR20090126104A (en) * 2008-06-03 2009-12-08 서울대학교산학협력단 Method and system for demand response of electric power
US8340726B1 (en) 2008-06-30 2012-12-25 Iwao Fujisaki Communication device
US8452307B1 (en) 2008-07-02 2013-05-28 Iwao Fujisaki Communication device
US20100023376A1 (en) * 2008-07-28 2010-01-28 Brown Stephen J Iterative real-time auction for resource management with user rules
US8639392B2 (en) 2008-09-29 2014-01-28 Battelle Memorial Institute Electric power grid control using a market-based resource allocation system
US20100121752A1 (en) * 2008-11-12 2010-05-13 Banigan Michael H Web-Based Bid Analysis, Award, and Contract Management System
US20100174638A1 (en) 2009-01-06 2010-07-08 ConsumerInfo.com Report existence monitoring
WO2010081165A2 (en) * 2009-01-12 2010-07-15 Battelle Memorial Institute Nested, hierarchical resource allocation schema for management and control of an electric power grid
US20110029352A1 (en) * 2009-07-31 2011-02-03 Microsoft Corporation Brokering system for location-based tasks
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US8869307B2 (en) * 2010-11-19 2014-10-21 Mobile Iron, Inc. Mobile posture-based policy, remediation and access control for enterprise resources
US9589297B2 (en) 2011-04-28 2017-03-07 Battelle Memorial Institute Preventing conflicts among bid curves used with transactive controllers in a market-based resource allocation system
US9245297B2 (en) * 2011-04-28 2016-01-26 Battelle Memorial Institute Forward-looking transactive pricing schemes for use in a market-based resource allocation system
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
WO2013138738A1 (en) * 2012-03-16 2013-09-19 Parsons Corporation Decision support system
US20180246479A1 (en) * 2012-06-29 2018-08-30 Accion Power, LLC Method and apparatus for strategic energy selection
US20140006201A1 (en) * 2012-06-29 2014-01-02 Accion Group Inc. Method and apparatus for competitive solicitation and bidding
US10861112B2 (en) 2012-07-31 2020-12-08 Causam Energy, Inc. Systems and methods for advanced energy settlements, network-based messaging, and applications supporting the same on a blockchain platform
US9513648B2 (en) 2012-07-31 2016-12-06 Causam Energy, Inc. System, method, and apparatus for electric power grid and network management of grid elements
US8849715B2 (en) 2012-10-24 2014-09-30 Causam Energy, Inc. System, method, and apparatus for settlement for participation in an electric power grid
US8983669B2 (en) 2012-07-31 2015-03-17 Causam Energy, Inc. System, method, and data packets for messaging for electric power grid elements over a secure internet protocol network
US10311416B2 (en) 2014-10-22 2019-06-04 Causam Energy, Inc. Systems and methods for advanced energy settlements, network-based messaging, and applications supporting the same
US10475138B2 (en) 2015-09-23 2019-11-12 Causam Energy, Inc. Systems and methods for advanced energy network
US20140081815A1 (en) * 2012-09-20 2014-03-20 Joe Miller Process and System for Synchronizing Data From a Meter Collection Database to a Billing Database
DE102012221291A1 (en) * 2012-11-21 2014-05-22 Siemens Aktiengesellschaft Multi-modal network and method for distributing resources in a multi-modal network
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
CA2837414C (en) 2012-12-14 2022-12-13 Battelle Memorial Institute Transactive control and coordination framework and associated toolkit functions
US9762060B2 (en) 2012-12-31 2017-09-12 Battelle Memorial Institute Distributed hierarchical control architecture for integrating smart grid assets during normal and disrupted operations
US9299107B2 (en) * 2013-03-13 2016-03-29 Convergent Energy + Power System and method for managing the charging and discharging of an energy storage device
US9870589B1 (en) 2013-03-14 2018-01-16 Consumerinfo.Com, Inc. Credit utilization tracking and reporting
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US10073553B2 (en) 2014-09-22 2018-09-11 Google Llc Scripting cross-device wearable interaction
US10210568B2 (en) 2014-09-26 2019-02-19 Battelle Memorial Institute Coordination of thermostatically controlled loads with unknown parameters
US10445152B1 (en) 2014-12-19 2019-10-15 Experian Information Solutions, Inc. Systems and methods for dynamic report generation based on automatic modeling of complex data structures
US10360184B2 (en) * 2015-06-24 2019-07-23 International Business Machines Corporation Log file analysis to locate anomalies
US11410230B1 (en) 2015-11-17 2022-08-09 Consumerinfo.Com, Inc. Realtime access and control of secure regulated data
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US11227001B2 (en) 2017-01-31 2022-01-18 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US20180225684A1 (en) * 2017-02-03 2018-08-09 General Electric Company Strategic operation of variable generation power plants
US11159044B2 (en) 2017-07-14 2021-10-26 Battelle Memorial Institute Hierarchal framework for integrating distributed energy resources into distribution systems
US10971932B2 (en) 2018-03-21 2021-04-06 Battelle Memorial Institute Control approach for power modulation of end-use loads
US10963433B2 (en) * 2018-08-17 2021-03-30 International Business Machines Corporation ASCII based instant object oriented schema generation
US20200074541A1 (en) 2018-09-05 2020-03-05 Consumerinfo.Com, Inc. Generation of data structures based on categories of matched data items
US11361392B2 (en) 2018-11-01 2022-06-14 Battelle Memorial Institute Flexible allocation of energy storage in power grids
US11451061B2 (en) 2018-11-02 2022-09-20 Battelle Memorial Institute Reconfiguration of power grids during abnormal conditions using reclosers and distributed energy resources
CN112579683A (en) * 2020-12-30 2021-03-30 广州华资软件技术有限公司 Method for efficiently accessing Tbase data in batches

Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5710887A (en) * 1995-08-29 1998-01-20 Broadvision Computer system and method for electronic commerce
US5758331A (en) * 1994-08-15 1998-05-26 Clear With Computers, Inc. Computer-assisted sales system for utilities
US5794219A (en) * 1996-02-20 1998-08-11 Health Hero Network, Inc. Method of conducting an on-line auction with bid pooling
US5794212A (en) * 1996-04-10 1998-08-11 Dominion Resources, Inc. System and method for providing more efficient communications between energy suppliers, energy purchasers and transportation providers as necessary for an efficient and non-discriminatory energy market
US5873071A (en) * 1997-05-15 1999-02-16 Itg Inc. Computer method and system for intermediated exchange of commodities
US5974403A (en) * 1997-07-21 1999-10-26 International Business Machines Corporation Power trading and forecasting tool
US6021402A (en) * 1997-06-05 2000-02-01 International Business Machines Corporaiton Risk management system for electric utilities
US6115698A (en) * 1995-08-18 2000-09-05 Continental Power Exchange, Inc. Apparatus and method for trading electric energy
US6285989B1 (en) * 1998-08-07 2001-09-04 Ariba, Inc. Universal on-line trading market design and deployment system
US6321212B1 (en) * 1999-07-21 2001-11-20 Longitude, Inc. Financial products having a demand-based, adjustable return, and trading exchange therefor
US6343277B1 (en) * 1998-11-02 2002-01-29 Enermetrix.Com, Inc. Energy network commerce system
US20020013631A1 (en) * 1997-07-23 2002-01-31 H. Van Dyke Parunak Computerized system for market-based constraint optimization
US6347274B2 (en) * 2000-02-28 2002-02-12 Hitachi, Ltd. Vehicular travel control system
US20050034023A1 (en) * 2002-12-16 2005-02-10 Maturana Francisco P. Energy management system
US6876982B1 (en) * 1996-02-19 2005-04-05 Lancaster Australia Pty Limited Universal contract exchange
US20060265323A1 (en) * 1999-10-20 2006-11-23 Accenture Llp Method and system for facilitating, coordinating and managing a competitive marketplace
US7249027B1 (en) * 1996-01-04 2007-07-24 Efficient Auctions Llc Computer implemented methods and apparatus for auctions
US7882016B2 (en) * 2003-12-19 2011-02-01 North American Energy Credit And Clearing Corp. Utilizing cash flow contracts and physical collateral for energy-related clearing and credit enhancement platforms

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6047274A (en) * 1997-02-24 2000-04-04 Geophonic Networks, Inc. Bidding for energy supply
US7010511B1 (en) * 1999-03-31 2006-03-07 Kinney Jr Sam E Method and system for conducting electronic auctions with net present value bidding

Patent Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758331A (en) * 1994-08-15 1998-05-26 Clear With Computers, Inc. Computer-assisted sales system for utilities
US6115698A (en) * 1995-08-18 2000-09-05 Continental Power Exchange, Inc. Apparatus and method for trading electric energy
US5710887A (en) * 1995-08-29 1998-01-20 Broadvision Computer system and method for electronic commerce
US7249027B1 (en) * 1996-01-04 2007-07-24 Efficient Auctions Llc Computer implemented methods and apparatus for auctions
US6876982B1 (en) * 1996-02-19 2005-04-05 Lancaster Australia Pty Limited Universal contract exchange
US5794219A (en) * 1996-02-20 1998-08-11 Health Hero Network, Inc. Method of conducting an on-line auction with bid pooling
US5794212A (en) * 1996-04-10 1998-08-11 Dominion Resources, Inc. System and method for providing more efficient communications between energy suppliers, energy purchasers and transportation providers as necessary for an efficient and non-discriminatory energy market
US5873071A (en) * 1997-05-15 1999-02-16 Itg Inc. Computer method and system for intermediated exchange of commodities
US6021402A (en) * 1997-06-05 2000-02-01 International Business Machines Corporaiton Risk management system for electric utilities
US5974403A (en) * 1997-07-21 1999-10-26 International Business Machines Corporation Power trading and forecasting tool
US20020013631A1 (en) * 1997-07-23 2002-01-31 H. Van Dyke Parunak Computerized system for market-based constraint optimization
US6285989B1 (en) * 1998-08-07 2001-09-04 Ariba, Inc. Universal on-line trading market design and deployment system
US6343277B1 (en) * 1998-11-02 2002-01-29 Enermetrix.Com, Inc. Energy network commerce system
US6321212B1 (en) * 1999-07-21 2001-11-20 Longitude, Inc. Financial products having a demand-based, adjustable return, and trading exchange therefor
US20060265323A1 (en) * 1999-10-20 2006-11-23 Accenture Llp Method and system for facilitating, coordinating and managing a competitive marketplace
US6347274B2 (en) * 2000-02-28 2002-02-12 Hitachi, Ltd. Vehicular travel control system
US20050034023A1 (en) * 2002-12-16 2005-02-10 Maturana Francisco P. Energy management system
US7882016B2 (en) * 2003-12-19 2011-02-01 North American Energy Credit And Clearing Corp. Utilizing cash flow contracts and physical collateral for energy-related clearing and credit enhancement platforms

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Business Editors. (8 December). Los Angeles Department of Water and Power Begins Trading on California Power Exchange. Business Wire,1. Retrieved February 5, 2012, from Business Dateline. (Document ID: 36617495). *
Enron Corp. $250 Million Notes Rated `BBB+' by Fitch IBCA -Fitch IBCA -. (25 November). PR Newswire,1. Retrieved February 6, 2012, from Business Dateline. (Document ID: 36277391). *
Publication title: Arizona Daily StarPages: 1GNumber of pages: 0Publication year: 1993Publication date: Oct 3, 1993Publisher: The Arizona Daily StarPlace of publication: Tucson, Ariz. Country of publication: United States Publication subject: General Interest Periodicals--United States ISSN: 0888546X *
Rose, Judah, & Mann, Charles. (1996, February). Price risk management: Electric power vs. natural gas. Public Utilities Fortnightly, 134(3), 24. Retrieved February 5, 2012, from ABI/INFORM Global. (Document ID: 9161070). *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8949943B2 (en) 2003-12-19 2015-02-03 Facebook, Inc. Messaging systems and methods
US10469471B2 (en) 2003-12-19 2019-11-05 Facebook, Inc. Custom messaging systems
US20130080552A1 (en) * 2005-04-04 2013-03-28 Jay D. Logue Federated Challenge Credit System
US8713175B2 (en) * 2005-04-04 2014-04-29 Facebook, Inc. Centralized behavioral information system
US20090222371A1 (en) * 2008-03-03 2009-09-03 Arthur Miller Method of energy procurement and system for employing
US7853516B2 (en) * 2008-03-03 2010-12-14 Direct Energy Business, Llc Method of energy procurement and system for employing
US9633357B2 (en) 2010-09-29 2017-04-25 Hewlett Packard Enterprise Development Lp Net utility determination based on product replacement and service plan coverage decisions
US20170200238A1 (en) * 2016-01-08 2017-07-13 Avion Energy, Inc. Aggregation of bids from multiple energy providers
US11574348B2 (en) * 2019-06-07 2023-02-07 Mitel Networks Corporation Job-specific contact center generation

Also Published As

Publication number Publication date
US20060265323A1 (en) 2006-11-23
US7085739B1 (en) 2006-08-01
US8032461B2 (en) 2011-10-04

Similar Documents

Publication Publication Date Title
US8032461B2 (en) Method and system for facilitating, coordinating and managing a competitive marketplace
US11636413B2 (en) Autonomic discrete business activity management method
US7418424B2 (en) Trade finance automation system
US8065219B2 (en) System architecture and method for energy industry trading and transaction management
US7640213B2 (en) System and method providing rules driven subscription event processing
US8312416B2 (en) Software model business process variant types
US20020103660A1 (en) Generic transaction server
US20020046053A1 (en) Web based risk management system and method
US8412614B2 (en) System and method for electrical power derivatives
US7860749B2 (en) Method, medium and system for customizable homepages for network-based auctions
US7783520B2 (en) Methods of accessing information for listing a product on a network based auction service
US20060004648A1 (en) Method and system for using templates for enhanced network-based auctions
US20060004649A1 (en) Method and system for a failure recovery framework for interfacing with network-based auctions
US7788160B2 (en) Method and system for configurable options in enhanced network-based auctions
US20050234803A1 (en) Method and system for verifying quantities for enhanced network-based auctions
Muth et al. What workflow technology can do for electronic commerce
Papazoglou et al. Distributed, interoperable workflow support for electronic commerce
KR102311511B1 (en) Open market system with enhanced security by applying blockchain
Walker et al. Planning a revenue stream system in an e‐business environment
WO2001042950A2 (en) Order management system
Keyes A Portfolio Management System for the Twenty-First Century............................................ Tim Scatliff
US20150317738A1 (en) Computerized method and system for secure communication, and method and system for matching customers with options for investment
Tan Hardware e-Inventory management system/Tan Kit Huang
Scatliff A Portfolio Management System for the Twenty-First Century
EP1242904A1 (en) System for facilitating transactions on an exchange

Legal Events

Date Code Title Description
AS Assignment

Owner name: ANDERSEN CONSULTING LLP,ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WINTER, LARRY A.;SHIELDS, FRANCIS X.;NORTHCUTT, ROBERT L.;SIGNING DATES FROM 20000104 TO 20000201;REEL/FRAME:024560/0683

Owner name: ACCENTURE LLP,ILLINOIS

Free format text: CHANGE OF NAME;ASSIGNOR:ANDERSEN CONSULTING LLP;REEL/FRAME:024562/0210

Effective date: 20010102

Owner name: ANDERSEN CONSULTING LLP, ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WINTER, LARRY A.;SHIELDS, FRANCIS X.;NORTHCUTT, ROBERT L.;SIGNING DATES FROM 20000104 TO 20000201;REEL/FRAME:024560/0683

Owner name: ACCENTURE LLP, ILLINOIS

Free format text: CHANGE OF NAME;ASSIGNOR:ANDERSEN CONSULTING LLP;REEL/FRAME:024562/0210

Effective date: 20010102

AS Assignment

Owner name: ACCENTURE GLOBAL SERVICES GMBH, SWITZERLAND

Free format text: CONFIRMATORY ASSIGNMENT;ASSIGNOR:ACCENTURE LLP;REEL/FRAME:024946/0971

Effective date: 20100831

AS Assignment

Owner name: ACCENTURE GLOBAL SERVICES LIMITED, IRELAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ACCENTURE GLOBAL SERVICES GMBH;REEL/FRAME:025700/0287

Effective date: 20100901

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION