Field of the Invention
-
The present invention relates to computing entities configured for electronic
commerce, and particularly although not exclusively, to a method and apparatus
for making bids and offers at electronic auctions over the intemet.
Background to the Invention
-
It is known on the intemet that several commercial websites are present
which serve the purpose of auctioning goods. Referring to Fig. 1 herein there is
shown an example of a prior art system in which first and second commercial
auction websites 100, 101 are each supported by a corresponding computer
entity 102, 103 operating on a website server. A user of the auction websites
over the intemet 104 accesses the auction websites 100, 101 by use of his own
computing entity 105. In Fig. 1, auction websites 100, 101 and the user are
shown as logical entities (being websites supported by the computing entities)
and the user operates a browser software 106 resident on the users computer
entity 105. Examples of such auction websites include those provided by eBay™
and QXL. A human user having a conventional personal computer equipped with
a conventional browser software may use the browser software to access the
auction websites over the internet in known manner, and using the browser may
generate a screen display downloaded from the website which provides the user
with an interactive interface on his computer entity 105 through which the user
can participate in an auction hosted by the website servers 102, 103. To
participate in an auction, a user typically must register with the auction site server
by entering the user's details such as company name, personal name, credit card
number, and address, in to dialog boxes provided on the website interface. The
user accesses information concerning goods sold through the auction website.
-
Referring to Fig. 2 herein, there is illustrated schematically aspects of a
typical user interface display of a known auction website, which a human user
can access on his or her graphical user interface by pointing a browser software
at the website. Typically such a display comprises a listing of goods or services
to be sold, a quantity of goods or services, a current highest bid price which is
being bid for the goods or services, a number of bids which have been received
by the website for those goods or services, a time at which the auction started,
and a time at which the auctioning of the goods or services may close, as well as
other details concerning payment method and shipping terms.
-
Referring to Fig. 3 herein there is illustrated an example of a prior art screen
display accessed by a user for making a bid. A user enters an amount which the
user bids for the goods using a dialog box provided. The bid is relayed over the
intemet to the website, which inputs the bid information into its controlling
software to determine whether or not the bid is successful. Once the auction
software accepts a successful bid, a confirmation message is sent to the
computing entity of the successful bidder, and a transaction, including supply of
goods and payment for goods, occurs by conventional means, for example postal
delivery of goods and conventional credit card transaction clearance.
-
It is known in prior art systems to provide at a known auction website a
software functionality known as a 'bidding elf', which is provided as part of an
auction website, and which is capable of bidding in an auction on behalf of a
buyer. The bidding elf provides a user with a screen display having dialog boxes
into which the user can enter an upper maximum limit to which he or she is
prepared to bid for various goods. The bidding elf then places bids on behalf of
the user, varying the bid level incrementally up to the maximum predetermined
limit set by the user. The bidding elf removes the need for the user to sit at his
visual display continuously to monitor current bidding whilst the auction is
occurring and continue to increase his bid incrementally up to his maximum bid.
-
With known electronic auctions, generally a user can only attend one
auction at any one time, since the website browser can only be pointed at one
auction at any one time and the user interface of one auction website can be
displayed on a single monitor at any one time. If a user wishes to attend more
than one auction simultaneously, in order to source goods or services at the best
price from several auctions, then the user must arrange a plurality of website
browsers supported by one or more computing entities to communicate with the
plurality of auctions, and must visually monitor each separate auction site
simultaneously. Such a system is possible, using conventional technology, but is
inelegant, requiring several items of computing equipment by the user, and
requiring manual monitoring and interaction of several auction sites at once. The
prior art bidding elf can only make bids in one auction, being the auction website
with which it is associated. Different prior art elves at different websites cannot
communicate with each other to coordinate bidding in several auctions.
Summary of the Invention
-
One object of the present invention is to provide a method and apparatus to
enable a user to participate in several electronic auctions simultaneously in a
controlled and coordinated manner to obtain a best price contract for goods and
services from a plurality of auctions. In one implementation, a user may set an
upper and/or lower price limit for bid or offer of goods or services at a plurality of
auctions, and thereby participate in risk free buying or selling of goods and
services. The user may be guaranteed that the maximum price bid will not be
exceeded, or a minimum price offered will not be exceeded in specific
embodiments of the invention.
-
Specific embodiments may enable a user to obtain items at a preferential
rate in one auction whilst participating in one or more other auctions for the same
goods/services and whilst avoiding buying of more goods than required, or selling
more goods than required through participating in other ones of the plurality of
auctions.
-
According to first aspect of the present invention there is provided an
electronic trading entity comprising:
- a processor;
- a memory means;
- a communications means;
- monitoring means for monitoring a plurality of trading data displayed by a
plurality of auction entities;
- quantity calculation means for calculating quantities of items for trading
with said plurality of monitored auction entities,
- price calculation means for calculating optimal prices of items to be traded
with said plurality of auction entities;
wherein said price calculation means operates to process said trading
data to obtain trading prices for a quantity of items calculated by said quantity
calculation means, said prices calculated for a set of chosen auction entities
selected from said set of all said plurality of auction entities;
said price calculation means operating to process said selected data to
obtain trading prices for a predetermined amount of items across all said selected
set of said plurality of auction entities. -
-
Preferably the electronic trading entity further comprises search means for
searching electronically for individual ones of said auction entities.
-
Preferably said amount calculation means comprises:
- means for storing bid data describing a plurality of bids in at least one of
said plurality of auction entities;
- means for storing user bid data describing a number of bids placed by said
trading entity with at least one of said plurality of auction entities; and
- means for determining an optimum number of bids and corresponding
price amounts of said bids to place with at least one of said plurality of auction
entities.
-
-
According to a second aspect of the present invention there is provided a
method of operating an electronic trading entity for trading a plurality of tradable
items, said method comprising the steps of:
- monitoring a plurality of auction entities;
- inputting a plurality of trading data from said plurality of auction entities;
- processing said trading data of said plurality of auction entities to
determine an optimum set of amount data describing quantities and prices of said
tradable items for trading by said trading entity.
-
-
Said step of processing trading data of said plurality of auction entities
may comprise:
- storing in memory a plurality of bid data displayed by said plurality of
auction entities;
- determining a number of active bids of said trading entity already sent by
said trading entity to at least one of said plurality of auction entities;
- constructing a plurality of currently successful sets of said bid data of said
plurality of auction entities;
- determining a cost to outbid each said set of currently successful bids;
- selecting a said currently successful set of bids having an optimum cost to
outbid; and
- constructing a set of bids of said trading entity which are higher than
corresponding bids of said optimum cost currently successful bid set.
-
-
Said step of constructing a set of bids of said trading entity which are
higher than said optimum cost currently successful bid set may comprise:
- for each bid of said optimum bid set, said bid made either by said trading
entity or a third party, selecting a highest third party bid appearing in an identical
auction entity to said bid, which also appears in said optimum bid set; and
- generating a trading entity bid of an amount equal to said highest third
party bid plus a minimum bid increment.
-
-
Said step of processing said trading data of said plurality of auction entities
may comprise:
- storing in memory a plurality of offer data of said plurality of auction
entities;
- determining a number of active offers already placed by said plurality of
auction entities;
- constructing a plurality of sets of offers of said auction entities;
- determining a value of each of said set of auction entity offers;
- selecting a set of auction entity offers having an optimum value to
undercut with new offers;
- determining whether said value is within a predetermined value limit; and
- generating a set of offer data matched to said optimum set of offer data.
-
-
Said step of processing data may comprise:
- storing a plurality of offers of a plurality of auction entities,
- selecting a plurality of sets of said plurality of offers, each set having a
number of members equal to a number of items to be obtained by said trading
entity;
- for each said selected set, determining a value of said set;
- selecting a said set having a maximum value;
- generating a set of offers which correspond with said set having said
maximum value.
-
-
Said step of generating a set of offers may comprise:
for each offer of said set of optimum offers, generating an offer having
value equal to the corresponding respective offer value, minus a predetermined
amount.
-
According to third aspect of the present invention there is provided a
method of exchanging data between an electronic trading entity and a plurality of
electronic auction entities, said method comprising the steps of:
- said trading entity monitoring data displayed by said plurality of auction
entities;
- said first trading entity extracting from said monitored data, data describing
prices of individual items to be traded;
- said first trading entity determining from said price data an optimum set of
trading data for sending to said plurality of auction entities; and
- said first trading entity communicating said trading data to said plurality of
auction entities.
-
Brief Description of the Drawings
-
For a better understanding of the invention and to show how the same may
be carried into effect, there will now be described by way of example only,
specific embodiments, methods and processes according to the present
invention with reference to the accompanying drawings in which:
- Fig. 1 illustrates schematically an example of a prior art system in which first
and second commercial auction websites are each supported by corresponding
computer entity;
- Fig. 2 illustrates schematically an example of a typical prior art user
interface display of a known auction website;
- Fig. 3 illustrates schematically further features of the typical prior art user
interface display of the known auction website;
- Fig. 4 illustrates schematically operation of a trading entity according to first
specific implementation of the present invention in an intemet environment;
- Fig. 5 illustrates schematically an architectural structure of the trading entity
of Fig. 4;
- Fig. 6 illustrates schematically interaction of the trading entity with a plurality
of auction entities over the intemet and interaction of the trading entity with a
user;
- Fig. 7 illustrates schematically a logical layout of the trading entity of Fig. 4;
- Fig. 8 illustrates schematically process steps carried out by the trading entity
for procuring a single good or item from a plurality of auction entities;
- Fig. 9 illustrates schematically process steps carried out by a monitoring
and trading component of the bidding algorithm for bidding for several goods or
services at once from a plurality of auction entities;
- Fig. 10 illustrates schematically a data table recording data describing a
plurality of bids and/or offers which the trading entity is actively pursuing at a
plurality of auction entities;
- Fig. 11 illustrates schematically a bid selection algorithm for selecting a set
of bids to place across a plurality of auction entities;
- Fig. 12 illustrates schematically an array of bids for each of a plurality of N
auctions in which individual sets of bids D are selected;
- Fig. 13 illustrates schematically an example of a specific set of bids selected
exclusively from a single auction;
- Fig. 14 illustrates schematically a set of bids comprising 4 bids, placed in 2
auctions at levels which outbid currently active bids of third parties in those
auction entities;
- Fig. 15 illustrates schematically an offer selection algorithm for selecting a
set of offers to be made in a plurality of auction entities;
- Fig. 16 illustrates schematically a method for determining an optimum set of
bids to place with one or a plurality of auction entities;
- Fig. 17 illustrates schematically a set of bids which may be displayed by a
plurality of auction entities and stored by a trading entity according to a specific
embodiment of the present invention; and
- Fig. 18 illustrates schematically a set of offers which may be generated by
the trading entity, to match with a set of bids as illustrated in Fig. 17 herein.
-
Detailed Description of the Best Mode for Carrying Out the Invention
-
There will now be described by way of example the best mode
contemplated by the inventors for carrying out the invention. In the following
description numerous specific details are set forth in order to provide a thorough
understanding of the present invention. It will be apparent however, to one
skilled in the art, that the present invention may be practiced without limitation to
these specific details. In other instances, well known methods and structures
have not been described in detail so as not to unnecessarily obscure the present
invention.
-
A first specific implementation according to the present invention is
concerned primarily with electronic commerce according to the 'English auction'
system in which a seller takes competing bids from a plurality of bidders, with a
current highest bid price from one of the bidders being the price which other
bidders must exceed in order for a successful transaction to occur. Where the
highest bid price is not exceeded for a predetermined period, the seller may
choose to either withdraw the goods from auction if his reserve price is not met,
or the seller may enter into a transaction with the bidder making the highest bid in
the auction.
-
Throughout this description, transactions concerning goods or services will
be referred to. Where a transaction to buy or sell a good is mentioned, it will be
understood that the subject of the transaction may be either a good or a service
or both a good and service, the terms good and service being used
interchangeably, and similarly a reference to a transaction involving a service will
be construed accordingly to include a transaction involving a good.
-
In this specification the term "lot" is used to refer to a minimum quantity
which is subject to a single transaction. A number of individual goods or services
comprising a lot may be defined by a user of a computer trading entity according
to specific implementations of the present invention described herein or may be
specified by an entity with whom the computer trading entity trades. A user may
define a lot size for any particular type of good or service as being one, or a
preset plurality of goods or services.
-
Referring to Fig. 4 herein, there is illustrated schematically an interaction of
a trading device 400 according to a first specific implementation of the present
invention with a plurality of auction entities 402 - 404. The trading device
comprises a computer program operating to control a first computing entity 401
comprising a data processor and memory means. Each auction entity comprises
a computer program operating a corresponding computing entity 405 - 407, the
computing entities each comprising a data processor and associated memory
means, the trading device 400 communicating with the one or plurality of auction
entities over the intemet 408.
-
Referring to Fig. 5 herein, there is illustrated schematically an architectural
structure of trading device 400. The trading device comprises a data processing
means 500; an area of memory 501 for storage of data and instructions used by
processor 500; a user interface 502, comprising a video display screen, keyboard
and pointing device, for example a mouse device; an operating system 503, for
example the known Unix™ operating system, Microsoft Windows™, operating
system, or Linux™ operating system; a modem 504 for communicating with other
intemet devices; a plurality of applications 505, including a web browser 506, and
a set of algorithms 507 for placing bids and offers at auction sites, the algorithms
507 co-operating with web browser 506. The web browser 506 may comprise a
conventional web browser, for example the known Microsoft Internet Explorer™
browser.
-
Referring to Fig. 6 herein, there is shown schematically communication of
trading device 400 with the plurality of auction entities, and with a user of the
device. Trading device 400 receives hypertext mark-up language (HTML) or
XML signals 600 from the auction entities, and sends data 601, also in HTML or
XML to the auction entities over the internet. Trading device 400 communicates
with the user interface using HTML signals, and can receive data input and
commands from a user via the user interface, for example by the user typing in
commands, or using the pointing device.
-
The trading device comprises a local set of software commands on the
computer entity 401, which operate to parse information from the auction
entities, and receives HTML signals, in the same way as the web browser. The
trading device extracts information from the HTML signals concerning a current
status of an auction entity, including information on a highest current bid and the
bidding increments set by the auction entity.
-
The trading device 400 contains a plurality of algorithms for interacting with
the user and one or more auction entities as will now be described.
-
Referring to Fig. 7 herein, there is illustrated a logical layout of trading
device 400 including arrows indicating flows of data between logical components
of the trading device 400. Trading device 400 comprises a web browser 506;
monitoring and trading algorithms 700; one or more price calculation algorithms
701, an auction selection algorithm 702, and a URL store 703. Web browser 506
may monitor one or a plurality of auction entities under control of monitoring and
trading algorithm 700. Monitoring and trading algorithm 700 interacts with price
calculation algorithm 701 to obtain information concerning calculated optimum
prices and lowest/highest prices. Price calculation algorithm 701 communicates
with auction selection algorithm 702 for selecting auction entities having the best
prices for selected goods or services. URL store 703 stores URL addresses of
selected auction entities which are referred to by the auction selection algorithm
702 and monitoring and trading algorithm 700. User interface 502 communicates
with web browser 506, and monitoring and trading algorithm 700, so that a
human user of the trading device can monitor and participate in trades carried out
by the monitoring and trading algorithm 700 and actively search and select
auction entities using web browser 506. Each of monitoring and trading algorithm
700 and web browser 506 are capable of communicating with auction entities via
the modem facility 504 of the host computer entity, via the intemet.
-
Whilst communications between the trading device and the auction entities
are described herein as being carried out in HTML or XML, protocols operated by
the trading device 400 for communication in the general sense is not limited to
these languages, and in the general case communication may occur by other
standard interfaces, for example FIPA (foundation of intelligent physical agents)
defined languages.
-
In some embodiments, algorithms for communicating with agent entities
may reside within a web browser, in which case the algorithms may generate
HTML driven screens which the user may review using his conventional web
browser. Information which the trading device displays to the user includes
information concerning the status of a set of auction sites selected by the user.
The trading device may be directed to web sites by a user typing in addresses of
known websites, using the URL of the websites, or alternatively a communication
algorithm within the device may be configured to use the browser to search for
auction sites by entering in a keyword search via the browser, into a conventional
search engine, e.g. Yahoo™ or Alta Vista™.
-
A user of the trading device needs to have confidence in the integrity and
reliability of the auction entities which the trading device is communicating with.
Consequently, in the best mode implementation, rather than leave selection of
auction entities to the trading device, a user may select a plurality of auction
entities with which the trading device communicates, for example by inputting the
URL data of selected auction entities to the trading device, which the trading
device stores in URL memory store 703. Other user inputs to the trading device
include:
- A list of goods or services which the user wishes to buy, sell or monitor
for. Goods need not necessarily be actively bought or sold, but can be monitored
and a user alerted to any particular goods of interest when these arise on an
auction site.
- Information concerning auctions which the user wishes to participate
in. This information may include a general instruction to participate in any auction
which the user has pre-selected and has entered its URL into the trading device.
- A quantity of goods or services to buy or sell. This data may comprise
a maximum quantity of goods or services to buy or sell, and a minimum quantity
of goods or services to buy or sell. For example, when buying or selling
electronic components, lots of 1000 units are common, and lots of 100 units or
lower are generally not traded.
- In the case of a buy instruction from the user to the trading device,
information describing an upper bid price limit (and currency type) which the user
is prepared to pay without the trading device referring back to the user.
- In the case of buying goods or services, an absolute upper bid price
limit and currency above which the user is unwilling to purchase the goods or
services.
- In the case of selling goods or services, a lower offer limit below which
the user requires referral of price information before selling the goods or services.
- In the case of selling goods or services, an absolute lower offer limit
below which the user is unwilling to sell the goods or services.
-
If the user is buying, and the goods are within the user's upper bid limit, the
trading device may buy goods and services automatically without further referral
to the user. Similarly, if the user is selling goods and services and the prices
obtained are above the user's lowest offer limit, the trading device may sell goods
and services automatically without further referral to the user.
-
Referring to Fig. 8 herein, there is illustrated steps of a simple algorithm for
purchasing one lot of goods or service only from one of a plurality of N auction
entities.
-
In step 800, the user inputs a maximum price limit PMAX being a price which
should never be exceeded in any of the N auctions for a quantity of goods or
services.
-
In step 801, the user inputs a maximum price data PMAX into his user
interface, which is received by trading device 400. In step 801, the user enters a
referral price PREF, which is a price above which any bids to be made by the
device must be referred back to the user before proceeding. In step 802, the
trading device monitors a plurality N of pre-selected auction entities, which have
previously been selected by the user, and which are selling the goods or services
of interest to the user. In step 803, the trading device monitors the current
highest bids b in each of the plurality of N auctions monitored. This results in a
plurality of bids b1i; ..... bN, being the current highest bid operating in each of the
N auctions. In step 804, if the trading device has a currently entered bid in any of
the N auctions, which is the highest bid in that auction, that is to say if the trading
device is actually leading the bidding in any one of the plurality of N auctions,
then the algorithm idles, and continues to monitor the N auctions and current bid
prices in steps 802, 803 as described previously. However, if the trading device
is not currently leading the bidding in any one of the N auctions, in step 805 the
algorithm selects the auction having the lowest current active bid (the active bid
being the highest bid in that auction) in step 805. In step 806, it is checked
whether there is more than one auction having an equivalent lowest active bid. If
there is only one such auction, then in step 809, the algorithm calculates a bid at
the level bi + δ in the selected auction i. However, if there is more than one
auction having a lowest active bid price, that is to say that there is a same lowest
active bid price for the goods or services in more than one auction, then the
algorithm selects from these the auction having the earliest finish time, and the
lowest active bid price in step 807. In step 808, the algorithm then proceeds to
calculate a bid bi + δ in the selected auction i, where δ is the smallest bid
increment acceptable in that auction i. In step 810 the algorithm compares the
bid bi + δ with the price limit above which all bids must be referred to the user
PREF. If the bid bi + δ is below the referral limit PREF, in step 811, the algorithm
proceeds to place the bid bi + δ in the selected auction and returns to monitoring
state 802. However, if the bid bi + δ is above the limit PREF above which all bids
must be referred to the user, in step 812, the algorithm compares the bid bi + δ
with the absolute maximum price limit PMAX set by the user to see if it is below
PMAX. If the calculated bid exceeds PMAX then the algorithm stops and no further
bidding takes place. The algorithm stops in step 813. However, if the calculated
bid bi + δ is within the maximum upper price limit PMAX, in step 814, the algorithm
refers the bid to the user for authorization. If the user authorizes the bid in step
815, then the bid bi + δ is placed in the selected auction in step 816 and returns
to monitoring step 802. However, if the user does not authorize the bid, or rejects
the bid bi + δ then in step 817, the algorithm stops and no further bidding takes
place.
-
The above algorithm ensures that the user always has a leading bid in one
of the plurality of N auctions, placing the lowest possible bid to take a lead in one
of the plurality N auctions and without placing a bid in any other auction than the
one in which the lowest possible bid is placed until that bid is overtaken. When
the user's bid is overtaken in the auction in which the user is bidding, the
algorithm selects the next auction having the lowest active bid price and places a
bid in that auction. This auction may be the same auction as the one in which the
user has just been outbid in, or may be a different auction of the plurality N
auctions. The algorithm is always searching for the lowest current active bid
which allows the user to lead in one of the plurality N auctions for the required
single lot of goods or services, and always below the user's referral price limit
PREF which the user is prepared to pay without the trading device referring back to
the user.
-
The referral mechanism provided where a bid is above the user's price limit
above which all bids need to be referred back to the user PREF, but below the
user's absolute maximum price limit PMAX above which the user will never want to
bid for the lot of goods or services, is provided primarily to give the user
confidence in the trading device and gain acceptance of the bidding system from
the user. However, an optimally behaving user should not use the referral
mechanism, but should set his maximum price limit above which he would never
wish to pay to be the same as the price limit above which referrals should be
made, that is to say PREF = PMAX. The trading device will never pay more than the
upper limit set by the user, and will not reveal that upper limit to the auction, or to
competing bidders.
-
Referring to Fig. 9 herein, there is illustrated schematically an example of
procedure steps carried out by monitoring and trading algorithm 100 for bidding
for several lots of goods or services at once at a plurality of auction entities. A
number M goods of a specified type are to be purchased from a plurality of N
auctions at an optimal overall price, that is to say, the best prices available
throughout the N auctions. Using this algorithm, some of the plurality M goods
may be bought at different prices to others, but overall, the best prices for the M
goods are obtained, subject to availability, at the plurality N of auctions. In each
of the auctions, different bidders may bid a different price per good for different
lots of goods where the price depends on the quantity traded. For example, a
first bidder may bid say $500 each for 5 items (5 lots) whereas in another auction,
another bidder may bid $450 per item for 10 items (10 lots) of the same goods.
The algorithm of Fig. 9 deals with the feature of the bid price per lot being
dependant upon the size of transaction by treating each of the M lots to be traded
separately, and attaching a separate bid price to each one of the plurality M lots
to be bid for. Therefore, in the algorithm, instead of bidding $2,500 for 5 lots, the
algorithm breaks the transaction down into 5 individual bids of $500 for each one
of 5 lots, resulting in 5 bids instead of 1 bid in this example.
-
In step 900, the user selects each of the plurality of N auctions in which the
user wishes to bid for the goods or services. This may be achieved by selecting
the auctions using a conventional web browser and inputting the URL of each
selected auction into the trading device. In step 901, the user inputs the single
type of good or service, and the total number of lots M of the good or service to
be bid for in the plurality N auctions via the user interface 502. In step 902, the
user inputs an absolute maximum bid price PMAX per lot, which the user is
prepared to pay. A lot of goods comprises a predetermined quantity of goods or
services which the user is buying, and may be a single good, or a plurality of
goods, for example 1000 individual items. In step 903, the user inputs a referral
price, PREF being a cost amount per lot above which any bids must be referred to
the user before they can be entered at any of the auctions. As described above,
a user who behaves optimally will set PREF = PMAX so that in practice no referral of
price occurs back to the user. In step 904, each one of the plurality of N auctions
are continuously monitored to check the current active bid prices, where the
active bid price is the highest bid price currently operating by any bidder in that
individual auction. In general, the current active bid price in each of the plurality
of auctions will differ, but in a theoretically 100% efficient marketplace, the
currently active bid price in all auctions may be the same. In step 905, for each
auction i the algorithm considers the top Mi bids
B1 i,.....,bMi i
where b1 i ≥ bMi i
-
For each auction, the top Mi bids are stored in a table, with the highest bid
price (the highest currently active bid price which would be successful in any
auction) b1 i at the top of the data table and the lowest active bid price bMi i at the
bottom of the table, bMi i being the lowest bid price in the auction which would
succeed in buying the goods or services. Further bids in the auction, which are
currently unsuccessful (inactive) are labeled bmi+1 i, bmi+2 i ... and so on.
-
The monitoring and trading algorithm maintains a database in memory in
which for each of the N auctions which are being monitored, there is stored data
describing a price amount for a plurality of individual bids which the algorithm has
placed and which are currently active. An active bid is defined herein as a bid
which has been placed with an auction entity, and which is of an amount
sufficient to secure a trade for that lot of goods or services in the absence of any
subsequent higher bids for those same goods or services, and disregarding
whether the amount exceeds a reserve price limit set by the auction entity for that
same lot of goods or services.
-
The algorithm may also store connected with the active bid information for
each lot, further information describing the proposed trade, including for example
a description of the goods or services for which the bid is being made, a quantity
of individual items for which the bid is being made, that is to say the number of
individual items in a lot which is being bid for, a close time by which the bid will be
accepted or rejected by the auction entity, and a quality information describing a
quality of goods or services to be provided. Examples of the types of information
which may be stored by the algorithm are illustrated in Fig. 10 herein. The data
stored may comprise a bid identifier data 1000 being a unique identification code
generated by the bid algorithm for a particular bid which has been placed; an
auction identification data 1001, comprising a URL of the auction in which the bid
identified by corresponding respective bid identifier 1000 has been placed; a lot
identification data 1002, indicating a specific lot of goods or services for which the
bid has been placed; a description information 1003 comprising a brief
description of the goods or services for which the bid has been placed, or
alternatively comprising a pointer to a separate table in which a more detailed
description may be stored; a lot size, comprising the number of individual items
(goods or services) in the lot which has been bid for; a monetary amount bid
1005, including a currency indicator relating to the currency in which the bid has
been made, a time and date data 1006 at which the bid was made; a closing time
of the auction for the particular lot which has been bid for; and a status indicator
1008 describing whether the current bid is in an active or inactive state.
-
In
step 907, the monitoring and trading algorithm sums the number of bids,
being one bid per specified lot, for the specified goods/services of the same type
currently active, in all the selected auctions. For example, referring to Fig. 10,
there are 5 bids active for lots of ten thousand 10k resistors, all of which are
currently active, and spanning two individual auctions. In this example, the lot
size is ten thousand individual resistors, and the price per lot which has been bid
varies from $25 to $28. If L
i is the number of bids currently active which have
been placed by the bidding device (in the example of Fig. 10 for the 10k resistor
lots), L
i equals 5, then if for all auctions i = 1 to N, then if the total number of bids
L
i is greater than or equal to M as determined in
step 908, then no further bids are
placed and the algorithm continues to monitor each of the plurality of N auctions
in
step 904 and continues with subsequent steps 905 - 907. However, in
step
908 the number of current active bids for all auctions is less than the total number
of lots of goods or services to be obtained, that is to say:
-
Then, the algorithm places additional bids according to a bid selection
algorithm hereinafter described with reference to Fig. 11, so that an additional Q
active bids are held by the trading entity, where Q is determined in equation 2
below.
-
Referring to Fig. 11 herein, there is illustrated an auction selection
algorithm for selecting a subset of the plurality N of selected auctions in which to
place new bids. The algorithm in Fig. 11 operates in real time, continuously
inputting new bid values from each of the plurality of N auctions as they occur,
and placing new bids on an ongoing basis as bids which have previously been
placed by the algorithm are overridden by competing bids from third parties.
-
An object of the algorithm is to determine the lowest cost bids to place in the
plurality of auctions N, in order to obtain the required number of lots of goods or
services 1100. In
step 1101, the algorithm receives input of data describing the
current active bids of all of the plurality of N selected auctions. These bids
comprise all the bids which, in the absence of any new bids, will be successful in
obtaining goods or services (subject to these bids not being below a reserve price
set by the auction). These bids are shown schematically in Fig. 12 herein as an
array of bids for each auction i of the plurality N auctions. For the purpose of
clarity in this example diagram, we assume every auction is selling exactly 4 lots.
-
The trading device then determines the optimum least cost bids to place
which will result in an additional Q active bids.
-
In each auction A, there are a plurality of bids which need to be beaten in
order to be successful in acquiring a given number of goods j from that auction.
A plurality of potential sets of bids are constructed to outbid existing bids in the
plurality N of auctions as illustrated in step 1102 herein. The beatable- j set of
existing bids in auction A is defined as the set
Equation 3
(bMi i -j + 1, ... bMi i) for j ≥ 1
-
This is the set of number j lowest bids which would succeed if the auction
were terminated immediately. For example, in Fig. 12, 1201 shows the beatable
- 1 set for auction 1, and 1202 shows the beatable- 2 set for auction 3.
-
The beatable zero (beatable - 0) set of bids for any auction is defined to
be an empty set of bids.
-
A plurality of sets of bids can be formed by taking the members of exactly
one beatable - j set (j ≥ 0) from every auction Ai. The set of all sets which can be
formed by taking the members of exactly one beatable - j set (j ≥ 0) from every
auction Ai is defined as the set Φ. In Fig. 12 there are illustrated 3 members of
Φ, each with 3 elements;
- The set made from the beatable - 1 set of auction 1 (1202), and the
beatable- 2 set of auction 3, and the beatable - 0 sets of all other auctions.
- The set (1203) made of the beatable - 3 set of auction N, and the
beatable- 0 sets of all other auctions.
- The set (1204) made up of the beatable - 1 sets of auctions 1, 2 and 3
and the beatable- 0 set of all other auctions.
-
All sets D in the set Φ which do not contain exactly Q bids made by parties
other than the trading device are deleted.
-
(1103) - For each set D ∈ Φ a cost of the set D is defined
-
Where DA is the set of bids in set D made by the trading device and ji is the
number of the highest bid which has been chosen by the algorithm in a particular
set of bids of a selected auction Ai.
-
Equation 4 calculates the cost of outbidding each beatable - j set in D by
placing ji new bids of value bi mi-ji + 1 + δi, and subtracts the cost of existing bids in
these sets made previously by the bidding device. This is illustrated
schematically in Fig. 13, for a simple case where Q = 4, and the set D comprises
the highest 4 bids in a single auction. In order to be successful in auction M, 4
bids 1302 must be placed, which exceed the highest bid b1 M in auction M. The
cost of placing these bids = 4 (b1 M + δ), where δ is the minimum bid increment
allowable in the auction. Similarly, in another example illustrated schematically in
Fig. 14 herein, there is shown another set Dpr comprising a number Q = 4 bids,
placed in order to outbid the currently active bids of third parties in auctions P and
R. To be successful in auctions P and R, 4 bids need to be placed 1501, 1502,
being 2 bids of an amount bP 3 + δ in first auction P, and 2 bids each at an amount
br 3 + δ in auction R, giving a total cost 2(bP 3 + br 3 + δP + δR) for the bid set DPR,
where bP 3 is the second lowest currently active bid price in first auction P, δP is the
minimum bid increment in first auction P, br 3 is the second lowest currently active
bid price in second auction R, and δR is the minimum bid increment in second
auction R.
-
δi is the bid increment, which is specified by a particular auction. Bid
increment data is obtained by a parser in the monitoring algorithm which reads
the bid data directly from the auction entity, the data being transferred in a
language such as HTML or XML.
-
(1104) - A set of bids having a minimum cost D
MIN is obtained by choosing
D
MIN ∈
such that
Equation 5
Cost (DMIN) ≤Cost (D)
∀ D ∈ Φ -
If more than one set satisfies equation 5, then the latest auction finish
times in each set are considered. The set with the earliest such finish time is
chosen.
-
In step 1105 the algorithm then proceeds to deploy those bids in the
relevant auctions at the appropriate calculated levels, as long as those bids are
below the referral price PREF set by the user. Any new bids which are calculated
by the algorithm which are above the referral price PREF will be referred back to
the user. Under no circumstances will new bids be placed where the amount is
greater than the maximum price limit PMAX. If all bids are placed, this will result in
ji bids of amount bi mi - ji + δi being placed in each auction Ai.
-
Referring to Fig. 15 herein, there is illustrated schematically an offer
selection algorithm for selecting a set of offers to sell a plurality of lots of goods or
services in a plurality of various auctions purchasing goods or services from the
trading device. The trading device attempts to sell goods by making offers to a
competitive tender. Hence the 'auctioneer' is putting out goods to competitive
tender. The auctioneer will never receive bids, only offers.
-
The offer selection algorithm illustrated in Fig. 15 operates where a
plurality N of auction entities request goods or services sold by the trading device
400 which offers those goods and/or services for sale. Each individual auction i
buys a quantity Mi lots of goods or services. That is to say each auction entity i
posts on its website details of the quantity of lots of goods or services which it
wishes to acquire, and posts a call for offers for each of those lots of goods or
services.
-
The trading device 400 places a plurality of offers with a selection of a
plurality of N auction entities. The number of individual offers, the particular
auction with which the offer is placed, and the amount of the offer are determined
by the offer selection algorithm illustrated schematically in Fig. 15 herein.
-
The trading device monitors the plurality N auctions, each auction entity
wishing to acquire a quantity Mi goods, the number Mi varying from auction to
auction in the general case.
-
In step 1500, the user inputs details defining the quantity of goods or
services M required to be sold or supplied into the trading device 400 using the
user interface. These details are stored in local memory in the trading device for
further reference. In step 1501, the user inputs an absolute price limit PMIN for
each lot of goods or services which are to be sold, the absolute price limit PMIN
being the price below which the user is unwilling to sell or supply the goods or
services. A separate price limit PMIN is input for each lot of goods or services to
be sold or supplied. The data describing the minimum offer price PMIN is stored in
memory by the trading device. In step 1502, the user inputs a referral price data
PREF, for each lot of goods or services which are to be sold or supplied. The
referral price is the price below which the trading device cannot operate
automatically, but must refer all offers which it makes to the plurality N of auctions
back to the user via the user interface, before proceeding to place those offers. A
user behaving optimally will set the minimum price PMIN to be the same as the
referral price PREF, so that in practice the trading device once instructed to sell
items does not refer back to the user. In step 1503, the trading device monitors
the plurality of N auctions, by parsing data from the websites operated by those
auction entities, the data describing the quantity, and offer price for goods or
services of the type specified in step 1500. Auction entities may be selected on
the basis of reliability, settlement terms, delivery terms, and trading history. In the
best mode implementation, a user will personally select the plurality of N auction
entities from which the price calculation algorithm can choose, rather than leaving
the selection process to a further set of auction selection algorithms 702.
-
In step 1504, the algorithm monitors a plurality of offers from each of the
plurality N auctions, receiving the lowest current offers in each auction i of the
plurality. Where a large number of offers are posted by an auction entity, the
algorithm may be configured to only receive from each auction at most a number
of lowest offers S1 i, ..... Smi i being the same as the quantity Q of the lots of
goods/services to be disposed of. This prevents the trading device becoming
flooded with large quantities of offer data from the plurality of auction entities.
Auction entities may be pre-selected by the user in a similar fashion as described
herein above with respect to an operation by the trading device.
-
In step 1504 for each auction i the lowest Mi offers S1 i, ..... Smi i are stored.
In step 1505, for each auction, the current number of active placed offers which
the trading device has placed in the auction are stored. In step 1506, for all
selected auctions, the number of active offers of goods/services specified are
summed. In step 1507, if the number of current active offers is greater than M,
then the algorithm returns to step 1503 and the monitoring process is continued.
However, in step 1507, if the number of current active offers is less than M, then
in step 1508 the algorithm proceeds to place a set of new offers according to the
offer selection algorithm.
-
Selection of individual auctions with which to trade are chosen from the
selected plurality N of auctions, and the prices at which those trades occur is
carried out by the offer selection algorithm illustrated with reference to Fig. 16
herein. The basis for operation of the algorithm of Fig. 16 is as follows.
-
In step 1601, the plurality N of pre-selected auctions are monitored by
parsing data from the websites of those auction entities. Offer data S1 i...., SN i, for
a plurality of individual offers S for each auction Ai up to the maximum number of
auctions N is received by the trading device, suitably in HTML, or XML
languages.
-
For an auction Ai, a beatable- j set of offers is defined as being:
(Smi-j + 1 i, ....., Smi i) for j ≥ 1.
-
The beatable - 0 set for any auction is defined to be the empty set.
-
In step 1602, there are generated all sets of offers which can be formed,
by taking the members of exactly one beatable - j set (j ≥ 0) from every auction
Ai. Let Φ be the set of all such sets.
-
All sets in Φ which do not contain a number exactly Q of offers made by
parties other than the trading device are deleted or ignored in step 1603. The
remaining offer sets each having Q members are selected in step 1604.
-
For each set, D ∈ Φ a profit D is defined as
-
Where DA is the set of offers in set D made by the trading device.
-
In step 1605, a maximum offer set DMAX is selected by choosing DMAX∈Φ
such that
Profit (DMAX) ≥ profit (D)
for all D ∈ Φ.
-
In step 1606 offers are deployed in the plurality of auctions by placing ji
offers each of amount
Smi+j-1 i - δ
-
in each auction Ai, where δ is an offer increment selected by the user or
specified by the auction site.
-
Once the offers are placed with the selected auctions, then provided no
competing offers are made by third parties at a lower price than those made by
the trading device, then the offers should be accepted by the selected auctions.
-
Different numbers of lots of goods or services may be accepted by
different auction entities, possibly at different times. Thus, the algorithm of Fig.
16 may dynamically and continuously loop back to step 1601 further monitoring
the plurality of N auctions, reviewing any offers which have not yet been
accepted. If an offer is accepted, then for that particular offer which is accepted,
settlement occurs in step 1608, by the algorithm confirming by a message to the
auction entity concerned that the offer has been accepted. This message forms
a legally binding contract between the trading device and the auction entity.
Payment and delivery may occur by conventional means, for example physically
shipping the goods, and making a credit card transaction, or electronic funds
transfer by conventional means. In the best mode implementation described
herein, settlement of trades may be delegated to a human user for actual
implementation.
