Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/06—Buying, selling or leasing transactions

Definitions

• This invention concerns apparatus for negotiation and finds particular application in collaborative software agent systems, for instance for process management or for electronic trading.
• agents In collaborative software agent systems, it is often necessary for the agents to collaborate either amongst themselves or on behalf of another entity. For instance, in process management a community of agents might between them control resources for running tasks and sub-tasks which together provide an overall process or service. Each resource may however be available to more than one agent, or to other processes altogether. Agents may therefore have to negotiate amongst themselves in order to arrive at an efficient way of exploiting the available resources to provide the overall process. Alternatively, in electronic commerce a community of agents might negotiate amongst themselves on behalf of other entities to arrive at an acceptable transfer of resources between the entities.
• a number of research projects have developed decentralised control mechanisms for distributed systems based on market analogies. Many of these are based on mathematical results of a branch of microeconomic theory.
• the world is divided into customers/suppliers of goods, and producers (who can transform the types of goods by destroying some in order to create others).
• the levels of supply, demand and production are functions of the set of prices for the goods (known as utility and production functions respectively). These prices apply globally, that is all transactions in a particular good at a given time take place at the same price, which is known to all.
• the set of prices is determined by a mechanism that operates in between rounds of production and trading. This sets the prices to be those that minimise the difference between overall supply and demand (taking into account production and consumption by producers).
• a method of negotiation for use in controlling exchange of one or more resources such as goods or services amongst at least two negotiating entities, the method comprising the steps of : i) receiving provision bid data to represent conditions for provision of a resource by a first negotiating entity; ii) receiving receipt bid data to represent conditions for receipt of the resource by a second negotiating entity; and iii) comparing the provision and receipt bid data to determine whether there is a negotiation solution between the first and second negotiating entities
• issued bid data represents one or more boundaries of an acceptable region of multidimensional deal space
• said comparison comprises determining whether there is an intersection of the regions defined by the boundaries of issued provision bid data and issued receipt bid data in the deal space to define a mutually acceptable region from which a negotiation solution can be determined.
• Intersection of the regions might mean that there is intersection between the boundaries of the bids but it may mean for instance that one region lies wholly within the other region, in which case the boundaries associated with the regions will not themselves intersect.
• the boundaries may be surfaces or, in a two-dimensional deal space, the boundaries might resolve to lines.
• the boundaries may represent multiple components of a bid, such as price and quantity, and/or time to delivery.
• the issued bid data might comprise one or more sell bids and one or more buy bids. Where there is a plurality of a first type of bid (sell or buy) but only one of a second type of bid (buy or sell), the method might further comprise the step of comparing the bid of the second type against each of the bids of the first type to identify a preferred match, such as a bid pairing which will result in a maximum amount of resource to be exchanged. Where there is a plurality of both types of bid, the method might further comprise the step of comparing several bids of the first type against several bids of the second type to identify a set of preferred bid pairings. A criterion for selecting preferred bid pairings might be for instance again that a maximum amount of resource will be exchanged. There will however be other criteria available, depending on the components of the bids, such as time to delivery.
• apparatus for use in controlling exchange of one or more resources, the apparatus comprising an input for receiving: i) provision bid data to represent conditions for provision of a resource by a first negotiating entity; and ii) receipt bid data to represent conditions for receipt of the resource by a second negotiating entity;
• the apparatus further comprising comparing means for comparing the provision and receipt bid data to determine whether there is a negotiation solution between the first and second negotiating entities,
• issued bid data represents one or more boundaries of an acceptable region of multidimensional deal space
• said comparing means makes a comparison by determining whether there is an intersection of the acceptable regions defined by the boundaries of issued provision bid data and issued receipt bid data in the deal space to define a mutually acceptable region from which a negotiation solution can be determined.
• the apparatus may further comprise bid pairing means for selecting one or more preferred bid pairings from amongst a plurality of available bid pairings between received provision and receipt bid data. Such selection may be done against one or more criteria, usually related to components of a bid represented by the boundaries expressed in the bid data, such as maximum quantity of resource to be exchanged in a community of negotiating entities, or minimum total time to delivery of resource to be exchanged in the community.
• bid data as issued may comprise an identifier, with or without further parameters, to represent boundaries of an acceptable region, which identifier and any parameters can be interpreted to give the boundaries within the bid data, rather than defining the boundaries themselves.
• embodiments of the invention may be used in the real time exchange of resources, such as goods or services, it is also possible that the exchange of resources takes place in the future, according to a stored record of the negotiated exchange. Hence embodiments of the invention might be used in generating or amending stored terms of exchange to be acted on, or potentially renegotiated, at a later date.
• negotiating apparatus for use in controlling exchange of one or more resources, said negotiating apparatus comprising: i) an input for resource-related data relating to a resource to be exchanged; ii) bid data generation means for processing received resource-related data to generate a bid for provision or receipt of said resource, said generated bid comprising a representation of one or more boundaries of an acceptable region of multidimensional deal space, such that said generated bid can be compared with another bid of like type to determine the presence or absence of a mutually acceptable region, defined by the boundaries in the compared bids, from which a negotiation solution can be selected.
• apparatus for use in controlling exchange of a resource between pieces of equipment, which apparatus comprises: i) input means for receiving bid data, ii) output means for outputting bid data , iii) means for storing at least one multicomponent relationship with respect to at least one resource, iv) monitoring means for monitoring availability data for said resource, v) bid assembling means for assembling bid data comprising a multicomponent relationship determined at least in part by the monitored availability data, vi) bid receiving means for receiving bid data comprising a multicomponent relationship, and vii) comparing means for comparing multicomponent relationships relating to a common resource but derived from different respective bid data to determine whether a negotiation solution exists.
• a multicomponent relationship may for instance comprise components selected from the following group: ⁇ Price ⁇ Quantity ⁇ Time to supply.
• the resource concerned is a service of some sort, such as a communications service, then examples of components might include quality of service, or security levels.
• a record of exchange of resource may be made when a negotiation solution is detected, either for acting on immediately or in the future. The record may be in the form of a contract term for the supply of a resource in the future.
• the apparatus may further comprise trigger means for triggering transfer of resource between said pieces of equipment in accordance with an output of the comparing means.
• the comparing means may, having determined that a negotiation solution exists, also select a solution and the transfer of resource will be in accordance with that solution.
• the apparatus may be supported at one or more sites in a communications network and bid messages may be transmitted between parts of the apparatus located at the same site or at different sites.
• the monitoring means for monitoring availability data may monitor a local supply of the resource. There may be more than one monitoring means and more than one bid assembling means, first and second monitoring means providing different availability data to respective bid assembling means. Where bid data for the resource comprise a relationship involving quantity as a component, this has the result that the same resource may have different relationships associated with it at different locations or with respect to different pieces of equipment for instance.
• Bid data may be transferred in any relevant protocol and may for instance be in the form of messages, as used between software applications sited on separate platform.
• Each multi component relationship may define boundaries, or surfaces, in a multidimensional deal space.
• a quantity/price relationship for instance may comprise a partially bounded two-dimensional area
• the comparing means determining that a negotiation solution exists when the partially bounded areas of two quantity/price relationships at least partially coincide, for instance (but not necessarily) to create a fully bounded two dimensional area.
• the boundaries may extend in three dimensions where more than two components are involved.
• Figure 1 shows schematically a network arrangement for providing processing capacity and communications to support the electronic trading system
• Figure 2 shows a functional block diagram of a software agent and a mechanism the agent acts for, for installation using the network arrangement of Figure 1 ;
• Figure 3 shows a functional block diagram of an auction engine for use in a software agent as shown in Figure 2;
• Figure 4 shows communication flows between agents of an electronic trading system according to Figure 1 ;
• Figure 5 shows a variation of the arrangement shown in Figure 4;
• Figure 6 shows a further variation of the arrangement shown in Figure 4;
• Figure 7 shows a more complex arrangement of software agents in an embodiment of the electronic trading system of Figure 1 ;
• Figure 8 shows a pair of curves representing a sell bid which might be assembled by a software agent of the system;
• Figure 9 shows two pairs of curves representing sell and buy bids mapped onto one another by an auction engine as shown in Figure 3,
• Figure 10 shows a stockpile of goods on which a bid might be at least partly based;
• Figure 11 shows curves assembled for the purpose of establishing a clearing price
• Figures 12 to 14 show price time bid curves for use in finding a preferred solution between entities for which price and time to delivery are components of a bid;
• Figure 15 shows the development of a mutually acceptable region for the entities of Figures 12 to 14.
• Arbitration negotiation employing a trusted third party or agreed mechanism to assist in reaching agreement on the terms of a deal.
• the candidate deal resulting from arbitration will typically be binding.
• Arbitration mechanism a mechanism that, given a set of bids from two or more parties, identifies potential deals, and selects one or more of these according to agreed criteria.
• Bid a statement by one party of the terms under which a deal would be acceptable or unacceptable to it.
• a bid forms part of a negotiation. It may specify explicitly or imply restrictions on conditions under which it is valid (e.g. only for a certain time after it is issued, or until a particular event occurs). Subject to these restrictions, a bid is binding until revoked or modified via an agreed mechanism. Defaulting on a bid (or deal) will generally result in some penalty or sanction, or may simply be forbidden (i.e. compliance is enforced).
• Contract Formal binding expression of a deal
• Deal space the (multi-dimensional) mathematical space defined by the allowed values of the parameters to a deal.
• a bid may be considered as defining a region or regions of deal space (or subspaces of it) that are acceptable or unacceptable to the issuing agent.
• Deal sub-space a space of lower dimensionality than the deal-space, and defined by the allowed values of a sub-set of the deal parameters
• Negotiation the process of determining a mutually acceptable deal and committing to a contract, or reaching the conclusion that such a deal is not possible.
• a negotiation can be viewed as a search for a region of deal space that is acceptable to all parties to a potential deal, with a view to selection of a specific point in deal space within this region
• Partial bid similar to a bid, except that the statement concerns only a sub-set of the terms of the deal.
• the system is suitable for agent communities which manage resources (which could be for instance either goods or services) and buying and selling may be done in kind or by means of a system-based currency rather than a recognised monetary currency.
• an agent community managing transfer of goods between resources may be supported by servers 110, 115, 120 and by desktop processing capacity such as personal computers 100, 105.
• desktop processing capacity such as personal computers 100, 105.
• a software agent assembling, issuing and receiving bids on behalf of a resource will be sited near that resource, for instance on a personal computer or local processing capacity, while a software agent which receives and brokers bids, in the nature of an auctioneer, is more likely to be sited on a server where it will be accessible to a large number of bidding agents.
• software agents managing transfer of goods between resources may be of different types.
• they may comprise ⁇ trading agents 200 which assemble and issue bids on behalf of resources supplying goods or services ⁇ trading agents 705, 710, 715, which receive and issue bids on behalf of resources which convert incoming goods or services of one type to outgoing goods or services of another type; ⁇ trading agents 720 which assemble and issue bids on behalf of resources consuming received goods or services; ⁇ auction agents 220 for resolving buy and sell bids.
• auction functionality can be provided separately from the resource management agent functionality, ie as separate auction and trading agents, but it is also possible for trading agents to carry out an auction directly, incorporating auctioneering functions within, or closely associated with, a trading agent 200, 705, 720.
• a trading system to be managed by an embodiment of the present invention can be modelled as a collection of repositories of goods, flows of goods and task engines.
• Each trading agent 200, 750, 720 may be associated with a controlled mechanism 205 which has at least one repository 210 and, optionally, at least one task engine 230 for driving a process in respect of goods from the repository 210.
• the repositories hold commodity goods, all items of a different commodity being regarded as identical, and one repository 210 only holds one type of commodity.
• the flows 235 between repositories 210 transfer commodities without changing their type or commodity number.
• Task engines 230 are pieces of technology which can perform a task, effectively taking an input commodity and either consuming it or converting it into an output commodity of a different type, effectively utilising resources and consuming "money" 240.
• workflows involve processing of work items associated with orders.
• a task may involve taking paperwork, a work item, from an in-tray associated with the task, performing work to progress the order, updating the work item and putting it in an out tray. Processing the work item generally requires use of resources, both consumables and assets, and can incur a cost.
• the basic building block of the electronic trading system is a unit comprising a software agent and the local region of the managed system for which it is responsible, that is, a collection of linked task engines 230 and repositories 210. All the agents are essentially similar and connected via an interaction mechanism.
• the interaction mechanism is intended, in conjunction with the behaviour rules of the agents, to cause the system to evolve to a state in which it is operating efficiently. Should circumstances change, the system should evolve to a state appropriate to the new conditions.
• a simple trading agent 200 is shown, which is responsible for a controlled mechanism 205.
• the controlled mechanism 205 comprises at least one repository 210 and a task engine 230.
• the simple trading agent 200 puts together and issues bids to an auction agent 220 and the result of a deal achieved at the auction agent 220 will be fed back to the controlled mechanism 205 which then implements the result of the deal directly with another mechanism 225 affected by the deal.
• An important aspect of embodiments of the present invention is the nature of the bids issued by the trading agents 200, 705, 715, 720, 730 and matched by the auction agents 220.
• the form of bid concerns transactions in which an amount of some commodity item or service is sold, and in which both the amount and unit price are subject to negotiation.
• each bid whether a sell bid or a buy bid, comprises a pair of curves 800, 805 (or in higher dimensional deal spaces, surfaces).
• an auction agent 220 will accept sell bids from supplying trading agents 200 and buy bids from buying trading agents 705. It is necessary for the auction agent 220 to resolve these bids to the benefit of the system as a whole and the bid structure is an important factor in this. The following is a discussion of the bid structure.
• the bids (to sell or buy goods or services) specify directed surfaces in a multi-dimensional deal space that are interpreted as the boundaries of the acceptable region 810 of deal space under the terms of the bid.
• the auction mechanism 300 within an auction agent 220 intersects the surfaces to find the boundaries of the mutually acceptable regions, then applies an algorithm to determine a specific point in this region as the basis of a potential deal. This algorithm is intended to produce the same deal that a fair negotiation between the two parties would reach.
• a related algorithm can be applied to produce a measure by which the 'goodness' of possible bid pairings can be ranked.
• sets of sell bids or buy bids may be combined to form virtual or composite bids.
• Composite buy and sell bids may then, for example, be intersected in the same way as the original bids and an algorithm applied to obtain a local or global measure of current market price for the type of good. In the case of a 2 dimensional (price vs. amount) bid space, this price is then used in combination with individual bids to determine the amount bought or sold by the corresponding agent.
• the buy and sell bids each include a pair of curves 900,905,800,805 representing the upper and lower bounds on the amount offered versus price. Intersecting the curves of a pair of bids (one buy, one sell) for a given good results in a finite region of deal space 810 that is acceptable to both parties (or else an empty region indicating that there is no mutually acceptable deal).
• a variety of algorithms could be used to select a point within the mutually- acceptable region 810. One way to do it is to select the point on the boundary of the region corresponding to greatest amount of goods sold 910. By putting restrictions on the allowed properties of the curves, this point can be made unique and will be one of the intersection points.
• the amount element of the selected point is then used as the ranking measure for candidate bid pairs.
• the curves should be continuous and have exactly one finite price value for every possible amount value and vice versa. This implies monotonicity, but goes a bit further.
• a rising and a falling curve will then intersect at exactly one point.
• Two falling or two rising curves can still intersect multiple times (or not at all), but the intersection points will have different amount values.
• the upper sell and lower buy curves should increase with price, and the upper buy and lower sell curves should decrease with price.
• bids are posted to independent auction agents 220 or are sent directly to trading agents 200,705,710,715.
• instances of the auction mechanism are incorporated into the trading agents' software.
• Incoming bids can be compared against internally-generated 'bids' (single auction) or transactions can take place at a price or amount to suit the agent owning the auction mechanism (double auction).
• double auction In the interests of fairness, the bidders should know in advance which of these alternatives is used.
• the single auction case compares a single sell (or buy) bid to multiple buy (or sell) bids.
• the double auction case treats arbitrary numbers of buy and sell bids.
• Auction agents may each operate in a single or double auction fashion, continuously, periodically, or in some other way.
• the auction mechanism can set a price at which all deals in a particular round take place. The amounts at this price are then simply read off the bids. In this mode the auction mechanism is effectively acting as a middleman, buying from one group of agents and selling to another. When the total amounts bought and sold in a given round are not equal, the surplus or deficit in goods and money must be carried by the auction agent which may in a subsequent round itself submit bids to buy or sell to redress the balance. To avoid this mismatch, the auction agent can aim to set the price to be that at which there is an exact match between the amounts bought and sold. Note that in a particular application, bids will typically be instances of a small number of families of surface (i.e.
• the surface relevant to a specific bid is distinguished by a small number of parameter values, and it is only these that need to be generated when making a bid. This is particularly important in facilitating bid decisions by human users.
• One alternative then is to transmit only the parameter values as part of the bid, and have the auction mechanism interpret these as denoting surfaces. This would require specialised versions of the arbitration mechanism for each family of functions, and matching versions of the trading agent software.
• the auction mechanism can be kept generic, however, by including the surface generation function as well as the parameter values as part of the bid. Note that this does not mean the function is physically transmitted with each bid.
• the solution adopted in the embodiment described below is to implement a bid as an instance of an object-oriented software class defining suitable methods for interrogating and operating on bids of this class.
• the class definition can be known a priori to the auction mechanism, or else transmitted once, eg, the first time an instance of the class is encountered.
• ⁇ Compared to mechanisms employing 'point bids', embodiments of the present invention require fewer bid messages to be exchanged ⁇
• the bid representation allows trading agents to express the important factors in the bid in a way that is semantically clear and largely independent of context.
• the bids can be displayed as curves on a graph, offering an intuitive interface. Direct manipulation (i.e. click and drag) of the graphs can be used to prepare and update bids.
• the clear semantics mean that it is possible to derive the bid curves from more application domain oriented paremeters (such as stock levels, rates of sale, production, purchase, etc.).
• the bid representation and associated mechanisms for manipulating and reasoning about bids can be employed in a variety of trading system architectures. They can thus form part of a flexible toolkit from which custom trading systems may be built.
• the bid representation is compact.
• the bid surfaces can be generated using parameterised functions, so that only the parameter values characterising the specific surfaces need to be altered or transmitted with each instance of bid.
• the bids can be manipulated, combined and otherwise reasoned about in a computationally efficient way.
• the form of bids and the mechanisms for combining them are particularly suited to decentralised management using market-based multiagent systems.
• Agents get feedback in a natural way on their own pro-active behaviour, and also information enabling them to react to other agents' behaviour. To appreciate these desirable properties a little, consider first an agent trading in an otherwise static environment, ie other agents keep their bids constant. The agent is able to derive information from the way the environment responds when it changes its bids in order to optimise its own internal parameters. The feedback from the environment is in terms of changes in quantities sold/bought and cashflow, etc. In the embodiment described below, increasing the amount offered for sale will result in more goods being sold but at a lower unit price. This could result in either an increase or a decrease in cash flow. Observing the change in cash flow yields information that helps the agent optimise its parameters so as eg to maximise profit.
• the embodiment described here is an arbitration mechanism (or family of mechanisms) able to support a variety of auction / negotiation styles in a 2-dimensional deal space (price vs. amount for a given commodity). It was originally devised for use within a market-based multi-agent system in which each agent manages a controlled mechanism 205. The agent is responsible for buying the resources consumed during production, selling the results of production, and controlling the level of production. The level of production affects the unit costs in a (non-linear) way that is not known to the agent, which only knows current costs. Trading, bidding and production proceed concurrently. The bid format and arbitration mechanism are applicable to a variety of market schemes and applications, however.
• a bid consists of two continuous p ce-versus-amount curves 800,805,900,905 as shown in Figures 8 and 9, an identifier denoting the bidding agent, a flag indicating whether this is a bid to buy or to sell, plus other parameters such as a validity time interval.
• One of the curves 805,905 denotes an upper amount level for an acceptable bid, the other 800,900 denotes a lower amount level.
• These curves denote the maximum and minimum amounts that an agent is willing to buy or sell as a function of price.
• the upper amount curve 805 for a sell bid increases monotonically with price, as does the lower limit curve 900 for a buy bid.
• the lower amount curve 800 for a sell bid decreases monotonically with price, as does the upper limit curve 905 for a buy bid.
• a point on the upper amount curve signifies that (subject to constraints imposed by the lower amount curve) the bidding agent is willing to agree a deal at this price for this amount or less.
• a point on the lower amount curve signifies that (subject to constraints imposed by the upper amount curve) the bidding agent is willing to agree a deal at this price for this amount or more.
• a pair of points (one from each curve) at the same price, with the upper amount greater than or equal to the lower amount signifies the acceptable range of amounts at this price.
• a similar pair in which the lower amount is the greater signifies that there is no acceptable amount at this price.
• a pair of curves signifies a set of amount ranges at various prices indicating that the bidder is willing to commit to a trade at a point in the region 810 of the deal plane above the lower amount curve and below the upper limit curve. Comparing a buy and sell bid yields a region of price-amount space within which a deal would be agreeable to both parties. Effectively, this two curve structure allows a vendor to say: 'I will sell this amount of goods if I am paid at least this price' across the full spectrum of amounts. The amount corresponding to minimum sale price is the 'ideal' amount the vendor wants to sell, perhaps corresponding to the excess over some target stock level. It is willing to sell more or less than this, but requires monetary compensation for doing so.
• 'I will buy this amount of goods if I have to pay no more than this price'.
• the amount corresponding to maximum sale price is the 'ideal' amount the vendor wants to buy, perhaps corresponding to the deficit below some target stock level. It is willing to buy more or less than this, but requires monetary compensation for doing so.
• the minimum amount is not a significant consideration.
• the approach may also work with the bid being unbounded in some directions, eg with no minimum curves at all, but then the system would have to deal with sale of negative amounts of goods.
• the arbitration mechanism when considering a pair of bids, the arbitration mechanism is entitled to set up a deal at any point on the deal plane 810 compliant with both bids.
• the mechanism will usually employ some function to rank the points in order of desirability.
• a trading agent monitors its stockpile 1000 of goods in its repository 210. It can generate a pair of bid curves by putting the monitored values into a predetermined equation. Alternatively, it can adjust the curve parameters dynamically to attain some target condition, e.g. maintaining the stockpile 1000 at some target level. To illustrate the second point, if its stockpile level is too high and increasing, then a selling agent lowers its selling prices in the next auction round to increase sales.
• v'(n) decreases with increasing n. This is because once the agent has enough stock for short-term needs, each increment of surplus has decreasing value, for example as a contingency reserve.
• v'(n) may be low if there is some minimum useful amount of stock, or may be at its highest here. Thus typical simple v'(n) curves will decrease monotonically or will have a single maximum.
• the profitability of selling or buying the m'th item depends on whether v'(m) is above or below this price.
• the vendor has bought B 0 items at average unit price P 0 , and that the stock level the vendor likes to maintain is N 0 .
• Po can be taken as an estimate of the average value of if the pile of stock is at the desired level. If the number of items currently in stock, N, is greater than N 0l then the excess items can be considered less valuable.
• each item has a different value to the vendor. Items at the top of the stack will normally have a lower value than those lower down.
• the items that can be sold at a profit are the ones whose unit value is less than the price under consideration.
• the maximum number that can be sold such that each is sold at a profit is the height of the stack minus the position of the item whose value equals the sale price.
• this function depends on the discounting policy of the vendor, the argument shows more generally that: it is possible to view the value of a item in a stack of identical items as a function of its position in the stack, and this gives a natural semantics for the maximum buy and sell amount curves.
• a discounting policy (such that an item to be used in the future is worth less than one to be used now as is standard accounting practice) results in the max sell (buy) curve being a monotonically increasing (decreasing) function of price.
• the agent enters its requirement for the service as the only buy bid; multiple other agents can submit sell bids.
• An analogous situation can be envisaged in which the seller incorporates the engine and there are multiple buyers. When there are multiple buyers and sellers involved, it is most natural to introduce a separate auctioneer or negotiation mediator in which the engine is incorporated.
• An auction engine is basically a collection of bids plus a set of operations that can be performed on that collection. Associated with each bid is the definition of the time interval during which the bid is valid (i.e. during which it is a binding commitment on the part of the agent submitting it). Note that for simplicity, there is no provision for an agent to retract a bid once it has been made. The main operation takes the currently valid bids, and generates a set of deals. As a result, the set of bids is reduced by removing those that have been used up, and modifying any that have been partly used. Note that an agent may have more than one active bid in the collection.
• a round of a single auction (one buyer and multiple sellers or vice versa) can be conducted by matching the single sell (or buy) bid against all the current buy (or sell) bids, with the deal (or leading candidate) being determined on the basis of greatest amount.
• a round of a double auction (multiple buyers and sellers) can be conducted by matching all combinations of current sell and buy bids, with the deal (or leading candidate) again being determined on the basis of greatest amount.
• Multiple deals can be determined in a single round by choosing the best n bid pairs.
• Multi-round auctions can be conducted by informing bidders of the current best bid pair, cancelling all other bids, and inviting repeat bids.
• the (agent acting as) auctioneer 220 can set a price at which transactions in a given round will take place. For a given bid, the amount bought or sold at a set 'market' price is simply the value of the upper limit curve at this price, provided it is greater than the lower amount at this price (otherwise it is zero).
• the (agent acting as) auctioneer now has to act as clearing house. In essence, the deals are between bidder and the auctioneer. Any surplus or deficit in goods or money is carried by the auctioneer.
• the auctioneer may itself bid in the attempt to rid itself of said surplus or deficit. To minimise such surpluses or deficits, the auctioneer may calculate the market price as being the 'clearing' price at which the total bought and sold are equal. This may be done quite simply.
• the clearing price 1100 is obtained by summing all current sell bids and all current buy bids then matching the two resulting bids to obtain a price/amount point.
• the price component is then the clearing price, which is used in combination with the individual bids to determine the amounts bought and sold by each bidder. Note that the effect of the lower bid curves may mean that the market is not completely cleared.
• the bids must be reduced or deleted correspondingly. If the price-amount point lies on the upper curve, then the bid is completely used up and may be deleted. Otherwise the upper curve is scaled by multiplying all points by a factor obtained by dividing the deal amount by the upper curve value corresponding to the deal price. The lower curve is set to zero at all prices.
• Bidders are informed of the results of their bids. Note that nothing has been specified about how often the auctioneer executes this operation, whether it is on a regular schedule (and if so whether the bid validity intervals are aligned with the execution period), whenever a new bid is received, etc. Similarly, it does not say whether the owner of the auction mechanism solicits bids actively, or just waits for them to arrive. All these factors can be specified at a higher level to create a variety of auctions (single, double, periodic, continuous, etc.)
• bids are represented by Java objects.
• the class of the object implies a particular curve parameterisation and defines appropriate operators for combining (e.g. adding), manipulating and querying bids of this type.
• the bid curves are characterised by ordered sets of points.
• the implied curves are obtained by linear interpolation between adjacent pairs of points and extrapolation to infinity beyond the pairs at each end.
• PolyLine an PolyLine is an infinite piece-wise linear curve defined by a sequence of points LinearBid.
• a LinearBid is a bid whose min and max curves are specified as PolyLines
• LinearBidPair a LinearBidPair encapsulates a buy and a sell bid for the same type of item, and provides methods, for example, to obtain the max amount point.
• CollectionOfLinearBids this is the base class for implementing auction engines.
• the content of the messages in each case originates in the sender as a Java software object, and similarly is used in the receiver as a Java software object. Depending on implementation, the content may remain in this form during transmission, or else be converted to, e.g. a textual form prior to transmission. On reception, the receiver can then instantiate an object based on this description and its own (or shared) class libraries. The descriptions given here assume that the content remains an object throughout, though some of the fields and/or procedures are only relevant to processing within the auction engine. 2.
• Auction messages assume that the content remains an object throughout, though some of the fields and/or procedures are only relevant to processing within the auction engine. 2.
• All messages are instances sub-classes of the AuctionMessage, possessing the following data fields: auctioneer: an identifier for the (agent embodying the) auction engine to which the bid is submitted; bidder: an identifier for the trading agent submitting the bid; commodity: an identifier for the type of goods or service involved; serial: a serial number, that when combined with the bidder identifier, uniquely identifies the message instance validity: a time interval defining the period over which the bid is valid. Note that this also identifies the clock with reference to which the interval is defined.
• Objects of this class are used to notify bidders of sales resulting from their bids. They have the additional properties: amount: giving the amount of commodity sold; price: giving the unit price at which the sale takes place; tradingPartner: an identifier for the trading agent to/from whom the items are sold;
• the auctioneer and tradingPartner fields will often refer to the same agent, with the agent embodying the auction engine either acting as intermediary or as the end customer / vendor, but this need not necessarily be so. Both amount and price are signed, with a positive sign indicating flow of goods or money to the bidder.
• the class Bid defines the following data fields: buying: a binary flag indicating whether this is a buy or a sell bid; allGone: a binary flag used by the auction engine. It indicates whether the bid amount has been used up.
• amount(price) this function returns a pair of numbers representing the upper and lower acceptable amounts at a stated price, or else an indication that there is no acceptable amount at this price
• price(amount) this function returns a number representing the minimum acceptable price at which the stated amount will be sold
• acceptable(point) this function indicates whether the given price/amount point lies within the acceptable region
• crossOverPoint() this function returns the price/amount point at which the two bid curves cross
• transact(point, timelnterval, otherParty) this generates and returns a SaleNotification for a transaction at the given price/amount point to/from the otherParty, valid for the given interval.
• the point must lie in the acceptable region of the bid. If the point lies on the maximum amount curve (as is usually the case), the bid is marked as used up. Otherwise, the residual amount is calculated as follows.
• the acceptable amount function is used to calculate the acceptable range at the given price.
• the maximum amount curve of the bid is scaled by the ratio of the amount sold to the upper amount of this range.
• the minimum mount curve is left unchanged as it is interpreted as the minimum amount for a single transaction.
• a PolyLine is piece-wise linear, that is the curves are continuous sequences of linear segments.
• the end segments are semi-infinite, i.e they extend to positive or negative infinity (remember the curves are monotonically increasing or decreasing).
• a PolyLine is defined by a sequence of price/amount points (held in data filed: points in ascending or descending order of x, i.e price) representing the vertices between the segments.
• the semi-infinite end segments are obtained by extrapolating the segment defined by the first/last pair of points.
• the PolyLine class defines a number of operations that are useful in processing bids, including: y(x): returns the y (amount) value - obtained by interpolation/extrapolation - corresponding to the given x (price); x(y): returns the x (price)value corresponding to the given y (amount); scaleBy(f actor): this multiplies they (amount) coordinates of all vertex points (an hence of all points) on the PolyLine by the factor. lntersections(another PolyLine): This returns a set of intersection points with the given PolyLine; add(another PolyLine): This returns a new PolyLine obtained by adding the original PolyLine to the one supplied in the argument.
• Addition involves adding the y (amount) coordinates at corresponding points on the two PolyLines.
• the vertices of the new PolyLine are obtained from the two original sets of vertices as follows.
• the vertices of each original line are added to the corresponding points on the other line (obtained by interpolation).
• the two new sets of points are combined, duplicate points removed, and reordered in ascending / descending sequence of x (price) value.
• Minumum(another PolyLine) Returns a new PolyLine which at all values of x (price) is the same as the input PolyLine with the lower y (amount) value).
• auction engine kernel The base class for auction engines is CollectionOfBids. In the case of bids based on PolyLines this is specialised to CollectionOfLinearBids. As the name suggests, instances of this class encapsulate some form of database of bids. In the case of the reference implementation, this simply takes the form of a Java Vector each for buy and sell bids: buyBids and sellBids. The other main data item is commodity, which identifies the type of item that this engine handles. Note that a give auction engine instance handles only one type of commodity, though it is possible for several auction engines to be grouped within one agent.
• a CollectionOfLinear bids also has the following means of interrogating or manipulating the bid collection and its contents: addBidToCollection(Bid): adds the bid (which must refer to the correct commodity) to the collection; purgeBids(time): This removes expired bids, i.e. ones that have been used up or whose validity interval ends prior to the given time, from the collection.
• SumBuyBidsAt(price, time) This returns the amount range obtained by taking the union of acceptable amount ranges of buy bids valid at the stated time, at the stated price. This range represents the upper and lower bounds of the total amount available for sale at the current time; sumSellBidsAt(price, time): As above, but for sell bids.
• NetBidsAt(price, time) This returns the amount range obtained by taking the intersection of the summed buy and sell bids. It represents the upper and lower bounds on the amount that can actually be sold at the current time at the given price.
• BestMatch(bid, time) returns (a reference to) the pair of bids (one buy and one sell bid, as an instance of LinearBidPair - see below) made up of the bid and the one that matches it best at the current time. The criterion for best match is defined as part of LinearBidPair. In the reference implementation, it is the maximum sale amount; bestPair(time): returns (a reference to) the pair of bids (valid at the stated time) ranked best over all.
• Cross ⁇ ver(time) returns the price/amount point at which the sum of the buy bid max lines and the sell bid lines intersect. Only those bids valid at the stated time are used.
• transactAIIAt (price, intermediary, time): This generates transactions (here, generating a transaction means creating sale notifications and reducing the bids accordingly) between bidders and the specified intermediary agent at the specified price, using the bids' transact functions, returning the corresponding SaleNotification objects.
• the intermediary will normally be the agent containing the auction engine, but need not be so.
• the amounts for the transactions are from the valid bids by taking the upper figure of the amount range returned by the bid's amount function. There is no transaction if the bid has no acceptable amount at this price.
• TransactPairWise(time) This implements transactions between pairs of bidders. First the best pair is selected, and the corresponding transaction is enacted. Transactions take place at the price/amount point determined by the bid pair object. This is repeated until there are no more transactions are possible. The SaleNotifications are returned.
• the main data fields are: buyBid and sellBid, which hold the bids.
• the main operations provided are: transactionPoint(time): Provided both bids are valid at the given time, this returns the 'best' price-amount point within the acceptable region of both bids, or else an indication that no acceptable point exists. In the reference implementation, this is the point corresponding to the maximum acceptable amount. This can easily be found by calculating the intersection points of the two buy bid curves with the two sell bid curves, rejecting any that lie outside the acceptable region, then selecting the highest remaining point. Often this will be the intersection of the two maximum amount curves. Transact(point, timelnterval): This generates a transaction between the two bidders at the specified price-amount point using the bids' transact methods. It returns the two SaleNotifications
• a double auction is one in which (multiple) buyers and sellers bid, there being a symmetry between the roles of buyer and seller.
• a continuous double auction is one in which bidding and resolution of bids into transactions takes place as a continuous parallel or interleaved process.
• a periodic double auction is similar to a continuous one, except that the bidding and/or bid resolution is performed at regular intervals rather than continuously. In this example, the bidding takes place continuously, but the bid resolution takes place at regular intervals known to the bidders.
• the bidders can thus take into account the periodicity of the auction when setting the validity intervals of the bids, effectively specifying which auction round or rounds the bid will be considered in.
• a bidder can for example submit a series of bids with each subsequent one becoming valid the round after the previous one expires.
• Figure 3 shows a simple periodic double auction engine formed by adding a wrapper 310 to a CollectionOfLinearBids 315.
• the wrapper 310 is made up of: a register 320: this holds information on trading agents currently using the service. It receives and acknowledges registration and deregistration messages from agents. When a registration message is received, a message is sent to the trading agent giving details of the periodicity of the auction rounds. Should this periodicity change, a message is sent out to all registered agents with the new information.
• the registration information may be used to relate agent names/references to addresses.
• a timer 325 This holds the definition of the auction periodicity. It signals the auction supervisor when a new auction round is due. It notifies the register when of new periodicity should this change.
• An auction supervisor 300 This passes new bids to the collection as they arrive. On receipt of a signal from the timer 325, it signals the bid collection 315 to perform a round of the relevant type of auction and then to perform a purge. It then routes the resulting sale notifications to the appropriate agents.
• this section describes, by way of an example, a simple trading agent 200 that might trade via such an engine.
• This agent 200 sells a single commodity via a single auction forum.
• a simple buying agent would be similar except, obviously, it buys rather than sells.
• an agent may buy and/or sell many commodities via many auction fora. It may also control means of production, i.e. of converting among types of commodity. Such means of production are described as 'technologies' and are characterised by production and cost functions.
• this simple selling agent 200 merely has a means of acquiring a set amount of its commodity per unit time at a fixed cost.
• a task engine 230 is shown. In the trading agent 200 as described below, the task engine is not required as the agent is not processing, producing, consuming or converting goods.
• the trading agent 200 registers with its chosen auction engine 305 and receives the periodicity information from the auction engine's timer 325 in return. It decides its initial bid and submits it with the validity interval set to include one or more of the times at which an auction round will take place, making allowances for the time it may take for a message to be delivered. Let us say that the trading agent 200 uses a fixed validity interval length. It also decides how frequently it is going to submit bids. Let us say that the bid frequency is chosen to be the same as the auction frequency. It submits further bids at this frequency, adjusting the bids according to any new information received since the last bid.
• the trading agent 200 controls a mechanism 205 for storing and transferring commodity items and money to designated other agents.
• the commodity items 210 are stored in a stockpile 1000.
• receives a sale notification from the auction engine 305 it signals 'authorisation to sell' to a transfer controller 215 of this mechanism 205.
• the authorisation to sell includes the sale notification.
• the mechanism 205 signals to a corresponding mechanism 225 in a designated 'other agent' that it is 'ready to transact' (again enclosing the sale notification). If the corresponding mechanism 225 has received an authorisation to sell (from its own agent) and a matching 'ready to transact' and the time is within the validity interval, then the controlled mechanism 205 sends the commodity items and accepts receipt of the money. If no, or too little money arrives, an exception is flagged.
• the agent's behaviour is based on the assumption that its trading environment can be treated as a collection of trading agents, one per commodity/auction forum that the agent trades in, and that these agents alter their bids relatively slowly. So our simple selling agent 200 acts as though it is selling to a single buying agent 720 with a monotonic max bid curve of otherwise unknown shape. Given the monotonicity of the two bid curves and that the auction mechanism will yield a sale at their intersection point, we can see that shifting the sell curve upward (increasing the amount datum) results in selling more items at a lower unit price. Shifting the sell curve to the right (increasing price datum) results in less being sold but at a higher unit price.
• the simple selling agent 200 in this example acquires/creates the items 210 it sells at a constant rate and cost. Its optimum steady state is characterised by a sale rate equal to this acquisition rate, i.e with a stockpile 1000 at a constant level. There is no value in holding stock for its own sake. The most desirable stock level will depend on anticipated sale fluctuations, and here we will take it as a given fixed value. The agent's utility thus decreases as the stock level deviates from this value and also as its rate of change deviates from zero.
• control law is not dependent on the external supply/cost, so that if these do change, the agent will adapt. In this simple case, there is no question, e.g. of adjusting margins on items sold to maximise profit, as the amount sold automatically determines the unit price, and the purchase price is determined externally. This changes, however, if the agent issues both buy and sell bids (in different auction fora).
• steady state solutions i.e. buy and sell bids resulting yielding equal amounts bought and sold
• there is one such level of throughput yielding maximum profit There are now four control parameters available, the datum coordinates of the buy and sell bids, but only two independent degrees of freedom (corresponding to the position of the transaction points on the other agents' bid curves).
• a possible control strategy is to use the sell bid datum amount to control the stock rate/level using the same control law as in the simple case above.
• the buy bid datum amount is used to achieve a given profit margin.
• the price datums are set so that their average equals the average of the actual transaction prices and their difference is constant.
• the double auction mechanism and trading agent described above can be combined to form a wide variety of multi-agent trading systems.
• an agent combines attributes of both trader 200 and auction engine 305, that is it is able both to: ⁇ generate bids, participate in trading deals on receipt of SaleNotifications, etc., and ⁇ receive bids, use them to determine deals, and send out the SaleNotifications.
• the auction mechanism 405 treats its trading agent persona 400 in exactly the same way it does other agents. Thus the auction mechanism 405 remains neutral. The only difference is that bids and sale notifications can be transferred by intra-agent means (for example by Java method calls) rather than using inter-agent messages.
• Figure 4 shows as an example a basic double auction (clearMarket variant) with the auctioneer 410 acting as a trading intermediary, showing the roles of the auction 405 and trading personae 400 of the auctioneer 410.
• Figure 5 shows direct pairwise trading 500. In this case the transactPairWise mechanism is used, and there is no need for the auctioneer 410 to have a trading persona.
• the above illustrations considered auctioneer agents possessing a trading persona 400. It is also possible to give trading agents 200 an auction persona 405 in order to build systems in which negotiation between agents is direct rather than via a distinct auctioneer.
• Figure 6 shows a case pronounced of the familiar 'contract net' frequently used in multi- agent systems.
• selling agents 200 submit bids to a single buying agent 720 (incorporating an auction engine 305 in an auction persona 405).
• the buying agent's trading persona 400 submits a buy bid, and the auction persona 405 can use its auction engine 305 to determine the resulting trading deals.
• Figure 7 gives an illustration. Possession of the trading and auction personae is implied by the arrows and labelling. Only bid arrows 725 are shown. The labelling indicates the types of item bought and sold, thus a label of 2-3 indicates that the agent 715 buys items of type 2 and sells items of type 3 (with an implied ability to transform type 2 into type 3).
• agents with a maximum of one input and one output type are shown, but arbitrary n-m agents are possible. It is also possible to couple trading agents via constraints on their production functions (due for example to competition for a shared resource), so they form what can be regarded as composite agents. It should also be noted that the individual markets in different types of item can be coupled, so that the example systems form multi-commodity economic systems.
• Embodiments of the present invention are described above mainly in terms of bidding as a function of amount and price. It would however be perfectly reasonable to bid in terms of other parameters, for instance in time to delivery of goods or services, or in quality of goods or services, or rate of delivery once delivery has begun.
• the following describes a way of identifying a pair of bids which together define a mutually acceptable region based on price versus time to delivery of a resource.
• a resource which could be equipment or even a person ("worker"), can provide or receive goods or a service but has a preferred time period for delivery.
• a utility function can be expressed in terms of the components making up a bid, in this case price and time to delivery.
• a change in price and or time results in a change, a U, in the utility function for the entity concerned.
• Figure 14 shows both price-time curves on the same plot, or deal space. It can be seen that the regions defined by the curves overlap to show a mutually acceptable region 1400.
• any price-time point in that region gives an increase in utility of 3 U to both the worker and the work queue manager. Stepping up the value of 3 U eventually leaves only one point. This point defines a price-time point that gives the mutual maximum change in utility to both parties involved in the negotiation and can be selected as the price-time point to be recorded for a contract between the worker and the work queue manager.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Finance (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Marketing (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Priority Applications (1)

Applications Claiming Priority (4)

Publications (1)

Family

ID=8241722

Family Applications (1)

Country Status (4)

Families Citing this family (5)

Family Cites Families (3)

• 2000
  • 2000-11-08 AU AU11651/01A patent/AU1165101A/en not_active Abandoned
  • 2000-11-08 EP EP00973101A patent/EP1228464A1/de not_active Withdrawn
  • 2000-11-08 CA CA002389828A patent/CA2389828A1/en not_active Abandoned
  • 2000-11-08 WO PCT/GB2000/004293 patent/WO2001035284A1/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events