Note: Descriptions are shown in the official language in which they were submitted.
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
A SYSTEM AND METHOD FOR IMPLEMENTING AN AUCTION ON A
COMPUTER NETWORK
FIELD OF THE INVENTION
The present invention relates to auction systems and more particularly to
systems and methods for implementing an auction system on a network, e.g. a
computer network or a TV network, or by means of an automaton.
BACKGROUND OF THE INVENTION
The disclosures of the following documents are incorporated herein by
reference:
U.S. patents 5,282,633 granted Feb. 1, 1994 to Boylan et al.; 5,083,271
granted Jan.21, 1992 to Thacher at al.; 5,630,757 granted May 20, 1997 to
Gagin
et al.; 4,927,156 granted May 22, 1990 to Breslow et al.; 5,009,429 granted
April
23, 1991 to Auxier; 4,637,614 granted October 18, 1985 to Gibbon et al.;
4,261,575 granted April 14, 1981 to Coreiy et al.; 5,559,312 granted September
24, 1996 to Lucero; 4,922,522 granted May 1, 1990 to Scanlon; 4,998,199
granted March 5, 1991 to Tashiro et al.; 5,038,022 granted August 6, 1991 to
Lucero; 5,159,549 granted October 27, 1992. to Hallman et al.; 5083,272
granted
Jan. 21, 1992 to Walker et al.; and 5,083,271 granted January 21, 1992 to
Thacher et al.;
PCT applications: WO 95131061 filed May 5, 1995 by Catapult
Entertainment, Inc.; WO 93/23125 filed May 14, 1993 by Codemasters limited;
and WO 93/22017 filed April 30,1993; and
European patent application 0 405 776 A2 published January 2, 1991.
SUMMARY OF THE INVENTION
In a first aspect, the present invention is a computerized auction system
which includes the following features: auction means for processing bids
communicated from participants of an auction, communicating receipts of the
bids
and status details of the auction to the participants, and determining a
winner of
the participants based on the bids received and communicating the winner to
the
CA 02311353 2000-OS-23
WO 99/27476 PGT/N098/00348
2
participants; bidder means for distinctly communicating to the auction means
distinct the bids from respective the participants and processing the receipts
of the
bids and the status details of the auction communicated from the auction
means;
network means for providing communication transmission paths between the
auction means and the bidder means, information communicated across the
network means between the auction means and the bidder means being under at
least one of a first transport protocol and a second transport protocol, the
frrst
transport protocol being more reliable than the second transport protocol with
respect to insuring that data representative of the information arrives at one
of the
auction means and the bidder means, the second transport protocol being faster
than the first transport protocol with respect to time elapsed for the data to
be sent
across the network means and received by one of the auction means and the
bidder means, wherein risks associated with the information communicated under
the second transport protocol include loss of the data during transmission
across
the network means, arrival of the data at one of the auction means and the
bidder
means in an order different from a temporal order in which the data were sent
from respective one of the bidder means and the auction means, and duplicates
of
the data arriving at one of the auction means and the bidder means, the risks
being an aspect of the auction in respect of the determining the winner of the
participants.
Preferably, the bids are communicated from the bidder means to the
auction means under the second transport protocol, and the auction means
includes auctioneer means for processing the bids communicated from the bidder
means and communicating the receipts of the bids and the status details of the
auction to the bidder means, the auctioneer means communicating with the
bidder
means under the second transport protocol. The auction system preferably
further
includes administrative means for processing accounts of the participants and
processing information related to the auction apart from information
communicated between the auctioneer means and the bidder means, and the
auction means preferably includes auction support means for prompting the
auction means to begin the auction, the auction support means communicating
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
3
with the administrative means on a secure communications channel over a
transmission path that is one of outside the network means and through the
network means.
In a preferred embodiment of the auction system, the network means
includes at least one of a telephone network, a public mail network, a telefax
network, a local area network, and the Internet, the first transport protocol
includes
a Transport Control. Protocol/Internet Protocol (TCP/IP), and the second
transport
protocol includes a User Datagram Protocol (UDP).
In a preferred embodiment of the auction system, the bidder means
communicate with the auctioneer means under auction protocols layered on top
of
the first or second transport protocols, and these auction protocols may
comprise
auction administration and bidding protocols. Further, the bidding protocols
may
preferably include parameters comprising a value for each of said bids, counts
of
messages received by said auctioneer means from said bidder means for each of
IS said participants, notions of time of said auction by each of said bidder
means,
identification of winner of said participants, time when said auction started,
time
when said auction is over and a current one of said bids becomes a final bid,
number of said bids communicated to said auctioneer means at any one time,
number of bids each of said participants has left, how long one of said bids
must
survive to win in said auction, and number of said participants.
In a second aspect, the present invention relates to a computer network
auction system server which includes means for processing bids communicated
from participants of an auction across a computer network,
means for communicating information across the computer network to the
participants in response to the bids communicated from the participants,
means for determining a winner of the participants based on the bids
received across the computer network;
means for communicating across the computer network the winner to the
participants;
means for a first transport protocol under which the means for
communicating information and the winner are carried out; and
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
4
means for a second transport protocol under which the bids are
communicated across the computer network from the participants,
communications under the first transport protocol being more reliable than
under
the second transport protocol with respect to the communications arriving at
their
destination, communications under the second transport protocol being faster
than
under the first transport protocol in respect of time from initially
transmitting the
communications to arrival of the communications at an intended destination,
wherein risks associated with communicating under the second transport
protocol
include loss of the bids during transmission across the computer network,
arrival
of the bids from different ones of the participants being in an order
different from a
temporal order in which the bids were sent from respective ones of the
participants, and duplicates of at least one of the bids arriving at an
intended
destination, the risks being an aspect of the auction in respect of the means
for
determining the winner of the participants.
The computer network auction server of the mentioned preferably
comprises administrative means for processing accounts of the participants,
and
the administrative means further comprises means for processing content in a
form of World Wide Web pages communicated to and from the bidder means.
Preferably the first transport protocol comprises a Transport Control
Protocol/Internet Protocol (TCP/IP), and the second transport protocol
comprises
a User Datagram Protocol (UDP).
A third aspect of the present invention relates to a method for implementing
an auction system on a communication network, which method comprises
communicating bids by input computer equipment of respective participants
of an auction across a network to auction computer equipment;
processing received the bids by the auction computer equipment;
providing by the auction computer equipment across the network receipts
of the bids to the input computer equipment;
determining by the auction computer equipment a winner of the participants
based on the bids received from the input computer equipment; and
communicating by the auction computer equipment to the input computer
equipment the winner of the participants;
CA 02311353 2000-OS-23
WO 99127476 PCT/N098/00348
providing first and second transport protocols under which communications
between the auction computer equipment and the input computer equipment are
carried out, the first transport protocol being more reliable than the second
transport protocol with respect to the communications arriving at an intended
5 destination, the second transport protocol being faster than the first
transport
protocol with respect to time elapsed for the communications to be sent across
the
network and received by at least one of the input computer equipment and the
auction computer equipment, wherein risks associated with the communications
under the second transport protocol include loss of the communications in the
network, an-ival of the communications at one of the auction computer
equipment
and the input computer equipment in an order different from a temporal order
in
which the communications were sent from respective one of the input computer
equipment and auction computer equipment, and duplicates of the
communications arriving at one of the auction computer equipment and the input
computer equipment, the risks being an aspect of the auction in respect of the
determining the winner of the participants.
Preferably the method in accordance with the third aspect of the invention
comprises processing accounts of said participants and storing results of the
auction. The network may comprise a public mail network, a telephone network,
a
telefax network, a radio network, a TV network or a computer network.
The network utilized may comprise the Internet, the first transport protocol
then comprising a Transport Control Protocol/Internet Protocol (TCP/IP), and
the
second transport protocol may comprise a User Datagram Protocol (UDP).
Preferably the method in accordance with the third aspect of the invention
includes carrying out communications related to the bids between the auction
computer equipment and the input computer equipment under auction protocols
layered on top of the first or second transport protocols. The auction
protocols
may comprise auction administration and bidding protocols. Preferably the
bidding
protocols include parameters comprising a value for each of the bids, counts
of
messages received by the auctioneer means from the bidder means for each of
the participants, notions of time of the auction by each of the bidder means,
identification of winner of the participants, time when the auction started,
time
CA 02311353 2000-OS-23
wo ~m4~6 rc~rmro9a~oo3as
6
when the auction is over and a current one of the bids becomes a final bid,
number of the bids communicated to the auctioneer means at. any one time,
number of bids each of the participants has left, how long one of the bids
must
survive to win in the auction, and number of the participants.
In a fourth aspect, the present invention concerns a method for
implementing an auction on a computer network server, which method comprises
processing bids communicated from participants of an auction across a
computer network,
communicating information across the computer network to the
participants in response to the bids communicated from the participants,
determining a winner of the participants based on the bids received
across the computer network;
communicating across the computer network the winner to the
participants;
communicating across the computer network under one of a first transport
protocol and a second transport protocol, arrival of communications at an
intended
destination being more reliable but slower under the first transport protocol
than
under the second transport protocol, risk of communications being lost,
delayed
and duplicated under the second transport protocol being an aspect of the
auction
in respect of determining the winner of the participants.
In a fifth aspect of the present invention there is provided an auction system
based upon submittal of stake-supported bids from auction participants within
pre-
established time limits, the system possibly comprising a communication
network
for communication between an auctioneer and the participants, the auction
system
comprising
- interface means adapted for presenting bids from the participants,
- a detector means for detecting bids submitted from each participant,
- a real or simulated clock situated with the auctioneer for marking the start
and end times for an auction, recording running auction time as well as time
points
for bid detection in the detector means, and
- a decision means for deciding on an auction result, the auction result being
a
function of the bid time points.
CA 02311353 2000-OS-23
WO 99/27476 PGT/N098/00348
7
Preferably, the decision means is adapted to test whether a predetermined
time period, or a time period variable according to predetermined rules, has
passed after the last detected bid without detection of a new incoming bid,
and if
this is the case, to identify the participant with the last detected bid as an
auction
winner, and if this is not the case during the total auction duration, to
identify the
participant having submitted the last bid before the auction end time, as a
winner.
The interface means may be computer terminals attached to a real time
data-transmitting communication network, possibly via modem, and the
auctioneer
then attached to the same network by means of a computer terminal in a similar
manner. Further, the auctioneer clock, the detector means and the decision
means may then be comprised in an auctioneer computer adapted to manage an
auction in accordance with programmed auction algorithms.
The auctioneer computer algorithms are preferably adapted to manage bids
submitted in real time from the participants during the course of the auction.
In a
specific embodiment, the computer may even be adapted for possible correction
due to transmission delay from the computer terminals of the participants.
One of the auctioneer computer algorithms may be an algorithm for varying
the length of the time period to "hammer down" as a function of elapsed
auction
time or as a function of the current bid submittal rate from the total of the
participants.
In order to present to each participant the running auction progress and
activity, the participant computer terminals and also the communication
network
may be adapted for transmission of real time information from the auctioneer
computer.
In a special embodiment, the auctioneer computer algorithms may be
adapted to manage bids submitted in a group from each participant within a
fixed
point of time, so that when this point of time has passed, the computer can
immediately simulate the total course of the auction.
The total number of bids during the auction may be predetermined, and the
auctioneer computer algorithms are then adapted to manage bids submitted from
each participant at the same time as the participant makes entry for the
auction/pays the bids.
CA 02311353 2000-OS-23
WO 99/Z7476 PCT/N098/00348
8
Alternatively, if no limit is set for the total number of bids during the
auction,
the auctioneer computer algorithms will be adapted to manage a) auction
entry/payment of bids from each respective participant within a predetermined
point of time, b) thereafter calculating the total auction time, i.e. the time
span from
start to end time, c) establishing a time limit for submittal of grouped bid
times,
from each respective participant, and (d) subsequent to reception of bids from
the
participants and expiry of the time limit, simulation of the total course of
the
auction.
The auctioneer computer, the participant computer terminals and the
communication network may further be adapted for transmission of information
about the simulated course of the auction to each respective participant,
possibly
in the form of a screen presentation of the auction course in a real or
transformed
time scale.
In an even further specified embodiment, the auctioneer computer may also
be adapted to transmit, in accordance with special programming, side
information
to the participant computer terminals, (a) the side information being
controlled
during real time or simulated auction progress by the auctioneer clock and
possibly by the running auction development, for initiating picture/sound
presentation or short film of a type which is auction related, entertaining or
distracting, next to or "behind" the auction information, in order to increase
the
auction attraction, and (b) the side information comprising, during phases
with
entry/payment/pre-bidding, animations containing entertainment or auction
related
information or possibly advertising.
In an alternative embodiment of the auction system of the fifth aspect, the
auctioneer computer may comprise a memory for storing a total auction course,
so
that a participant may have data concerning the auction course presented in
his
computer terminal automatically or on request after a finished auction.
In an embodiment of the fifth aspect of the invention, which embodiment is
directed to an auction performed by means of an automaton, at least one
participant is a genuine participant and a plurality of participants is a
number of
simulated participants, the system further comprising auctioneer random
generator means controlling the number of and bidding times for simulated
CA 02311353 2000-OS-23
WO 99/Z7476 PCT/N098/00348
9
participants in accordance with predetermined random generator algorithms, the
algorithms containing parameters adjustable so as to tune auction winning
probability into a range that is compatible with national law.
In a preferred embodiment of the auction system of the fifth aspect, the
communication network may be devided in two parts,
part of the communication network may be any of a public switched
telephone network, a cellular network, a computer network and a reverse TV
channel network,
the interface means may be any of telephones, cellular phones, telefax
units, computer terminals, and TV sets having two-way communication
capabilities,
the auctioneer may be broadcasting any of a radio program, a TV program
and a text TV program via another part of the communication network, which
other
part is constituted by any of a public radio channel, a TV channel and a
closed-
i 5 circuit network, in which radio/TV/text TV program real time information
is
transmitted regarding auction progress.
in a completely different embodiment of the auction system in accordance
with the fifth aspect of the invention, the interface means are coupons to be
completed by each participant and sent to the auctioneer, a coupon containing
information about the desired bid time points for the participant in question
within a
pre-established time frame, and with a number of bids fixed according to rule
and
according to stake, the detector means is a coupon reader unit, the decision
means is a preprogrammed computer attached to the coupon reader unit, and the
clock is a simulated clock according to which the bids from the participants
are
ordered chronologically, the communication network being a public mail
network,
a telephone network, a telefax network or a computer network.
In a sixth aspect of the invention, there is provided a method for an auction
based upon submittal of stake-supported bids from auction participants within
pre-
established time limits, the auction comprising the steps of:
presenting to an auctioneer bids from the participants via at least
interface means,
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
detecting by auctioneer bid detector means bids submitted from any
participant,
using a real or simulated clock situated with the auctioneer for marking
start and end times for the auction, and for recording running auction time as
well
as time points for bid detection by the auctioneer bid detector means, and
deciding on an auction result by an auctioneer decision means, the
auction result being a function of the bid time points.
Preferably the auction method also comprises testing whether a
predetermined time period, or a time period variable according to
predetermined
10 rules, has passed after the last detected bid without detection of a new
incoming
bid, and if this is the case, identifying the participant with the last
detected bid as
an auction winner, and if this is not the case during the total auction
duration,
identifying the participant having submitted the last bid before the auction
end
time, as a winner.
BRIEF DESCRIPTION OF THE DRAWINGS
In the following a more detailed description of the invention is given,
referring also to embodiment examples illustrated in the appended drawings,
where
fig. 1 shows schematically basic elements of a computerized auction
system in accordance with a first aspect of the invention,
fig. 2 shows hardware and software platform characteristics of network
servers constituting an essential element of the computerized auction system
in
accordance with the first four aspects of the invention,
fig. 3 shown hardware and software platform characteristics of network
clients which constitute another essential element of the computerized auction
system in accordance with the first four aspects of the invention,
fig. 4 shows an auction system overview in accordance with the first aspect
of the invention,
fig. 5 is a flow diagram illuminating some necessary steps in a method in
accordance with the invention,
CA 02311353 2000-OS-23
WO 99/Z7476 PCT/N098/00348
11
fig. 6 is a communication chart showing connections between any client
and the auctioneer game engine,
fig. 7 is another communication chart highlighting connections between
auctioneer servers and the closest part of the communications network,
fig. 8 illustrates what happens in a real time version of an "American
auction",
fig. 9 illustrates what happens in an "instant" version of an "American
auction",
fig. 10 illustrates what happens in a "strategic/simulation" version of an
"American auction",
fig. 11 shows in a schematical manner all possible communication network
connections between objects participating in an auction in accordance with the
invention, and
fig. 12 shows an example of a bid board display for an auction participant in
a sealed bid type auction.
DETAILED DESCRIPTION OF THE INVENTION
Fig. 1 is a simple illustration of general features of the computerized and
network-based auction embodiment of the invention, in which embodiment the
auctioneer uses at least two network servers as shown in the left part of the
drawing, of which one server is mainly an administrative server for processing
participants' accounts and related information, while the other server
processes
bids communicated via the network from the participants, as well as
communications to the participants regarding running auction status details.
The figure further shows examples of participant PC-s and the
communication network in general.
Fig. 2 deals with examples of required hardware and software platforms for
the two necessary network servers. The drawing is text-based and self
explanatory, and the text thereof is hereby incorporated.
Fig. 3 deals with examples of required hardware and software platforms for
participant PC-s, and the drawing textual and self exptanatory. The text is
incorporated herein.
CA 02311353 2000-OS-23
WO 99127476 PCT/N098/00348
12
The original auction concept, at the outset being a network dependent
invention, can easily be adapted to cover a much wider market segment,
adaptation i.a. as follows:
- "game-boy" type machines
- distributed via CD's/simulation
- automatic game machines
- advertising tools/auctioning 3'° party company products.
The inventor believes that this will enhance, at low cost, the value of the
invention.
The basic, underlying concept "American Auction" is a concept where
strategic skills are important for winning the auction. Participating will
also
enhance the strategic (and analytic) skills over a period of play, improving
the
participant's general strategic skills in his normal lifelwork situation, thus
having
major educational and competitive elements. Last, but not least, the
participation
is entertaining via the excitement of the actual auction, and the various
supporting
themes.
Strate , education and entertainment are the three most important
attractive/seiling features of the auction concept, and will (have to) be
present in
all versions of the invention. As the focus has been on these features while
developing the Auction concept, we believe that these are present as an
integrated part of the concept.
While, however, different market segments/populations have varied focus
on these elements, it is important to "tailor" products/themes and actual
medium,
in addition to segmentation according to stake/pot size.
By doing this, the auction organizer will be able to cover a vast market,
covering
both high/iow "status" markets, also competing with more traditional game
machines, "game boy", pure entertainment games (PC and/or Internet based) etc.
It has also become clear to the inventor, that the Auction well may be an
excellent marketing tool for Computer/lntemet related (as well as non-related)
companies in advertising and selling their products through selling licenses
and
arranging auctions for these companies where their products are the auction
pot.
Such auctions may be distributed via CD (through PC magazines or otherwise),
or
via a look-up through a web browser or company home page. It is felt that this
CA 02311353 2000-OS-23
WO 99/27476 PGT/N098/00348
13
idea has a major potential for being a new marketing/advertising concept,
where a
product can be prominently displayed to an attentive audience for a long
period of
time.
The concept can be used in a number of "spin-off' products highlighting
strategic, educational and/or the entertainment features and variants of same.
1. "Game boy" type palm-held machine where the competition is simulated by
selected number of participants (competition), number of competing/own
bids and a varied number of bids per participant/groups of participants. This
flexibility will give different degrees of difficulty the same way as current
"game boy" machines, but with totally different features through themes,
strategy and entertainment value. Game pot in the form of points.
Entertaining themes, however, simpler artistically, due to limited capacity.
2. CD, or Internet distributed simulation auctions (with same features as the
"game boy" version), but with a more sophisticated animation and choices,
to be distributed (for CD's) via PC Magazines/Mail etc. and to be played via
own PC.
This product rnay be excellent as an enhancement of the animations of the
original Auction concept as well as being a stand-alone product for
entertainment as well as training for the actual Coin Auctions.
These CD/internet distributed simulation auctions are also excellent media
for advertising (see above).
3. Automatic game machines/Simulation of competition.
Same concept as 1 and 2 above, but with winning pot. Such an automaton
auction concept would be covered by Games Legislation in many countries.
The pot would be dependant on the chosen degree of difficulty.
This product will compete directly with the current game machine market,
and licensing to current operators should be considered.
4. Auctions arranged for the purpose of advertising products, where
pot/auction object is the advertising company's product/products.
Distribution both via Internet and CD's.
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
14
First preferred embodiment of the invention:
A system for conductin4 an "American Auction" across an Internet.
American auction resembles an ordinary auction, where players make bids,
and if a bid is unchallenged for some period of time the last bidder wins.
However,
in this auction all bids are the same "size", players pay for each bid they
make,
and the player who makes the last valid bid is the winner.
It. is referred in general to figs. 1-8.
The auctioneer uses, or preferably is a program which handles incoming
bids from authorized bidders. The program runs on a machine with an Internet
connection. The bidders must use machines with access to the same Internet
that
the auctioneer is connected to. The machines must be equipped with a WWW
browser which can down load and execute Java applets. All participants in an
auction communicate with the same (single) auctioneer using special "auction
protocols" layered on top of the standard Internet Protocols.
Fig. 4 is an overview of an embodiment of the computerized auction system
of the invention. First level parameters are auction rules, auction protocols,
system
capacity, performance/optimizations, auction operation and security issues.
On a next level the auction protocols are divided into an auction
administration protocol and a bidding protocol that are handled separately.
On a next level below the performance/optimizations level, one aspect is
the avoidance of data conversions, and another aspect is reduction of message
traffic.
Under the security issues there are aspects related to initialization,
bidding,
overload and result distribution.
1. The Rules (see fig. 5)
1.1 Preliminaries
~ there are N players
~ each player must buy at least min bids, before the auction starts
~ there is currently no maximum limit on the number of bids a player can
buy
~ a player cannot buy more bids once an auction has started
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
1.2 Startup
~ Players must decide if they want to play before the auction starts.
(Otherwise players could watch the auction, and join late without risk and
5 with an added chance of winning.)
~ It should be possible to rejoin the auction after the auction has started
(client machines will crash).
~ During demos players will be allowed to log in at any time.
10 1.3 The Play
~ players are notified whenever a bid is made
~ whenever a player makes a bid, a clock is started
~ if timeout seconds elapse without further bids, the player who made the
last bid is declared the winner
15 ~ there is an (imposed) upper limit on the duration of a auction, probably
between one and two hours
~ the timeout decreases as the auction grows older
There is a chicken and egg problem at the start of the auction, when no
one has made any bid, and there is no winner. it is possible to set the
initial
timeout to the entire auction duration, and reset it to a "normal" value when
the
first real bid arrives. This works well for demo purposes, but is probably not
suitable for a real auction. Another solution is to set the initial timeout
normally,
and if no one has made a bid during the first timeout seconds, the organizer
of the
auction is the winner. A third solution is to have a "house player" who gives
a
single bid sometime at the start of the auction, and is quiet thereafter. The
house
player wins on behalf of the auction organizer.
The auction needs to stop some time. Assume there are 3600 players,
each with 10 bids available. Wth a timeout of 10 seconds, a worst case auction
will last 100 hours, which is clearly not acceptable.
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
16
In one embodiment, the timeouts are decreased linearly as the auction
grows older. However, the timeout cannot be allosed to approach zero, so that
the
round trip time becomes greater than the timeout. A timeout lower limit must
be
set, or one solution might be to publish a deadline for each auction. If the
auction
reaches the deadline without having established a winner, the Xth bid to
arrive
after the deadline becomes the winning bid.
1.4 Payoff
~ unused bids in excess of min are returned to the players
~ collect penalties each player must pay for at least min bids
~ the auction organizer takes a cut (e.g. 20%) of the total income, the rest
(the pot) is paid back to the participants (winners)
~ players who have not made any bids get nothing
~ the winner gets some fraction rp ize (e.g. 80%) of pot
~ the winner gets all his bids refunded (if possible)
~ while there are money left: the players who have made fewest bids get a
refund of their made bids (not their penalty bids)
~ any excess (round off errors etc.) go the auction organizer.
2. Auction Protocols
The protocol may e.g. use ASCII text encoding. Each message consists of
some number of fields, separated by blanks. The first field is a single "tag"
character which identifies the type of the message.
2.1 Auction Administration
It is convenient to use a reliable connection for the administrative
commands, Login and Quit.
Referring to fig. 6, when a participant wishes to send an administrative
command (Login or Quit), he (the client) should follow the following steps:
1. open a TCP connection to Auctioneer server/Game engine (using
the same port number as the UDP connection for bidding uses).
2. format and write the command to the connection
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
17
3. read the response (or possibly "end of file")
4. close the connection
In fig. 6, lower part, are shown two sequential access storage media, i.e.
one containing data regarding legitimate participants (players) and one for
storing
logs, both connected to the administrative network server.
It is assumed that the administrative system distributes a client code to the
participants, together with a "name" and (eventually) authentication
information,
encryption keys etc.
At the start of the auction the participant must log on to the server with a
Login mesage. The server (auctioneer) will reply with an Accept message or an
Error message.
Login = L name
port
Accept = A
winner start
now deadline
bidsmade bidsleft
timeout who
serial
1 S Error =
E string
name an alphanumeric string
port the UDP port the client whiches to use
winner the id of the current winner
now the auctioneer's idea of the current time
start when the auction started (if start > now the auction
has not started
yet)
deadline auctioneer's notion of time when the current bid
becomes final (if
deadline < now the auction is over)
serial the serial number of the message this is a reply
to
bidsmade how many bids have been made so far (total)
bidsleft number of bids the player has left
who numeric id the player should use in remaining communication
with
the server
timeout how long a bid must survive in order to win
CA 02311353 2000-OS-23
WO 99/27476 PG"C/N098/00348
18
When a participant detects that the auction is over, he should ask for
results by sending a Quit message. The server wilt reply, with either a Payoff
message, a Wait message (if the auction is not over yet), or an Error message.
Quit = Q who
Payoff = P who result bidsmade bidspaid
Error = E string
Wait = W
who numeric id
result net amount won (or lost if negative)
bidsmade number of bids seen by the server
bidspaid number of bids the player must pay for
2.2 Bidding Protocol
It would be preferable to have a reliable real time communication channel
between the auctioneer and the participant throughout the auction, but the
Internet
protocols can not provide this.
Instead UDP is preferably used as the transport protocol for the bids. This
means that messages can get lost, they can arrive out of order, and they may
be
duplicated.
Message delays and message loss should be considered part of the
auction, and an aspect of the auction that participants should be aware of.
The auctioneer measures time in seconds since auction start. The
auctioneer's notion of time is the one that counts.
The participants can announce that they are still alive, and they can make
bids.
Bid = B bid serial who now
bid takes the values 0 ("I am here") or 1 ("I want to make a bid")
serial each participant keeps a count of how many messages he has sent,
the first message has serial number 0
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
19
who each participant gets a unique (numeric) identification at auction
start
now the participant's notion of auction time (unused by the auctioneer so
far)
The client program should probably send empty bids at "slightly random"
regular intervals, perhaps something like an average of two messages per
minute.
The auctioneer sends a Receipt for every message it receives from a
player. The auctioneer broadcasts a Status message whenever he receives a new
bid (and possibly at other times as well):
Receipt = R winner start now deadline bidsmade bidsleft serial who when
Status = S winner start now deadline bidsmade timeout max
winner the id of the current winner
now the auctioneer's notion of current time
start when the auction started (if start > now the auction has not started
yet)
deadline auction time when the current bid becomes final (if deadline < now
the auction is over)
serial the serial number of the message this is a reply to
bidsmade how many bids have been made so far (total)
bidsleft number of bids the participant has left
who numeric id of participant
when the 'now' value of the bid this is a reply to
timeout how long a bid must survive in order to win
max number of (potentially) participating bidders (this should probably be
the number of "active" participants, and perhaps it should only
include participants with bids left)
For each participant, the auctioneer will keep track of the serial number last
seen. When the auctioneer receives a bid (or an "I'm here" message), it will
check
the serial number of the new message against the saved serial number.
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
~ If the new serial number is greater than the saved one, it is accepted,
analyzed, and replied to. .
~ If the new serial number is less than or equal to the saved number, it has
arrived out or order (or it may be duplicate). The message is ignored
5 (and not replied to).
The client should probably compute a running estimate of the round trip
time, and it is probably a good idea for a client to synchronize it's notion
of time
with that of the auctioneer.
It is the auctioneer's count of the number of bids made by a participant
10 which counts. The client should probably keep track of the last message it
has got
a receipt for, and attempt to synchronize the local count of the number of
bids
made, with that of the auctioneer. The client program should probably not
prohibit
the participant from sending more bids than the participant is supposed to.
15 3. Capacity
Each participating bidder should get a notification of new bids "immediately"
when a new bid is accepted from a legitimate bidder. Such notifications
("status
messages") are ASCII text messages, they are small (less than 100 characters),
and the content is not secret.
20 The time from the auctioneer gets a new bid until it can start broadcasting
status messages is negligible compared to the time it takes to do the
broadcast.
A machine which executes the auctioneer program should have the
capacity to send the same (small) message to N different UDP addresses in the
course of S seconds, where N is the number of participating bidders, and S is
an
acceptable approximation of "immediately".
The status message will be sent to one bidder at a time, so that the delay
(from the auctioneer) will be 0 for the first bidder and S seconds for the
last.
The bidders will in addition experience network delay. It is hard to predict
how much delay will be acceptable to the bidders. One might guess that a total
delay of less than 1 second is more than good enough, while delays greater
than
4 seconds will be unacceptable.
CA 02311353 2000-OS-23
WO 99/Z7476 PCT/N098/00348
21
Tests have been performed using Sun Sparcstation 20 machines running
Solaris 2.5. It seems that these can send somewhere between 1000 and 2000
UDP messages per second.
4. Performance and Optimizations
4.1 Avoiding Data Conversions
Messages and togs are textual, all numbers are transmitted in decimal. This
is good for debugging purposes, but the server will spend a fair amount of
time
converting between binary data and textual format. Either binary formats or
special purpose textual routines could improve speed.
4.2 Reducing Message Traffic
Clients should send few "I'm here" messages. Clients will probably receive
sufficient number of Status messages to stay reasonably updated.
Sending Status messages to all clients is the main bottleneck. IP mutticast
would probably remove this bottleneck, but is unfortunately not generally
available.
One should try to avoid "useless" status messages, for instance by trying to
detect if a batch of bids arrives at more or less the same time, and send a
status
message only when the last one has been processed.
If the load is very high, and there is a batch of bids coming in, one could
quietly "drop" all bids but the last (players would gain by this).
If the load is high, try to avoid sending Receipts for non winning or empty
bids.
One could let the server send "unsolicited" receipts if it has dull periods.
5. Running an auction
A real auction should be handled using (at least) two web servers, see
figs. 1, 2 and 7.
In fig. 7 is shown an example of connections between the closest central
Router in the network and the auction servers. An administration server has a
two-
way connection to the network, operating under a first transport protocol that
is
CA 02311353 2000-OS-23
. . WO 99/27476 PCT/N098100348
22
reliable, however not necessarily very fast. This server is able to present a
WWW
menu leading to a demo, a log on possibility for a participant, other types of
information, and a credit cheque feature is also included.
The administration server provides user names, passwords etc. for an
S auction server that has another type of connection to the network, i.e. a
connection operating under a faster, but less reliable transport protocol.
This fast
connection takes care of the actual real time bidding process in which
messages
(bids) must be conveyed rapidly to the auctioneer, as well as receipts to the
participants.
A third auctioneer server has also been included in the drawing, which
server takes care of messages that are common to all participants, and may
operate under the first mentioned transport protocol.
The main administrative server handles accounts, auction information and
web pages, and should not execute on the same machine as the auctioneer.
A "small" web server must execute on the same machine as the auctioneer,
This server communicates with the main server across a secure channel, and has
the following tasks (see also fig. 2):
~ on request send Java code to legitimate auction participants (bidders)
~ start the auction program (the auctioneer) at the correct time with the
correct parameters
~ save the result of an auction (logs and payoff matrix)
The auctioneer is preferably a normal Unix program, and can be started
from the command line:
# auction options
The options are:
- I string set log-prefix to string. As a special case, if log-prefix is not
set, all
logs go to standard output.
- b file name of a file of legal bidders, no file implies demo mode. This file
is
currently an ASCII text file, containing one line for each legal bidder.
Each fine consists of at least two fields, separated with whitespace.
The first field is the name of the bidder. The second field is the
CA 02311353 2000-OS-23
WO 99/Z7476 PCT/N098/00348
23
maximum number of bids this bidder is allowed to make. Further
fields are currently ignored, but are expected to contain security
information (keys, passwords).
- p port number of the port to use. The same port number is used for UDP
and TCP. The current default is 6010, which is a fairly random
choice.
- s time when the auction starts. Currently two formats are accepted: +n
starts in n seconds, or h.m starts today at h.m o'clock. Current
default is +1 (start after 1 second).
-d minutes how long the auction lasts. Current default is 20 minutes.
- t seconds initial timeout (default is 20 seconds).
- m max default max number of bids per bidder when running demos
(default 8).
-D demo mode, allow anyone to log in (implied if no -b option)
The auctioneer prints a list of authorized bidders before the auction starts
(a requirement for accounting and audit reasons). The first line identifies
the
auction, the second is a comment, and the remaining lines are one for each
bidder.
Each line contains a numeric id, the name of the bidder, and the number of
bids he has available.
Example:
# ./auction (0.9) 1997/11/17/10.19.36 = 000879760176 castor
# id who bids
000000. 0
000001 Eigil 8
000002 Tom 8
000003 Eirik 8
000004 Brynjulv 8
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
24
During the auction, the auctioneer prints interesting events to a log file.
Each line starts with a "time-stamp", which is the current, auctioneer time
(in
seconds since some reference time), followed by a "serial number" within each
second.
Log lines are either Comment lines, Login lines, Quit lines, Bid lines or
Status lines. Status lines are printed whenever a new status message is
broadcast.
Comment = time-stamp # comments
Login = time-stamp L id port name addr result
Bid = time-stamp B bid id serial time disp
Status = time-stamp S winner left timeout total
Quit = time-stamp Q id
id numeric id
winner the id of the current winner
port which port the bidder wishes to use for status messages
name real name of bidder
addr Internet address of bidder
result one of "ok", "no" or "late"
serial serial number of the bid
bid 1 (real bid) or 0 (no bid)
time bidders notion of time (unused by auctioneer)
disp how the bid is treated
(emptyBid/GameOver/waitABit/noneLeft/Accepted)
left time left until deadline (from timestamp)
timeout current timeout value
total total number of bids made by all bidders so far
CA 02311353 2000-OS-23
WO 99/27476 PCTlN098/00348
An example except:
0879760175.00000 # ./auction (0.9) 1997/11 /17/10.49.36 = 000879760176 castor
0879760177.00000 # NOTSTARTED -~ RUNNING
0879760177.00001 S 000000 1199 020 0
5 0879760179.00000 L 1 43391 Eigil 156.116.2.222:43391 ok
0879760179.00001 B 1 00001 000000 879760179.854896 accepted
0879760179.00003 S 000001 020 020 1
0879760180.00021 B 1 000004 000008 879760180.886145 noneLeft
0879760238.00001 # result printed
10 0879760238.00002 S 000002 -01 019 32
0879760243.00000 Q 000001
0879760249.00002 # auction over : 879760237
After the auction is over, the auctioneer prints a result file, which consists
of
i 5 an initial identifying line, then a header line, followed by one line for
each active
bidder. Each line contains the bidder's numeric id, the bidder's name, the net
result, and the number of bids made.
Example:
# ./auction (0.9) 1997/11117/10.49.36 = 000879760176 castor
20 # id who result bids
000000 . 0 0
000001 Eigil -8 8
000002 Tom 17 8
000003 Eirik -8 8
25 000004 Brynjulv -8 8
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
26
6. Source Code
# date
Fri Nov 7 13:18:45 MET 1997
# we bids.c
commands.c
log.c main.c
payoff.c player.c
rungame.c
util.c game.h
137 481 3152 bids.c
135 425 2783 commands.c
39 104 765 log.c
164 650 4813 main.c
113 446 2477 payoff.c
108 426 2732 player.c
200 640 4643 rungame.c
133 439 2954 util.c
128 541 3287 game.h
1157 4152 27706
total
main.c main program for the auctioneer
rungame.c actually run the auction
bids.c handle incoming bids
commands.c handle incoming (tcp) commands (logon and
quit)
payoff.c implements current rules for payoff at
end of auction
player.c readlcreate player data structures
log.c implements logging functions
util.c various utilities
game.h contains common typedefs and declarations
client.c a program which creates one or more clients
7. Security Issues
7.1 Initialization
It is here assumed that the auctioneer program will be started by a minimal
web server running on the same machine as the auctioneer.
This minimal web server will communicate with the main administrative web
server using SSL, and will deliver Java code to authenticated clients
(participants).
CA 02311353 2000-OS-23
WO 99/Z7476 PCT/N098J00348
27
7.2 Bidding
During the auction the participants send Bids, and the Server sends
Receipts and Status messages. Message loss is part of the game.
Cheaters may attempt to listen to message traffic they are not entitled to
see, they may attempt to inject false messages into the message streams, they
may resend genuine messages, or they may push "junk bytes" into the message
streams.
Authentication and encryption techniques can be used to ensure the
integrity of messages, at a possibly substantial cost in processing time.
The simplest approach is to have the auctioneer share a secret key with
each player. This key is used to encrypt and decrypt Receipts, Bids and Status
messages.
There does not seem to be any compelling reason to keep the content of
messages secret. If this is so, it is sufficient if we use the key to attach a
signature
to each message.
7.3 Overload
One possible attack could run as follows: A participant decides to bid. As
soon as she gets a receipt she activates one or more programs which attempt to
block other participants from getting their bids through to the server. These
programs could send as much junk data as possible to the auctioneer.
A possible counter to this sort of attack is for the server to slow down the
clock if it receives a burst of junk.
7.4 Result Distribution
The server writes the result and the log to files, e.g. sequential files as
shown in fig. 6. Administrative routines must ensure that these files are kept
as
long as needed, and that they are not tampered with.
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
28
8. Further preferable features
~ The Auctioneer should minimize the number of status messages sent.
~ The Auctioneer must provide signed (or possibly encrypted) messages.
There are public domain C implementations of MD5 which can be used
as a basis for signing messages.
~ The Auctioneer must handle overload gracefully. A suitable strategy for
this must be specified and implemented.
~ It must be possible to ensure that auctions finish in a reasonable amount
of time. A strategy for timely termination of an auction must be specked
and implemented.
FURTHER AUCTION EMBODIMENTS
A) "REAL TIME" - Interactive, see fiq. 8.
Fig. 8 relates to the real time embodiment of the computer network auction
system. A clock symbolizes the starting time of the auction, prior to which
time
participants must have signed on and bought a predetermined number of bids.
The "rolling film" symbolizes the running auction time period, during which
any participant may place his successive bids at successive points of time to
stop
the "auction hammer" from falling all the way down. The rolling film may also
symbolize a log of the auction progress, which log can be "replayed" at a
later
time.
The real time auction is played interactively in "real time" starting at a
fixed
time and ending when one participant wins. (Exactly like a "normal" auction.)
Bids
are bought ahead of time, and used during the auction at participant's option.
The length of the auction depends on the allowed number of participants
and bids per participant. Theoretically, the auction may be never-ending,
therefore
it is important to limit auction time by limiting number of bids (participants
and/or
bids). Likely maximum is 2500 bids (say: 5 bids and 500 participants)
CA 02311353 2000-OS-23
WO 99127476 PCT~~g
29
The auction does not start unless bidding starts. It is unlikely that anybody
wants to be the first bidder. Therefore the auction machine has one bid which
is
used to start the bid process (1S' bid only).
A bid wins as long as no other bids come in within a set number of
seconds. At the outset this time period is planned set at 30 seconds. (As
visualized by timer count-down meter ("auction hammer falling") presented on
participants' PC screens.)
To limit total auction time, this variable (30 seconds until winning) may be
reduced to 20 sec. and 10 sec. a certain time into the auction, which also
increases the intensity of the auction and the nervousness of the
participants, thus
over proportionately reducing auction time.
Safey/secur~ features how to prevent or counteract iammin4.
The net work auction must be protected from unauthorized activities from
participants, and one should also create procedures to be followed in case of
technical breakedown/loss of a significant number of participants.
In case of a technical breakdown, i.e. the loss of contact with a certain
number (major number) of participants, andlor the server is in an "overload"
situation, the auction will be stopped. A random number of bids will then be
"erased" as legitimate bids, and returned to the bidders. !n this way, nobody
can
predict which bid was the last bid, in case of manipulation. After a "clean-
up", i.e.
when on-line access has been re-established, the auction restarts.
The auctioneer shall have on-tine contact with at least n% of the
participants at any time. When this limit is crossed, the auction stops,
contact must
be re-established, and the auction then contint~.
Regarding the problem of jamming, a safety precaution for the auction, and
a precaution against manipulation, is a function where the "Java-applet" on
the
client PC continuously sends (fake) messages as an "on-line check". For an
outsider/manipulator, these checks are impossible to distinguish from real
bids,
which complicates a possible manipulation effort. Further, traditional "fire-
walls"
will be implemented for the auction server, and the highest approved security
in
coding will be implemented. At present, a 56 bit DES-algorithm is approved for
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
commercial applications from the US. This security code compares to codes
currently used by e.g. the Bank of Norway.
To eliminate a bidder with a certain jamming strategy, the auction may be
stopped in the same manner as described above, a random number of bids will be
5 cancelled to eliminate the jamming bidder, and the game will then be
restarted.
Optional features:
All of the three below items will have (be perceived as having)
entertainment value for the participants and set the auction above other
games:
10 ~ Interactivity
~ Design
~ Strategy game (log - analysis of individual strategy compared to other
participants/winner after auction end - or alternatively during auction)
- I nteractivity
15 The auction has full "real-time" interaction as one sees all actions of
other
participants, and your own actions are re-action to this.
- Design
Pure entertaining features are presented as background design visualizing
the action of the participants via theme-stories. The story must reflect the
action of
20 the participants, i.e. also be interactive with the auction-action. The
themes may
be "auction-theme with auctioneer, gold-coin machine etc.", dragons and
dungeons, war-game, etc., i.e. the themes may be unlimited as long as theme
(or
action within the story) may easily reflect the auction-action.
Another feature is that a participant may choose from a range of
25 background stories, the one to his liking, which gives him/her most
excitement.
- Strategy
One may choose different strategies for participating in the auction. The
(ultimate} point of the auction is to have the bid surviving for 30 seconds
(or as
tong as the auction-rule specifies for a winner).
30 Below we will try to present strategies as we see them presently, by
indicating in a table individual participant's chances to win as affected by
other
participants' strategy:
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
31
Individual strategy:
Action Non-Action (wait)
Other
participants'Action Reduced chances Increased chances
strategy:
Non-ActionIncreased chancesReduced chances
Alternative results
for individual
participant:
Winning (others Loosing (other
don't bid) winner)
Loosing (no more Surviving (others
bids) bid)
Remaining in Winning (bids left
auction when others have
none)
One will see from the above table that it is important for the winning
chances that the participant is counter-"cyclical" to the "mainstream"
strategy. The
strategy may have to be different for the different periods of the auction
(beginning/middle/end), as one may see a "non action" strategy in the
beginning,
and an "action" strategy towards the end, so one should actually plan more
than
one strategy for each individual auction.
An auction-log comparing individual participant's strategy with average
participant/winner will give feedback for strategy in a next auction. This, we
expect, will be perceived as "educational"P'a learning experience", and
definitely
entertaining, even if a winning strategy for one auction may be a loosing
strategy
for the next one.
CA 02311353 2000-OS-23
WO 99/Z747b PCT/N098/00348
32
Lastly, the auction log may be used to define:
1. 2"d/3"~ place (after winner)
2. winner strategy
3. optimal strategy - early/middlellate auction
4. total time in winning position
5. how many bid-rounds you have waited out ("stayed cool")
6. how many bids given at the same time
A limited number of participants give high winning chances compared to
most other game types, thus giving a high attraction value.
Market segmentation:
1$'tier segmentation: Participants must have access to PC or another type
of interface equipment.
2"tier seqmentation: Cost of bids. (Le. covers affluent and average
segment based on this variable).
Examples:
Affluent: 100/1000 USD bid (total cost at 5 bidslauction 500/5000 USD auction)
Average: 1/20 USD bid (total cost at 5 bids/auction 5/100 USD auction)
B) SIMULATION 1 Non interactive. see fiq. 9.
Fig. 9 is similar to fig. 8, but retates to a "simulated auction" embodiment,
i.e. the auctioneer computer calculates (calculator symbolized as machine in
centre) an immediate result when bids with indicated time points have been
received from all participants. A log is prepared at the same time, symbolized
by
the short "film roll" on the right, and the log can be fetched at any time
later by the
participant.
This is the auction version for participants who want full freedom in
choosing their own time for participation - without having to wait through the
auction process, or a set bid-time or auction time. The beauty (from the
organizer's point of view) of this auction is that it is an auction totally
flexible as
concerns fulfilling market demand, as one auction starts as soon as the
previous
is finished.
CA 02311353 2000-OS-23
WO 99/Z7476 PGT/N098/00348
33
This simulated auction is non-interactive, with limited number of
participants. Participants are signing on/purchasing bids, and_ bidding
individually
up to a flexible starting time (when the pre-set number of participants have
signed
on/bid).
The number of bids/participants is set before bidders can sign
on/participate. Therefore, the participant starts immediately when the set
number
of bids is entered, as a genuine off line/non interactive auction.
The server has, based on number of allowed bids (function of bids per
participant/participants), created a time simulation string, divided into
individual
blocks with enough individual blocks to allow for space between bids (unused
blocks), i.e. to allow for any bid in the string to win - at the beginning -
middle -
end). This procedure is a total replica/simulation of the "real-time" auction,
save for
the interactive element. Le. the participants cannot in this auction, react to
the
other participants during the auction. Otherwise the selection criteria for
the winner
is exactly the same.
When bids have been made, and all bids have been given in, the auction
machine will immediately simulate the time, and carry out the auction based on
bid-input. Thus a winner/winners is/are selected.
When this is done, the participants may enter the organizer's home page
and retrieve the auction log and the visualization of the auction.
Each individual will be able to see his bids on his screen, and how long
time each bid lasts. Subject to a limited number of bids per player, the whole
auction may be visualized over a period of 5 minutes.
Regarding the length of the auction, the actual simulation is instant.
However, a participant will use the time it takes to bid. Total individuality
of when
done.
Since dependent on a fixed number of bids having been made, the point in
time when the actual auction is run on the auction-machine is not known.
This auction may be played at any time, but may have a delay in selection
of winner.
Since time is simulated, the problem of 1S~bid does not appear. There will
always be a first bid. Then the auction starts.
CA 02311353 2000-OS-23
WO 99/Z747G PCT/N098J00348
34
A bid wins as long as no other bids coming in within a set number of
seconds. At the outset this time is planned set at 30 seconds.
The simulation of seconds between bids is done by allocating a number of
seconds to each block (position where bids are allowed). Since there are more
blocks in a time-string (the total auction time) than bids allowed, there may
be
open spaces/blocks between two bid representing 30 seconds, and thus a winner
may appear before auction time end. The trick is to estimate number of blocks
relative to number of bids, to allow for both a winner at the beginning/middle
and
end (last bidder), subject to total bidding strategy.
Such protection may be an issue if a participant can manipulate the auction
machine before auction starts. When time-simulation/auction winner is
calculated,
this is done off line, i.e. no jamming/manipulation is then possible from
outside
sou rces.
Optional features:
As this auction embodiment is totally non-interactive and off line with the
auction machine, the interactive feature of the other auctions is non-
existent. It
may however be provided with extra features to give a semblance of
interactivity.
(See below).
One or more of the below items should be present in the auction for
attractiveness and entertainment value:
~ Simulated Interactivity
The auction is totally non-interactive in all phases. However, one may
create, as earlier mentioned, a semblance of interaction, with pop-up theme
during
individual play, exactly the way as described under "Simulation 2", see below.
~ Design
The purely entertaining features are the background design visualizing the
action of the participants via theme-stories. The story will be simpler than
the "real
time" version (during the placing of bids), and cannot reflect interactively
the action
on the graphical "bid-board", as bidding is done over a period of (say) 15
minutes.
It is however, important to give an impression of interactivity or at least
action.
CA 02311353 2000-OS-23
WO 99/27476 PGT/N098/00348
This cannot be done by interacting with other bidders' actions however, as
this would be misleading (there will always be some participants who have not
yet
placed their bids - thus affecting strategy for an individual participant
after
individual participant made his bid). Thus the theme design must interact with
5 other parameters than actual bidding. One may bring his individual log from
a
previous auction, to guide current bidding as well as background story.
Another feature is that a participant may choose from a range of
background stories, the one to his liking, which gives him/her most
excitement, or
alternatively drop the theme stories altogether to concentrate 100% on the
bidding
10 process.
~ Strategy
Same as in "real time" embodiment.
A limited number of participants give high winning chances compared to
most other game types, thus giving a high attraction value.
15 Market segmentation:
1'' tier segmentation: Access to PC.
2"d tier sectmentation: Cost of bids (i.e. covers affluent and average
segment based on this variable), and limited/no time for playing a "real time"
auction.
C) SIMULATION 2 - Non interactivelperceived lpartlY) interactive, see fig. 10.
Fig. 10 represents an embodiment that is an intermediate solution in
relation to what is shown in figs. 8 and 9. The participants really do not
engage in
an interactive auction, but have nevertheless a specified time period,
symbolized
by the two clocks, during which to place their bids in time. The "broken" film
roll
symbolizes the non-interactive bidding during the bid period. The machine on
the
right side symbolizes instant calculation of the auction result after expiry
of the
bidding period, and the short "film roll" on the far right is a log that can
be fetched
at any later time.
This type of simulated auction is non-interactive, with unlimited number of
participants. Participants are signing onlpurchasing bids individually up to a
pre-
set starting time, but bidding during an interval of a limited time (bid-
time).
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
36
When number of bids/participants is known (at starting point), the auction
server makes a time simulation string, divided in individual blocks
(simulating an
auction), with enough individual blocks to allow for space between bids {i.e.
allows
for any bid in the string to win, as there may be gaps between each bid so
that
any bid may win - either at the beginning/middle or end).
The participants are allowed 10/15 minutes to use their bids in the string -
which may be visualized multi-dimensionally for easy bidding on a coupon.
When the bids have been entered (within the allowed bid period), the
auction machine will immediately~nstantly simulate the time (auction), and
come
up with a winner/winners.
The auction will be visualized immediately when the winner has been
"calculated", via a meter showing bid activity on a time axis, with the
individuals'
bids entered. Each individual will see his bids on his screen, and how long
each
bid lasts. Subject to a limited number of bids per participant, the whole
auction
may be visualized over a period of approx. 5 minutes no matter how many
participants are participating.
The length of the auction is independent of the number of participants/bids.
Fixed time for bidding (on-line, non-interactive). Total auction time
including
visualization may be approx. 15/20 minutes.
A benefit of this auction embodiment is that a participant not having time for
"Real time" participation (or wanting a second auction, after "real time"
play) may
enter this auction.
Since time is simulated, the problem of 1~' bid does not appear. There will
always be a first bid. Then the auction starts.
A bid wins as long as no other bids are coming in within a set number of
seconds. At the outset this time is planned set at 30 seconds. The simulation
of
seconds between bids, is done by allocating a number of seconds to each block
(position where bids are allowed). Since there are more blocks in a time-
string (the
total auction time) than bids allowed, there may be open spaces/blocks between
two bids representing 30 seconds, and thus a winner may appear before auction
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
37
end. The trick is to estimate number of blocks relative to number of bids, to
allow
for both a winner at the beginning/middle and end (last bidder), subject to
total
bidding strategy.
Jamminglunauthorized acccess - protection
Such protection may be an issue if a participant can manipulate the auction
machine before auction starts.
When a time-simulation/auction winner is calculated, this is done off line,
i.e. no jamming/manipulation is possible from outside sources.
Optional features:
All of the three below items will have (be perceived as having)
entertainment value for the participants and set the auction above other game
types:
~ Interactivity
~ Design
~ Strategy auction (log - analysis of individual strategy compared to other
participantslwinner after auction ends - or alternatively during auction)
~ Interactivity
The auction is not interactive in the normal sense (like the "real time"
version), however, this is an auction alternative for individuals not having
time for
the fully interactive version Since the auction is played (bids placed) during
a pre
set period, and the auction is visualized in "amended real time" the
participants
wilt perceive the auction as if they were participating interactively during
the
viewing/visualization.
~ Design
The purely entertaining features are the background design visualizing the
action of the participants via theme-stories. The story will be simpler than
the "real
time" version (during the placing of bids), and cannot reflect interactively
the action
on the graphical "bid-board", as bidding is done over a period of (say) 15
minutes.
It is however, important to give an impression of interactivity or at least
action. This cannot be done by interacting with other bidders' actions
however, as
this would be misleading (there will always be some that have not yet placed
their
bids - thus affecting strategy for an individual participant after he has made
his
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
38
bid). Thus the theme design must interact with other parameters than actual
bidding. One may bring his individual log from a previous auction, to guide
current
bidding as well as background story.
Another feature is that a participant may choose from a range of
background stories, the one to his liking, which gives him/her most
excitement, or
alternatively drop the theme stories altogether to concentrate 100% on the
bidding
process.
~ Strategy
Same as in "real time" embodiment.
~ Potlwinning chances
The unlimited number of participants gives lower winning chances than the
"real-time" auction, however, on the other side, the pot may be very much
higher.
Market segmentation:
1't tier segmentation: Access to PC.
2"° tier segmentation: Cost of bids (I.e. covers affluent and average
segment based on this variable), and limited time for playing.
LEVELS OF SCREEN ACTIVITIES
(VISUALIZATION): The visual story on the screen (theme) as experienced by a
participant needs to be created as interactive, with actions interacting on
different
levels with auction activities. It will be basically four levels which should
be
individually interacting as follows, and a fifth "just for fun":
~ The setting (general theme)
~ The auctioneer
~ The general participant population ("competitors" - everyone but you)
~ The individual participant (feedback on individual action)
~ Funny "pop-ups" (sit-com) - (randomly distributed throughout the auction),
just
for fun, as well as a "confusion element"
CA 02311353 2000-OS-23
WO 99/Z7476 PCTlN098/00348
39
FACTS/iNFO TO PARTICIPANTS DURING AUCTION:
Particularly in a real time computer network auction embodiment, but also
in simulation embodiments, the following information will be of interest for
the
participants, and any or all of the features listed below should be
transmitted to
the participants PC's:
~ Timing of bid-round (Fixed, random or sequential) - It is believed that the
random alternative is most exciting, where the count-down meter (to winning)
shifts randomly from 30 sec to 20 sec to 15 sec during the auction. This will
heighten the excitement, and necessitate higher concentration throughout the
auction.
~ Each bid's individual life
~ Traffic (how many bids entered during a time sequencelperiod)
~ Number of bids left (total and individual)
~ Number of bids placed (total and individual)
~ Total number of bids (total and individual)
~ Number of participants
~ Pot size
LOG PARAMETERS: The log is intended to be a guide for the participants,
informing them of their actions/ non-actions and how it affects their winning
chances. The log will also inform them of their strategy compared to
optimal/winning strategy, and give suggestions for alternative strategies
which
may help them in next auction, hence giving a feeling of winning chances "no
matter whether I was not winning this time". The auction iog will be
accessible
after the auction is over. We expect the auction log also to have an
independent
entertainment value, and can be visualized on the participant PC screens.
The following elements will be (considered to be) included in the log:
~ You are the Winner
~ Time each bid lasted (before competitive bid placed)
~ Time all bids lasted
~ How many rounds stayed cool ("wait" position at the end of a round/total
accumulated rounds)
CA 02311353 2000-OS-23
WO 99/27476 PCT/N098/00348
~ How many times stayed cool (accumulated)
~ How many times same strategy as others (acting within same "second" as
others, and how many others
~ How many times different strategy (define "different")
5 ~ Optimal strategy vs. your strategy
~ Winner's strategy vs. your strategy
~ Alternative winning,strategies in this auction (good advice for next game)
IDEAS FOR THEMES: As example of alternative themes:
10 ~ Auction with "Einstein" personifying an auctioneer
~ Auction on a Steamboat on Mississippi (1870'ish)
~ Auction on a castle in Scotland
~ "Indiana Jones" - obstacle course - liveldie (Searching for the Hoty Grail)
~ Traditional auction (with sit-corn pop-ups)
15 ~ Casino environment/high society
~ Straight auction coupon (as Lotto), the "no fuzz" version for Simulation
auctions
~ Etc.
SIT-COMIPOP-UPS: The sit-corns could be a special, recognizing feature for
20 the organizer's auctions, (example Gary Larson's "The Far Side") and could
also
be used for advertisement during the auction. The idea would be continuously
creating new pop-ups.
The pop-ups confuse the participant as well as provide the auction with
added entertainment value. They must be so interesting and comic that they
25 interfere with participant concentration, but makes the auction more fun to
participate in (as a compensation for loss of concentration - and possibly
loss of
the auction, even). Randomly appearing sit-corns should appear nvt too often,
and
should appear/disappear in say 5/6 sec.
The pop-ups can both appear in "real-time", and particularly in the
30 Simulation versions of the auction, to make those more "interactive" and
interesting/ entertaining.
CA 02311353 2000-OS-23
WO 99/27476 p~~Ogg~pp3,~g
al
Fig. 11 shows, in a general manner and similar to fig. 1, the various
parties/objects that may be involved in an auction system according to the
invention. Two or more objects may be interconnected in open or closed
communication that may be analogue or digital. In addition to participant PC-s
and
auctioneer servers, which have been dealt with extensively here above, the
following possibilities shall be mentioned:
video/automaton auctions may be realized either with a connection via a
network to an auctioneer server, or the complete auction system may be
realized
inside such an automaton, the auction type then being one with simulated other
participants. (Such a free-standing automaton may also be realized in the form
of
a small e.g. palm-held, apparatus.)
However, an automaton may of course operate as a terminal in a similar
manner as a PC.
One way of conducting an auction in accordance with the invention, is in
connection with a TV or radio show. In such a case, normal TV, text TV or
radio
channels (public or closed-circuit) may be used as one part of the
communication
network, namely for presenting the current real time auction progress for the
participants, who may e.g, use a telephone network (cellular or public
switched
network) as the network part for bidding, i.e. sending bid messages to the
auctioneer. Hence, the elements telephone, radio and TV are shown in the
drawing, along with a telefax which is also a possible interface unit in
connection
with a telephone network. It should also be noted that in a digital television
network, two-way communication will be possible, hence providing a possibility
for
TV sets with message return with the aid of touch screens or e.g. hand-held
remote controls.
Finally, in e.g. a TV show there will usually be an audience and audience
persons may also take part as auction participants, then receiving an
interface unit
(radio or wire connected to the auctioneer computer) for entering into a
bidding
session.
CA 02311353 2000-OS-23
wo ~m4~s rcrmro9sroo34s
42
Fig. 12 shows an example of a "bid board" that can be used in connection
with an "instant" type auction, see fig. 9, and such a bid board can be
presented
on a PC screen or e.g. an automaton. Placing of bids, i.e. marking specific
points
of time, is made in a simple manner by moving to hour, minute and second
positions in the three scalesldials shown, and confirming when a desirable
time
point has been set. When all allowed bids have been placed, the total bid
package
is sent to the auctioneer by using the "SEND" button. One feature that can be
included, is an "accumulated bid value", showing the sum value of all bids
made
so far at the moment of entering a bid, to give the participant an idea of the
possible winning pot.
