WO2001098787A2

WO2001098787A2 - Tariff generation, invoicing and contract management

Info

Publication number: WO2001098787A2
Application number: PCT/NZ2001/000116
Authority: WO
Inventors: Simon Venn Young; Andrew Bryan Philpott
Original assignee: Jimmi Limited
Priority date: 2000-06-22
Filing date: 2001-06-22
Publication date: 2001-12-27
Also published as: AU2001267953B2; CA2413007A1; WO2001098787A8; US20090307059A1; EP1297345A2; US20040030646A1; AU6795301A; US7949555B2

Abstract

A computer-implemented method of supplying a tariff to a tariff recipient, the method comprising the steps of: a) receiving one or more cost curves from one or more suppliers, each cost curve being indicative of variations in the cost of a product or service expected by a respective associated supplier over time; b) receiving a load curve, the load curve being indicative of expected variations in consumption of the product or service over time; c) calculating a tariff from the load curve received in step b) and the cost curve received in step a) in accordance with a predetermined algorithm; and d) transmitting the tariff calculated in step c) to the tariff recipient.

Description

TARIFF GENERATION, INVOICING AND CONTRACT MANAGEMENT

The present invention relates to a system for calculating and transmitting tariffs to tariff recipients. The system is able to be deployed in a computer network environment. The invention also relates to improvements in invoicing and contract management.

The invention can be used in connection with the supply of a variety of products or services, such as electricity, water, gas or mobile phone or internet usage. These products are typically associated with network industries. This application provides detailed examples as to how it could be applied in the electricity industry.

In the newly deregulated electricity market it is becoming increasingly important for electricity purchasers to 'shop around' amongst a number of electricity suppliers in order to find the best deal.

One method of doing this is a 'reverse auction'. In a reverse auction, a Request For Proposal (RFP) from the purchaser is sent to a number of suppliers who review the RFP, and submit bids to the purchaser. The purchaser can then review the rival bids, and select one of the suppliers accordingly.

A problem with a conventional reverse auction is that it can be difficult for the purchaser to make meaningful comparisons between the rival bids, each of which may involve different conditions and pricing structures. As a result the purchaser may choose a bid which turns out to be more expensive than other bids. It is an object of the present invention to address this problem, or at least to provide the public with a useful alternative.

A first aspect of the invention provides a computer-implemented method of supplying a tariff to a tariff recipient, the method comprising the steps of: a) receiving one or more cost curves from one or more suppliers, each cost curve being indicative of variations in the cost of an associated product or service expected by a respective associated supplier over time; b) receiving a load curve, the load curve being indicative of expected variations in consumption of the product or service over time; c) calculating a tariff from the load curve received in step b) and the cost curve received in step a) in accordance with a predetermined algorithm; and d) transmitting the tariff calculated in step c) to the tariff recipient.

By calculating the tariff on the basis of the cost curve and the load curve, the invention enables the tariff recipient to easily compare a number of tariffs received from one or more sources.

The invention may be used to calculate a tariff for a product such as electricity, gas or water, or may be used to calculate a tariff for a service such as mobile telephone or internet useage. The invention will be described below with reference to electricity tariffs, but it will be understood that the invention is equally useful for other products or services.

The method of the first aspect of the invention is typically performed by a central processor, which may be distributed over a number of physical locations.

Typically the tariff is displayed to the tariff recipient, for instance on a computer screen or in a hard printout.

The supplier may be one of a variety of entities - for instance a generator, marketer or retailer of the product or service. The tariff recipient may be a purchaser, such as the ultimate end-user of the product or service, or may be a marketer or retailer. Alternatively the tariff recipient may be some intermediary, such as a client or a buying group which aggregates a number of individual load curves into one large one.

In its most general form the algorithm can be considered as a 'black box' type algorithm which receives a load curve and a cost curve as inputs, and outputs the tariff. In the preferred form described herein, the algorithm is described in terms of a set of mathematical models incorporating certain business rules. The business rules may relate to creation of a tariff by a supplier, and may also relate to charges associated with lines charges. The mathematical model may also include business rules associated with the structure of a tariff across time, i.e. the number and duration of fixed billing 'buckets' of time during a desired contract period. The contract period is the period of time in which a contract to supply is being sought. The algorithm is typically transmitted to the central processor before a tariff is created, and may be stored by the central processor. This enables the algorithm to be formulated by the supplier (possibly with input from the tariff recipient and/or other third parties) before being transmitted to the central processor.

The algorithm typically includes the step of multiplying together the cost curve and the load curve.

The algorithm typically includes a minimisation step. For instance in one of the mathematical models described below, a revenue curve (comprising a plurality of revenue values) is generated by multiplying together the load curve and the cost curve, and the sum of the revenue values is minimised (subject to certain constraints).

Typically the algorithm is transmitted to the tariff recipient. The algorithm may be transmitted with the tariff, or may have been previously formulated with input from the tariff recipient. This ensures that the process is completely transparent - ie the tariff recipient can review the algorithm and determine how a respective tariff has been calculated.

The cost curve may be an equation which functionally describes the variation in cost over a particular time period. However preferably the cost curve comprises a plurality of cost curve data values. The cost curve data values may include buy rate values which represent the cost expected by the supplier for supplying the product or service. For example in the case of an electricity tariff mechanism, these buy rate values may be obtained from expected electricity spot market values.

The load curve may also be represented by an equation which describes variation in expected consumption across the contract period. However preferably the load curve comprises a plurality of expected load data values. Each expected load data value is typically indicative of the amount of product or service expected to be consumed during a respective time period. The expected load data values may be absolute values (e.g. MWh) or may be normalised values (e.g. percentage values). Typically the load curve is received from the tariff recipient. However in some cases the load curve may be received from a source other than the tariff recipient. For instance the load curve may be received from a buying group and the tariff transmitted to an end user.

At a minimum, the method of the first aspect of the tariff setting mechanism will be only performed once - ie a single supplier submits a single cost curve, and a single tariff recipient submits a single load curve.

Alternatively a single supplier may submit a plurality of cost curves and the tariff recipient can choose between the different tariffs, each tariff having been calculated using a respective different cost curve. In this case the method typically includes the additional step of: e) receiving a cost curve identifier which identifies a cost curve for use in step c) .

Preferably a plurality of suppliers each submit at least one cost curve and the tariff recipient can choose between the different tariffs calculated for each supplier. Alternatively a tariff (eg the lowest cost tariff) may be selected by the central processor, or by the tariff recipient's computer. Typically the method includes the additional step of: f) receiving a supplier identifier which identifies at least one of the suppliers, wherein a cost curve associated with the supplier identified in step f) is used to calculate the tariff in step c).

Typically step b) (receiving the load curve) is performed after step a) (receiving the cost curve). That is - the supplier submits the cost curve first without reference to a particular load curve. This can be contrasted with a reverse auction in which the supplier submits a bid in response to receipt of an RFP, which may or may not contain a load curve, from a tariff recipient. One advantage of receiving the cost curve first is that this makes the process "front-end empowering'. In other words, it enables the tariff recipient to control the rate they will be charged by suitable manipulation of their tariff structure, as set out below in the second aspect of the invention. Another advantage of receiving the cost curve first is that it reduces the time lag between the tariff recipient submitting a load curve and receiving a tariff. In a conventional reverse auction the time lag between submitting an RFP and receiving a bid can be a matter of weeks.

Preferably the cost curve is saved in a store after it has been received in step a), and then retrieved from the store prior to, or during, the tariff calculation step c) . However this is not essential, for instance a supplier may submit a continuous stream of cost curve data values which do not need to be stored but are updated continuously through links to electricity financial markets such as the New York Mercantile Exchange.

A second aspect of the tariff setting mechanism provides a computer implemented method of obtaining a tariff, the method comprising the steps of: a) transmitting a first load curve to a central processor, the first load curve being indicative of expected variations in consumption of a product or service expected over time; b) receiving a first tariff from the central processor, the first tariff being associated with the first load curve; c) transmitting a second load curve to the central processor, the second load curve being indicative of expected variations in consumption of a product or service over time; d) receiving a second tariff from the central processor, the second tariff being associated with the second load curve; e) selecting the first tariff or the second tariff; and f) transmitting a contract acceptance, the contract acceptance indicating which tariff has been accepted in step e).

The second aspect of the invention relates to the steps (typically carried out at the tariff recipient's computer) involved in selecting a preferred tariff, and setting up a contract with the supplier associated with the selected tariff.

The tariff recipient submits a number of different load curves, or aggregated load curves, and selects (or has selected for them by their computer or by the central processor) a preferred one of the tariffs. The load curves may be transmitted simultaneously, or alternatively the tariff recipient may submit the first load curve; review the first tariff, calculate the second load curve in response to the first tariff, and so on. In this way the tariff recipient can iteratively input their load curves to achieve an optimal tariff.

A problem with the "front-end empowering" nature of the invention is that the tariff recipient may submit a load curve which does not accurately reflect actual consumption during the contract period for which the tariff may have been created.

In accordance with a third aspect of the invention there is provided a computer implemented method of invoicing for the provision of a product or service, the method comprising: a) monitoring consumption of the product or service; b) invoicing in accordance with the monitored consumption and a tariff; c) calculating an expected profit value in accordance with the monitored consumption; d) calculating an actual profit value in accordance with the monitored consumption; e) making a surcharge if the expected profit value exceeds the actual profit value; and f) making a refund if the actual profit value exceeds the expected profit value.

The third aspect of the invention provides a means of dealing with load misrepresentation, by charging or refunding any shortfall/surplus.

According to a fourth aspect of the invention there is provided a computer implemented method of establishing a contract between a supplier and a tariff recipient for the provision of a product or service, the method comprising the steps of: a) supplying an tariff to the tariff recipient by a method according to the first aspect of the invention b) receiving a contract acceptance from the tariff recipient, the contract acceptance identifying a supplier; c) transmitting a contract confirmation to the tariff recipient to acknowledge receipt of the contract acceptance in step b); and d) forwarding the contract acceptance to the supplier identified in the contract acceptance.

The fourth aspect of the invention provides the additional feature of contract management. That is, the central processor acts as an intermediary between the supplier and tariff recipient in a contract acceptance routine. According to a fifth aspect of the invention there is provided a method of invoicing a tariff recipient for the provision of a product or service, the method comprising establishing a contract with a tariff recipient by a method according to the fourth aspect of the invention; monitoring consumption of the product or service during a contract period; and invoicing the tariff recipient in accordance with the tariff previously supplied to the tariff recipient in step a) and the monitored consumption.

According to a sixth aspect of the invention there is provided apparatus for supplying a tariff to a tariff recipient, the apparatus comprising: a) means for receiving one or more cost curves from one or more suppliers, each cost curve being indicative of variations in the cost of a product or service expected by a respective associated supplier over time; b) means for receiving a load curve, the load curve being indicative of expected variations in consumption of the product or service over time; c) means for calculating a tariff from the received load curve and the received cost curve in accordance with a predetermined algorithm; and d) means for transmitting the calculated tariff to the tariff recipient.

According to a seventh aspect of the invention there is provided a computer system including a computer readable medium carrying a computer program, the computer program being configured to carry out the method of one or more of the first to fifth aspects of the invention.

According to an eighth aspect of the invention there is provided a computer readable medium carrying a computer program, the computer program being configured to carry out the method of one or more of the first to fifth aspects of the invention.

According to a ninth aspect of the invention there is provided a computer program configured to carry out the method of one or more of the first to fifth aspects of the invention.

The present invention will now be described by way of example with reference to the following drawings, in which: Figure 1 is a functional flow diagram of a system;

Figure 2 illustrates a suitable system architecture for implementing the functions shown in Figure 1 ; .

Figure 3 illustrates the use of a distributor server and regulatory body server; Figure 4 is a flowchart illustrating the steps involved in submitting Time of Use data; Figure 5 is a flowchart showing the selection of an existing profile or building a profile; Figure 6 shows a load curve over a period of business and non-business days; Figure 7 illustrates seasonal influences; and Figure 8 is a flowchart illustrating the steps involved in tariff setting

Referring to Figure 1 , the system has three main functional modules - an optimiser module 1 , a billing module 2 and a settlement module 3.

The optimiser has two sub-systems: a cost sub-system and a load sub-system.

Cost Sub-System

The cost sub-system is responsible for collecting and storing energy, distribution and other charges used in the optimiser. The costs will distill down to tariff components and rules on how the tariff components are used.

The optimiser 1 receives supplier data from suppliers .4. The suppliers 4 may be primary sources of electricity (ie generators) which are seeking to set up forward contracts for the wholesale provision of electricity during some future contract period. Alternatively the suppliers 4 may be power marketers who buy wholesale electricity and capacity on transmission lines. Alternatively the suppliers 4 may be retailers. The optimiser 1 also receives data from clients 5. The clients 5 are non-utility web entities which have pre-existing relationships with end users 0. Examples are transaction-based clients (e.g. telecommunication providers). Instead of receiving data from the end user 0 via clients 5, the optimiser 1 may receive data directly from the end users 0, as indicated in Figure 1 .

The data received from the suppliers 4 includes cost curves. An example of a cost curve is given below in column 5 of Table 1 : Table 1 : Simple single day, Three Bucket, Single Curve Optimisation

The cost curve shown in column 5 comprises a set of buy rate data values. Each buy rate data value is a rate in $/MWh specified by the supplier during a respective 1 hr period. For example, referring to Table 1 , the supplier expects to be able to buy or generate electricity at a rate of $39.72/MWh during the period from 1 1 am to 1 2noon and $32.78/MWh during the period between 1 1 pm and midnight.

A cost curve can be defined as follows: one or more cost curve components from a supplier, grouped together, to create electricity prices across time. A cost curve component can be defined as follows:a set of data having the following attributes:

unit of measure, calculated or derived e.g. kWh, kWAh; timeframe e.g. day, working day, single half hour; rate - monetary value; effective period e.g. Midnight, July 1 1 999 to Midnight December 31 1 999; location - grid exit point (final distribution network point before customer site) *

* there may be no site applicable. For example street lighting.

Cost curve components may have coincident effective periods and be cumulative or exclusive based on rules. An example is two components with coincident effective periods, one component has a cost per kWh the other component has a connection cost per day. Another example is a component for a cost per kWh less than x kWh for the same effective period as a component for a rate per kWh greater than x kWh. Some cost curve components may have a value in every timeframe in an effective period.

An example of an energy cost curve component is:

unit of measure kWh timeframe working day rate monetary value effective period Midnight, July 1 1 999 to Midnight December 31 1 999 location grid exit point or network node.

An energy cost curve component may also be a series of rates over an effective period.

For example:

Unit of measure kWh

Location grid point = x?

Effective period midnight, July 1 1 999 to midnight December 31 1 999

The curve has a rate for every time period within the effective period Timeframe 01 /09/99 1 3:30 to 01 /09/99 14:00.

Rate monetary value

Suppliers can supply printed or electronic versions of their charges that can be manually or electronically inputted to the system. Data entry forms in a computer application can enable the system operators or suppliers to update cost curves. Alternatively suppliers can supply cost curves in prescribed file formats for importing into the system.

Lines and distribution charges are parameterised in the same way. The only variation is that they are usually constant across a Distributor defined area, typically by geographic region. So when energy component only tariffs are used, the system uses lines and distribution cost curve components from lines company suppliers.

Lines and distribution cost curve components are stored in a form readily useable in the Optimiser. They are a set of parameters needed for the optimiser to construct a tariff covering an entire contract period.

The system can also retrieve the cost curve components from suppliers who make this available. Distributors or regulatory bodies can maintain databases with regional specific charges and/or individual connection point charges. A customised translation program is used to convert charges from the supplier's format to cost curve components in the system. Every regulatory body and distributor system is different. This necessitates a customised program. Connection point information can typically include connection information mandatory for the switching module 8 in Figure 1 .

Figure 3 illustrates the relationship with the tariff setting server (ie the optimiser 2 in Figure 1 ) and the servers owned by a regulatory body and a distributor. Referring to Figure 3, a translation program operating in the tariff setting server must communicate with the regulatory body server and/or the distributor server. This communication is handled by available protocols such as TCP/IP or HTTPS. The program may select relevant files and transfer them to the tariff setting server with FTP. Alternatively the program could perform interactive SQL to select data from the database server. This program can operate independently of end user interaction during contract management.

Clients such as internet clients can have contractual arrangements for collecting fees or commissions for contract establishment or billing. These are represented in the system in a similar way to vertical industry charges. For example a client may have a fixed charge per contract established through the system based on contract value. This cost curve component is represented as:

Unit of measure = contract establishment Timeframe = calendar year 2001

Rate = Φx

Rule = contract value greater than $y

Associated with cost curve components are rules describing their application in the optimiser. A simple example is that a Summer Energy cost curve component is only available in the summer timeframe. A more complex example would be that a Peak Demand Penalty cost curve component applies to the 10 highest demand peak during a month. A client based rule may be that all tariffs offered must be from suppliers in same geographic area as the client.

Cost curve components may have zero of more rules to observe when aggregating cost curve components into available cost curves for the optimiser to use. The rules may be represented in business objects stored in an object oriented database or parameters in a relational database table. This technique allows users interfaces and persistent storage methods to be created as the need requires. As long as the rule can be expressed in terms of data available to the system and arithmetic expressions and boolean logic applied then any rule can be implemented. In this way the system is insulated from rigid database designs.

Load Sub-System

When an end user 0 wants to obtain a tariff for a future contract to supply electrical power to the end user's site, they transmit a load curve to the client 5 (or directly to the optimiser 1 ).

An example of a load curve is given in column 2 of Table 1 . The load curve comprises a set of expected load values (in MWh), each representing the amount of electricity that the respective end user expects to consume during a particular hour of the day. These expected load values may be based on historical consumption data associated with the end user, or may be estimates if no historical data are available. The end user may also transmit a set of normalised expected load values. The third column of Table 1 gives a typical set of normalised expected load values over a twenty four hour period. Thus for example the end user expects to consume 6.61 28% and 1 .8369% of the day's power during the two one hour periods mentioned above.

The optimiser 1 includes a load sub-system which deals with various means used to measure consumption and parameters (for example peak demand) for the purpose of physical settlement and optimisation. In general they take two forms; time-of-use where interval data recorders enable actual consumption profiles across time, and custom profiles where profiling is a means of estimating consumption without having a time-of- use meter. A variation on using a custom profile is building a model of a profile based on business type and existing billed consumption.

The load sub-system handles consumption data for many commodities. For example for electricity kWh and kVAR, for water m³, for gas GJ.

Time Of Use or interval data is a record of consumption or other values (measured or derived) at predetermined intervals over a period of time. Typically this data is supplied as comma separated or other forms of variable files for a period. Time of Use data can be captured from the end user during contract establishment. This data must be sent in a format that the system can process. See Figure 4 flowchart showing the means of submitting time-of-use data

Profiling is a means of estimating consumption without having a time-of-use meter. The profiling process determines the shape of the consumption curve. The shape of interest is the shape across the whole settlement period. For example a profile could exist for a 24 hour service station. This profile curve can be broken into an equivalent set of time- of-use periods.

Some profiles are Ex Post (e.g. residual profile based on the connection point) . Some are Ex Ante (ahead of consumption time) and can be standard profiles or proprietary profiles.

See Figure 5 Flowchart showing selection of an existing profile or building a profile. The end user can have a facility from their browser to build a load curve that best represents their consumption. This may be useful where the end user business is not represented in the set of profiles available. It should only be used where the end user has a good understanding of their consumption curves.

An end user with a sports stadium is a good example for load profile building. They may have light loads except when used for night events. The end user is in an excellent position to estimate peak load spikes based on their calculated or measured lighting load.

Typical steps in building a load profile interactively are as follows:

1 . Select starting profile curve. For example the typical business day/night - non- business day/night curve shown in Figure 6. Curves for each 1 5 minute interval in a day are provided for finer or coarser granularity if necessary.

2. Select magnitude of curve values appropriate for each depiction. For example above select Business day value, business night value, non business day value and non business night value.

3. Select other period influences like monthly, bi-monthly, annual and seasonal variations. Choose appropriate curve. For instance see Figure 7 which is a load curve illustrating seasonal influences.

4. Select magnitudes of these period influences.

5. Provide forward and back controls to enable end user to edit curves. Provide metrics like total unit consumption on curves as they are built.

Some alternative approaches are as follows:

1 . Provide computer package for profile building that the end user can download and run on their computers to build profiles. The results would be uploaded to the price setting system. 2. Provide program that. runs within the internet browser session to allow curves to be manipulated with user mouse movements and clicks. This can be done with Java, VRML, Flash or other available technologies.

Apart from transmitting the load curves described above, the end user will also select and transmit other data as discussed below. See Figure 8 Schematic of Price Setting on the Internet.

(a) Select network or service territory and account. This will determine the lines and connection charges. In some algorithms, network charges may be included as constraints.

(b) Select contract period. This selects the length of period for the optimisation. A supplier may have different cost curves for different contract lengths.

(c) Select expected volume. A supplier may have different cost curves for different volumes sold. This may also involve selecting a seasonal profile.

(d) Select tariff type. Some tariffs will contain different amounts of revenue risk. A peak load profile tariff contains more revenue risk than fixed off-peak tariffs due to greater price volatility in that period.

(e) Select daily load shape. This will involve determining what type of meter is used (TOU, profile, multi-register etc). This effectively signals whether the load curve will be custom or not.

(f) Build a tariff structure:

• select billing and settlement period. The contract period will usually be a multiple of this period. Options will probably be limited, e.g. day, week, fortnightly, monthly, bi-monthly, quarterly etc. This period defines the billable 'shape' for each tariff period;

• select day type. A day type is defined as a day that has a significantly different shape from other day types. The most obvious example is business days (BD) and non-business days (NBD). However, some businesses may have more definitive day types. This may include a particular day of the week; • assign day types to actual dates. For the most common, e.g. BD/NBD, the selection will already be made;

• select tariff buckets. These are periods during a load shape when the price will be the same for every trading period during that bucket, e.g. peak, shoulder, off- peak, day, night;

• assign hours to tariff buckets for each shape.

This then creates a tariff structure, i.e. the basis of charging for electrical energy consumption across a contract period.

(g) Build a contract shape. This divides the contract period into the billing and settlement periods, and allows for variations between these periods to be selected. This will take account of seasonal variations in load, or indeed intra-monthly variations if the billing period is weekly for example.

(h) Select tariff calculation algorithm. The optimiser has a set of previously stored tariff calculation algorithms, examples of which are described below. In this step the preferred set of algorithms for that particular end user will be identified.

The client 5 may already have other relevant details stored for the end user, (each name/address details etc) and these details may be transmitted to the optimiser 1 along with the data described above.

The end user is presented with a number of icons on the screen of their PC (see items 24,25 in Figure 2), each icon corresponding with a particular one of the suppliers 4. When the end user clicks on a selected icon, an identifier is transmitted to the optimiser 1 which retrieves a buy rate curve associated with the selected supplier 4.

The optimiser 1 inputs the load curve (eg column 2 of Table 1 ) and the retrieved buy rate curve (eg column 5 of Table 1 ) into an optimisation model that encapsulates business rules as constraints, and calculates a tariff using the algorithm selected in step h).

An example of a tariff is illustrated in column 6 of Table 1 . The tariff of column 6 comprises a set of sell rate tariff values, each associated with a particular hour of the day. In the first 'bucket' (comprising hours 1 to 8) the sell rate tariff values are $34.32 $/MWh. In the second bucket (hours 9-1 6), the sell rate tariff values are $40.54 $/MWh. In the third bucket (hours 17-24) the sell rate tariff values are $51 .1 9 $/MWh. In the example of Table 1 the values shown in column 6 have been calculated using the One Curve Model' algorithm described below under item 1 .

The optimiser 1 can also deal with the situation where the cost curve is stored as an arithmetic function rather than a set of values in a curve. The arithmetic function describes a curve but it reduces the computational requirements of optimisation. In this case rather than multiplying all the bucket rates with all the load values, these cost values are aggregated together. The simplest case of this is where the load curve is a constant. The tariff component would be the sum of the load values for multiplied by the cost value. In these cases however the derivation is the same; the aggregation creates a forward cost curve as if the algorithm was the forward cost curve itself.

The optimiser 1 may also filter supplier tariffs based on attributes independent of load curves. Examples of this are

1 . Client constraints 2. Location constraints

3. End user preferences for supplier or energy source e.g. non nuclear power

4. End user preferences for contract details like payment type.

These constraints will be secondary inputs into the invention and not an integral part of it.

The optimiser then transmits the sell rate tariff values, back to the end user 0 and/or the client 5. The end user can elect to have the tariff values displayed on screen, in a hard printout or in the form of a downloadable file such as an Excel™ file.

If the end user 0 wishes to make a comparison with other suppliers, then the end user can click on another icon and these steps are repeated.

The end user can also submit a second load curve, different to the first load curve, if none of the tariffs are satisfactory, and repeat this process until they are satisfied with the result. By this method the end user is performing a sensitivity analysis on the tariffs and can evaluate the benefits of modifying their consumption loads. Virtual Reality Modelling Language (VRML) can be used to represent multiple load curve vs tariffs.

The selection of supplier icons may be replaced by a single process where the choice of supplier is made automatically. These contract setting mechanisms may or may not be blind as to the supplier, so the end user does not know with whom they contract

The optimiser described in this tariff setting mechanism can adopt a number of different market models depending on the preferences of the end user and the supplier. Here we describe several possibilities.

Examples of mathematical models used in tariff calculation

1. One curve model

Suppose a supplier has a cost curve of the form c(t),t = 1 , 2, ..., 24 and requires that in each hour of the day the tariff exceeds this by some margin m(t) . Suppose that an end user has a load curve given by /(t),t = 1 , 2, ..., 24. Let B_j, i = 1 , 2, ..., k, be a collection of subsets of {1 , 2, ..., 24} that partition this set: i.e. <x B. = φ, B, = {1 , 2, ..., 24 }. We call the subsets B_t tariff buckets. The optimiser constructs a set of tariffs, p_i = \ , 2, ..., k, satisfying certain business rules expressed as constraints. One of these might be a bound on the maximum price. Alternatively one might require that the revenue earned in tariff bucket / must not be greater than tariff bucket / multiplied by some constant α,₇. Mathematically this problem is expressed as:

^m,'nimiSe

subject to Pi ≥ c(t)+ m(t), t e R.,z = 1,2,..., k, (margin constraints)

Pi∑,_eB. W ^{≤ α}ijPχ u_<,_B ^l(^t)> I,J = 1,2,...,k, ⁽revenue in proportion⁾

Pi ≤ M(t), t e B_j,i = 1,2,..., k. (bounds on price) 2. Dual Curve model

Suppose a supplier has a cost curve of the form c(t),t = 1,2,...,24, and will supply up to /(t),t=l,2,...,24, at this rate. Let d(t), t = 1 ,2, ...,24, be the rate at which they are prepared to supply above l(t) . (In most circumstances d(t) will just be the spot price for power at t .) In the dual-curve model the supplier charges the end user a fixed v— .24 amount of C = 2_, ,c(f)l(i) irrespective of the consumption of power. If the actual load

x(t) exceeds l(t) then there is a surcharge D ⁼ ∑_₁d(t)[x(t)-l(t)]+. Here [v]₊ =max{v,θ}. There is no optimisation in this model, apart from the tariff recipient choosing the supplier with what appears to be the best C + D value.

3. Probabilistic demand curve model

Suppose a supplier has a cost curve of the form c(t), t =1,2,...,24. End users have load curves l(t,ω),t= 1,2,...,24, weΩ, where Ω is a set of scenarios for the load curve of the end users. Associated with each scenario ffl is a probability π(ω). Let B_l,i = l,2,...,k , be a collection of tariff buckets. The supplier would like to minimise the expected cost faced by the tariff recipient subject to constraints that ensure that in each scenario they ensure a margin that they had charged c{t) + m(t). Formally this is the following optimisation problem:

minimise

subject to ω eΩ, (margin constraints)

i,j=l,2,...,k, oeΩ (revenue in proportion)

p_t ≤ Mt), t e R, i = 1, 2, ..., k. (bounds on price)

Probabilistic demand curve model (total margin) Suppose a supplier has a cost curve of the form c(i), t =1,2,...,24 . End users have load curves l(t, ω),t= l,2,...,24, w e Ω., where Ω is a set of scenarios for the load curve of the end user. Associated with each scenario ø is a probability π(ω) . Let B_t , i = l, 2, ..., k , be a collection of tariff buckets. The supplier would like to minimise the expected cost faced by the tariff recipient subject to constraints that ensure that in each scenario they ensure a total daily margin of M. Formally this is the following optimisation problem:

minimise ∑ -P. ∑^M∑_,-,, t_t ω)

subject to ∑_i=l Pi ∑ _B K cv)c(t) + M, Q G Q (margin constraints)

P' Σ_ieB ^(^^β))' iA A,2, ...,k, ω e Ω (revenue in proportion)

p, ≤ M(t), t B i = l,2,...,k. (bounds on price)

5. Call-option model

The supplier provides a cost curve of the form c(t),t = 1,2,...,24 for some day in the future. The end user decides an amount of power that they would like at this price on that day, and submits a load curve l(t), t = 1,2,..., 24 for that day. For each t the supplier computes the price e(t) of a European call option on 1 megawatt of power at the exercise price of c(t). The supplier then charges the end user a risk charge that gives the end user the right (but not the obligation) to purchase up

to l(t) MW of power in interval t at c(t). Any purchases of power above /ft) are charged at the spot price. The total cost to the end user for the day's power is

2₄ 2₄ P = E + ∑∑cc((tt))xx((tt)) ++ ∑∑(d(t) - c(t))[x(t) - l( ,

1=1 /=! where [v]₊ =max {v,0) . There is no optimisation in this model, apart from the tariff recipient choosing the supplier with what appears to be the best P value. The tariff recipient can try different l(t) curves to try and compute the best deal for each supplier, but since there is uncertainty in x(t) and d(t), P has a probability distribution. Call-option model with consumer optimisation

This is the same as the call-option model except that the end user provides scenarios of their load and possibly correlated scenarios of the spot price. For any supplier, the optimiser then chooses l(t) to minimise the expected value of P over scenarios o e Ω , that represent different load and price outcomes for that day. Suppose the random price on the day in question has outcomes d(t,ω) , and the load curve of the tariff recipient has load outcomes x t, ω) (typically correlated with spot price) . Recall the total cost to the end user for the day's power is in any given scenario ω .

24 P(ω) = T {e(t)/( + c(t)x(t, ω) + (d(t, ω) - c(t))[x(t, ω) - l(t)] +} . ι=ι

This gives the following two-stage stochastic optimisation problem:

minimise ^ |e(t)/(t) + ∑_ω^π(ω (d(t,ω) - c(t))y(t,ω) subject to l(t) + y(t, ω) > x(t, ω), o e Ω y(t,ω) ≥ 0 ω e Ω. l(t) ≥ 0.

Contract Management

If no further comparisons are required, unless the optimiser makes a selection automatically, the end user selects a preferred one of the suppliers 4 (e.g. by clicking on an icon) and a contract acceptance is transmitted to the selected supplier, and passed on to a contract management module 6 within the billing module 2. An account is also set up by account activation module 19. The contract management module 6 transmits a confirmation message to the end user and a contract notification to the selected supplier 4.

An Electricity Service Provider (ESP) includes a metering module 7, switching module 8 and reconciliation module 9. Once a contract has been completed, the contract management module 6 transmits the contract data to switching module 8. The contract management module 6 also transmits the contract data to a lines function interface 10 and a billing sub-module 1 8. Billing

During the contract, the metering module 7 collects the metering data (time-of-use, custom time-of-use), which is stored and processed by reconciliation module 9. In this example we shall assume that the billing period is twenty four hours. An example of twenty four hours' worth of metering data is shown in column 4 of Table 1 . At the end of the twenty four hour billing period the reconciliation module 9 transmits the metering data shown in column 4 of Table 1 to the billing sub-module 1 8. The billing sub-module 1 8 also receives lines billing data from the lines function interface 1 0. The billing sub- module 1 8 then multiplies the metering data (column 4) by the sell rate tariff values (column 6) to produce a set of actual revenue values (not shown in Table 1 ) . The billing sub-module 18 also calculates the sum of the actual revenue values to generate a total revenue value (also not shown in Table 1 ).

If the 'custom time-of-use' method is used, then load profiles will be assumed. These can be assumed ahead of actual consumption (ex ante) or after actual consumption based on methods such as sampling, or residual unmetered loads (ex post)

All billing data (including the total revenue value, lines billing data etc) is transmitted by the billing sub-module 18 to the end user in the form of an email or by other selected means (e.g. a downloadable file such as an Excel™ file) for display on screen or on a hard print-out.

The Billing system can also collect financial data and other non consumption data. This could be information from suppliers that they might typically include in mailed bills. It could be complete billing information for the billing system to pass directly to the end user. It could be billing information relating to other services supplied outside the contract.

Feedback Loop

By submitting an on-line forward price path for use in establishing a fixed retail contract, a supplier carries a major underlying risk: load misrepresentation. End users seeking to establish a fixed forward retail contract on-line have incentive to misrepresent their load. Load misrepresentation takes two forms;

• shape risk (i.e. that the actual load curve is more coincident with pricing peaks than the expected load curve). In this circumstance suppliers have to buy more expensive electricity in order to physically settle;

• magnitude risk (i.e. that the load is smaller than expected and thus revenue or annual margin is lower than expected).

Because the contract created remains fixed to one forward price path, other potentially lower cost curves may be discarded by the end user if load is overly misrepresented. Dual curves also help reduce this technical problem. Another way of dealing with this problem is through a "feedback loop". In this mechanism any shortfall or surplus in profit or revenue is recovered from (or returned to) the purchaser in the following billing periods. The exact mechanism for doing this can take a number of forms.

In its simplest form, the profit margin per MWhr calculated ex-ante with the expected load U(t)) is applied ex-post to the actual load ( (t)) to give an expected profit with the observed load defined by

24 2 24

Z = ∑2(t)∑(_/ t)-c(t))/(t)/∑/(t) . ι=ι t=ι 1=1 The shortfall S is defined to be the difference between Z and the profit Y that was actually received, where

24

Y = ∑(p(t)~c(t))λ(t), ι=ι so S = Z-Y.

The shortfall (or surplus) can be charged (or refunded) as a one-off fee for the next billing period, or it can be spread over billing period as a surcharge per MWhr. Alternatively it can be spread evenly over the remainder of the contract period, and the tariff structure increased, or decreased evenly by this margin.

As an example consider a billing period of twenty four hours, with data as shown in Table 1 . At the end of the first twenty four hour period the tariff recipient is billed according to their consumption during that period (column 4 of Table 1 ), and according to the previously agreed sell rates (column 6 of Table 1 ). In this example the shape of the actual consumption data (column 4) differs widely from the expected load curve (column 2) . Moreover the total load is 1 393 MWhr as opposed to 1 361 MWhr as expected. This discrepancy may result in losses being sustained by the supplier. Here Y= $7561 .92. Since

₂4 T (p(t) - c(t))l(t) = $7854.60

-=ι

we have that Z= $7854.60 ( 1393/1361 ) = $ 8,039.28. Note that this is the profit that the supplier would have made if they had made the same profit margin per MWhr as expected when the optimisation was run ($7854.60 /1 361 ), but earned this margin on every MWhr of power sold (1 393).

The shortfall in profit 5 = Z-Y = $ 8,039.28-$7561 .92 = $ 477.36. This amount is either added to the bill for the following day, or divided by the expected total load for the next twenty four hour period and added to the tariffs in column 6 of Table 1 for this period. If the contract period is longer than the billing period (say 30 days) then the shortfall can be distributed over the remaining days in the contract period. In the feedback loop mechanism the final day in the contract period will incur a shortfall or surplus to be reconciled as a washup payment, or included in the following contract period.

Observe that the feedback loop continually penalises the user for discrepancies between the expected load shape and the actual ex-post load shape that are to the disadvantage of the supplier. It also rewards the user if their misrepresented load shape gives an unexpected windfall to the supplier.

At regular intervals the optimiser is re-run to advise end users of the advantages of changing tariff or suppliers. Depending on supplier contractual arrangements supply of new optimisations to the end user may be permitted. Suppliers may permit the optimisations to include only their cost curves. During the course of the contract the end user loads are optimized against the current supplier tariffs to look for more favorable tariffs. The loads used are either the original loads captured during contract establishment or loads based on actual consumption data captured during billing.

Settlement The settlement module 3 includes a trust account 1 2, and bank accounts 1 3-1 7 each associated with the clients 5, ESPs, Lines Companies 10, suppliers 4 and an Application Service Provider (ASP) which operates the modules (1 -3) respectively. The billed value is direct debited from the end user's bank account by billing module 6 (after a settlement period previously specified by the end user) and paid into the trust account 1 2. The trust account 1 2 is administered by a trust account administrator who arranges for concurrent payments into the accounts 1 3-1 7.

Clients

The clients 5 will be able to access the billing data and reporting functionality such as graphical reports of consumption, and debtors information. They are also able to alter the way in which the end users receive and view their electricity billing data.

Architecture

A suitable system architecture is illustrated in Figure 2. The ASP hosts applications at two sites - one for sales and user registration, and one for operational processing.

End user and supplier data is recorded at the sales/user registration site in stores 20,21 under control of a server 23. The data is received from end user PCs 24,25, or via a client 34, and cost curve data is received directly from supplier PCs 26,27. The communication link is completed via the internet 28 and modem 29. The server 23 also provides interactive tours for prospective users, utilising interactive data in store 33.

The functions of the optimiser module 1 , billing module 2 and settlement module 3 are performed at the operational processing site by a server 30 in conjunction with a store 31 and modem 32. The majority of the system software is hosted by the ASP and stored in a computer readable medium (eg hard drive) on the server 30. Only a relatively small amount of software is stored in computer readable media associated with the end user/supplier PCs 24-27.

Every billing period a bill confirmation is automatically generated and transmitted to the end users PC 24,25. The bill confirmation in the form of an email has a hyperlink that connects the end user PC 24,25 to the billing server 30. The end user has the ability to drill down (acquire) to full billing and contract history reports for their contract. The generators/marketers/client also have the ability to drill down to full billing and contract history reports, but restricted to their contracts.

To maximize the effect of this invention, the ability to compare must be transportable across suppliers. Billing and settlement modules enable transportability to be maintained. Typically the method is performed by a central processor (typically that may be hosted by an Application Service Provider - ASP) which is remotely located from the supplier(s) and the tariff recipient. This enables the tariff recipient and supplier(s) to minimise the amount of local processing power required.

The optimiser in this system calculates tariffs for tariff recipients that meet certain conditions or business rules. One of the novel and unique aspects of this invention is that given cost data from the suppliers, and load data from the tariff recipients, the best deal for the tariff recipient can be constructed automatically by optimisation software, once the rules defining constraints on the tariffs have been set, and an objective to be optimised has been determined. On the one hand the optimisation could optimise an objective function determined by the tariff recipient subject to rules set by the supplier and tariff recipient constraining the choice of tariff. Such an objective function would typically be overall cost of supply (that the optimisation would seek to minimise). On the other hand the optimisation could maximise the revenue earned by the supplier subject to rules set mainly by the tariff recipient constraining the choice of tariff.

Although this invention has been described by way of example and with reference to possible embodiments thereof, it is to be understood that modifications and improvements may be made without departing from the spirit or scope of the invention.

Claims

1 . A computer-implemented method of supplying a tariff to a tariff recipient, the method comprising the steps of: a) receiving one or more cost curves from one or more suppliers, each cost curve being indicative of variations in the cost of a product or service expected by a respective associated supplier over time; b) receiving a load curve, the load curve being indicative of expected variations in consumption of the product or service over time; c) calculating a tariff from the load curve received in step b) and the cost curve received in step a) in accordance with a predetermined algorithm; and d) transmitting the tariff calculated in step c) to the tariff recipient.

2. The method of claim 1 , wherein the tariff comprises one or more tariff values of the general form: p = c.l + m, where p is a tariff value, c is a cost curve value, I is a load curve value, and m is a non-zero margin value

3. The method of claim 2, wherein the tariff values p are calculated by minimising p. I subject to one or more predetermined business rules.

4. The method of claim 2 or 3, wherein the tariff values p are calculated by minimising p. I. pi subject to one or more predetermined business rules, where pi is a predetermined probability value.

5. The method of claim 3 or 4 wherein the tariff values p are calculated by minimising p. I subject to predetermined constraints on m.

6. The method of any of the preceding claims wherein the predetermined algorithm calculates one or more tariff values in accordance with the equation: p = c.lmax + d[l-lmax], where p is a tariff value, c is a cost curve value, I is a load curve value, Imax is a maximum load value, and d is a surcharge value.

7. The method of any of the preceding claims wherein the predetermined algorithm calculates one or more tariff values in accordance with the equation: p = e.l + c.x + (d-c)[x-l] ₊ , where p is a tariff value, c is a cost curve value,

I is a load curve value, e is an option value, x is an actual load value, d is a surcharge value, and

[v]₊ = max{v,0}.

8. The method of any of the preceding claims, wherein step b) is performed after step a).

9. The method of any of the preceding claims further comprising saving the cost curve in a store after it has been received in step a), and retrieving the saved cost curve from the store prior to, or during, the tariff calculation step c).

10. The method of any one of the preceding claims wherein steps a)-d) are performed by a central processor.

1 1 . The method of any of the preceding claims further comprising transmitting the predetermined algorithm to the central processor before a tariff is created in step d).

1 2. The method of any of the preceding claims wherein the tariff comprises a plurality of tariff values, and the method further comprises the step of summing the tariff values.

1 3. The method of any of the preceding claims further comprising transmitting the predetermined algorithm to the tariff recipient.

14. The method of any of the preceding claims wherein the cost curve comprises a plurality of cost curve values.

1 5. The method of any of the preceding claims wherein the load curve comprises a. plurality of load curve values.

1 6. The method of any of the preceding claims wherein the load curve is received in step b) from the tariff recipient.

1 7. The method of any of the preceding claims, wherein step a) comprises receiving a plurality of cost curves from one or more suppliers.

1 8. The method of claim 1 7 wherein step c) comprises calculating a plurality of tariffs from the plurality of cost curves.

1 9. The method of claim 1 8 further comprising the step of selecting a preferred one of the tariffs.

20. The method of claim 1 7, 1 8 or 1 9 including the additional step of: e) receiving a cost curve identifier which identifies one of the plurality of cost curves for use in step c).

21 . The method of any one of the preceding claims wherein step a) comprises receiving cost curves from a plurality of suppliers.

22. The method of claim 21 including the additional step of f) receiving a supplier identifier which identifies at least one of the suppliers, wherein a cost curve associated with the supplier identified in step f) is used to calculate the tariff in step c) .

23. A computer implemented method of obtaining a tariff, the method comprising the steps of: a) transmitting a first load curve to a central processor, the first load curve being indicative of expected variations in consumption of a product or service expected over time; b) receiving a first tariff from the central processor, the first tariff being associated with the first load curve; c) transmitting a second load curve to the central processor, the second load curve being indicative of expected variations in consumption of the product or service over time; d) receiving a second tariff from the central processor, the second tariff being associated with the second load curve; e) selecting the first tariff or the second tariff; and f) transmitting a contract acceptance, the contract acceptance indicating which tariff has been accepted in step e).

24. A computer implemented method of invoicing for the provision of a product or service, the method comprising: a) monitoring consumption of the product or service; b) invoicing in accordance with the monitored consumption and a tariff; c) calculating an expected profit value in accordance with the monitored consumption; d) calculating an actual profit value in accordance with the monitored consumption; e) making a surcharge if the expected profit value exceeds the actual profit value; and f) making a refund if the actual profit value exceeds the expected profit value.

25. The method of claim 24, further comprising receiving a load curve, the load curve being indicative of expected variations in consumption of the product or service over time, wherein the expected profit value is calculated in step d) in accordance with the received load curve.

26. A computer implemented method of establishing a contract between a supplier and a tariff recipient for the provision of a product or service, the method comprising the steps of: a) supplying a tariff to the tariff recipient by a method according to any of claims 1 to 22; b) receiving a contract acceptance from the tariff recipient, the contract acceptance identifying a supplier; c) transmitting a contract confirmation to the tariff recipient to acknowledge receipt of the contract acceptance in step b); and d) forwarding the contract acceptance to the supplier identified in the contract acceptance.

27. A computer implemented method of invoicing a tariff recipient for the provision of a product or service, the method comprising establishing a contract with a tariff recipient by a method according to claim 26; monitoring consumption of the product or service during a contract period; and invoicing the tariff recipient in accordance with the tariff previously supplied to the tariff recipient in step a) and the monitored consumption.

28. The method of any of the preceding claims, wherein the product or service comprises electrical power.

29. Apparatus for supplying a tariff to a tariff recipient, the apparatus comprising: e) means for receiving one or more cost curves from one or more suppliers, each cost curve being indicative of variations in the cost of a product or service expected by a respective associated supplier over time; f) means for receiving a load curve, the load curve being indicative of expected variations in consumption of the product or service over time; g) means for calculating a tariff from the received load curve and the received cost curve in accordance with a predetermined algorithm; and h) means for transmitting the calculated tariff to the tariff recipient.

30. A computer system including a computer readable medium carrying a computer program, the computer program being configured to carry out the method of any of claims 1 to 28.

31 . A computer readable medium carrying a computer program, the computer program being configured to carry out the method of any of claims 1 to 28.

1. A computer program configured to carry out the method of any of claims 1 to 28.