WO1999027476A2 - A system and method for implementing an auction on a computer network - Google Patents

Abstract

The invention is a computerized auction system which includes 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 te participants based on the bids received and communicating the winner to the participants.

Description

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 Corely 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 ai.; and 5,083,271 granted January 21 , 1992 to Thacher et al.;

PCT applications; WO 95/31061 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 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 first 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 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 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 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; 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 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, arrival 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 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. 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. 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 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- 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, 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 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, 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-explanatory. The text is incorporated herein. 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^rd 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 life/work 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.

Strategy, education and entertainment are the three most important attractive/selling 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/low "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/Internet 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 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 may 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. First preferred embodiment of the invention:

A system for conducting 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 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 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.

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 • 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. With a timeout of 10 seconds, a worst case auction will last 100 hours, which is clearly not acceptable. 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 prize (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 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 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 When a participant detects that the auction is over, he should ask for results by sending a Quit message. The server will 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 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. • 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 (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 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.

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. 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. 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 logs 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 multicast 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 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 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:

- 1 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 line consists of at least two fields, separated with whitespace.

The first field is the name of the bidder. The second field is the 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 pod 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. - 1 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 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 An example except:

0879760175.00000 # ./auction (0.9) 1997/11/17/10.49.36 = 000879760176 castor

0879760177.00000 # NOTSTARTED → RUNNING

0879760177.00001 S 0000001199020 0 0879760179.00000 L 1 43391 Eigil 156.116.2.222:43391 ok 0879760179.00001 B1 00001000000879760179.854896 accepted 0879760179.00003 S 000001 020 020 1 0879760180.00021 B 1 000004000008879760180.886145 noneLeft

0879760238.00001 # result printed 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 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/11/17/10.49.36 = 000879760176 castor # id who result bids

000000 . 0 0

000001 Eigil -8 8

000002 Tom 17 8

000003 Eirik -8 8 000004 Brynjulv -8 8 6. Source Code

# date

Fri Nov 7 13:18:45 MET 1997

# wc 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 read/create 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). 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. 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 specified and implemented.

FURTHER AUCTION EMBODIMENTS

A) "REAL TIME" - Interactive, see fig. 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) 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 (1^st 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.

Safety/security features, how to prevent or counteract jamming.

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, and/or 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. In 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-line 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 continββs.

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 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 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: • Interactivity

• Design

• Strategy game (log - analysis of individual strategy compared to other participants/winner after auction end - or alternatively during auction)

- Interactivity 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 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 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 long as the auction-rule specifies for a winner). 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:

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 "educationalTa learning experience", and definitely entertaining, even if a winning strategy for one auction may be a loosing strategy for the next one. Lastly, the auction log may be used to define:

1. 2^nd/3^rd place (after winner)

2. winner strategy

3. optimal strategy - early/middle/late 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^sttier segmentation: Participants must have access to PC or another type of interface equipment.

2^ndtier segmentation: Cost of bids. (I.e. covers affluent and average segment based on this variable). Examples:

Affluent: 100/1000 USD bid (total cost at 5 bids/auction 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 fig. 9. Fig. 9 is similar to fig. 8, but relates 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. 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. I.e. 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 1^st bid does not appear. There will always be a first bid. Then the auction starts. 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 sources. 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. 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 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.

A limited number of participants give high winning chances compared to most other game types, thus giving a high attraction value. Market segmentation:

1^st tier segmentation: Access to PC.

2^nd tier segmentation: 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 interactive/perceived (partly) 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 on/purchasing bids individually up to a preset starting time, but bidding during an interval of a limited time (bid-time). 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/instantly 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 aucfion, after "real time" play) may enter this auction.

Since time is simulated, the problem of 1^st 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 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.

Jamming/unauthorized 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 participants/winner after aucfion ends - or alternatively during aucfion)

• Interactivity

The auction is not interactive in the normal sense (like the "real time" version), however, this is an aucfion alternative for individuals not having time for the fully interactive version Since the aucfion is played (bids placed) during a preset period, and the aucfion is visualized in "amended real time" the participants will 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 bid). Thus the theme design must interact with other parameters than actual bidding. One may bring his individual log from a previous aucfion, 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. • Pot/winning 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^st tier segmentation: Access to PC. 2^nd 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

(VISUALI-ZATION): 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 interacfing 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" FACTS/INFO TO PARTICIPANTS DURING AUCTION:

Particularly in a real time computer network aucfion 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 aucfion. This will heighten the excitement, and necessitate higher concentration throughout the aucfion.

• Each bid's individual life

• Traffic (how many bids entered during a time sequence/period)

• 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 aucfion, hence giving a feeling of winning chances "no matter whether I was not winning this time". The aucfion log 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) • 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") • 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: • Aucfion with "Einstein" personifying an auctioneer

• Auction on a Steamboat on Mississippi (1870'ish)

• Auction on a castle in Scotland

• "Indiana Jones" - obstacle course - live/die (Searching for the Holy Grail)

• Traditional auction (with sit-com pop-ups) • Casino environment/high society

• Straight auction coupon (as Lotto), the "no fuzz" version for Simulation auctions

• Etc.

SIT-COM/POP-UPS: The sit-coms could be a special, recognizing feature for 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 interfere with participant concentration, but makes the aucfion more fun to participate in (as a compensation for loss of concentrafion - and possibly loss of the aucfion, even). Randomly appearing sit-coms should appear not too often, and should appear/disappear in say 5/6 sec.

The pop-ups can both appear in "real-time", and particularly in the Simulation versions of the aucfion, to make those more "interactive" and interesting/ entertaining. 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 aucfion 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. 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 scales/dials 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.

Claims

PATENT CLAIMS 1. A computerized aucfion system comprising: auction means for processing bids communicated from participants of an auction, communicating receipts of said bids and status details of said auction to said participants, and determining a winner of said participants based on said bids received and communicating said winner to said participants; bidder means for distinctly communicating to said auction means distinct said bids from respective said participants and processing said receipts of said bids and said status details of said auction communicated from said auction means; network means for providing communication transmission paths between said auction means and said bidder means, information communicated across said network means between said auction means and said bidder means being under at least one of a first transport protocol and a second transport protocol, said first transport protocol being more reliable than said second transport protocol with respect to insuring that data representative of said information arrives at one of said auction means and said bidder means, said second transport protocol being faster than said first transport protocol with respect to time elapsed for said data to be sent across said network means and received by one of said auction means and said bidder means, eherein risks associated with said information communicated under said second transport protocol include loss of said data during transmission across said network means, arrival of said data at one of said aucfion means and said bidder means in an order different from a temporal order in which said data were sent from respective one of said bidder means and said aucfion means, and duplicates of said data arriving at one of said aucfion means and said bidder means, said risks being an aspect of said auction in respect of said determining said winner of said participants.

2. The auction system according to claim 1 , wherein said bids are communicated from said bidder means to said auction means under said second transport protocol.

3. The aucfion system according to claim 1 , wherein said aucfion means comprises auctioneer means for processing said bids communicated from said bidder means and communicating said receipts of said bids and said status details of said auction to said bidder means, said auctioneer means communicafing with said bidder means under said second transport protocol.

4. The auction system according to claim 3, wherein said auction system comprises administrative means for processing accounts of said participants and processing information related to said auction apart from information communicated between said auctioneer means and said bidder means.

5. The auction system according to claim 4, wherein said administrative means further comprises means for processing content in a form of World Wide Web pages communicated to and from said bidder means.

6. The aucfion system according to claim 4, wherein said auction means includes auction support means for prompting said auction means to begin said auction, said auction support means communicafing with said administrative means on a secure communications channel over a transmission path that is one of outside said network means and through said network means.

7. The aucfion system according to claim 6, wherein said auction support means further comprises means for storing results of said auction.

8. The auction system according to claim 6, wherein said auctioneer means and said auction support means together comprise a first computer network server coupled to said network means, and said administrative means comprises a second computer network server coupled to said network means.

9. The auction system according to claim 1 , wherein said network means comprises at least one of a telephone network, a public mail network, a telefax network, a local area network, and the Internet, said first transport protocol comprises a Transport Control Protocol/Internet Protocol (TCP/IP), and said second transport protocol comprises a User Datagram Protocol (UDP).

10. The auction system according to claim 5, wherein said network means comprises the Internet, said first transport protocol comprises a Transport Control Protocol/Internet Protocol (TCP/IP), and said second transport protocol comprises a User" Datagram Protocol (UDP).

11. The auction system according to claim 10, wherein said auctioneer means communicates with said bidder means under said UDP, said administrative means communicates with said bidder means under said TCP/IP, and said auction support means communicates with said administrafive means under a secure sockets layer (SSL).

12. The auction system according to claim 3, wherein said bidder means communicate with said auctioneer means under auction protocols layered on top of one of said first and second transport protocols.

13. The auction system according to claim 12, wherein said aucfion protocols comprise auction administration and bidding protocols.

14. The auction system according to claim 13, wherein said auction administration protocols include parameters comprising names of said participants, identification of access communication ports to said auctioneer means by said bidder means for respective said participants, identification of said winner of said participants, time reference for said auction, time when said aucfion is to start, time when said aucfion is to be finished, time when a current one of said bids becomes a final bid, number of accumulated said bids at any one time, number of said bids a particular one of said participants has left to submit in said aucfion, and how long a particular one of said bids must remain highest of said bids to become a winning one of said bids.

15. The aucfion system according to claim 13, wherein said bidding protocols 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 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.

16. A computer network aucfion system server comprising: means for processing bids communicated from participants of an auction across a computer network, means for communicating information across said computer network to said participants in response to said bids communicated from said participants, means for determining a winner of said participants based on said bids received across said computer network; means for communicating across said computer network said winner to said participants; means for a first transport protocol under which said means for communicating information and said winner are carried out; and means for a second transport protocol under which said bids are communicated across said computer network from said participants, communications under said first transport protocol being more reliable than under said second transport protocol with respect to said communications arriving at their destination, communications under said second transport protocol being faster than under said first transport protocol in respect of time from initially transmitting said communications to arrival of said communications at an intended destination, wherein risks associated with communicating under said second transport protocol include loss of said bids during transmission across said computer network, arrival of said bids from different ones of said participants being in an order different from a temporal order in which said bids were sent from respective ones of said participants, and duplicates of at least one of said bids arriving at an intended destination, said risks being an aspect of said aucfion in respect of said means for determining said winner of said participants.

17. The computer network aucfion server according to claim 16, further comprising administrafive means for processing accounts of said participants.

18. The computer network auction server according to claim 17, wherein said administrative means further comprises means for processing content in a form of World Wide Web pages communicated to and from said bidder means.

19. The computer network aucfion server according to claim 16, wherein said first transport protocol comprises a Transport Control Protocol/Internet Protocol (TCP/IP), and said second transport protocol comprises a User Datagram Protocol (UDP).

20. The computer network auction server according to claim 16, wherein said bids are communicated from said participants under auction protocols layered on top of one of said first and second transport protocols.

21. The computer network auction server according to claim 20, wherein said aucfion protocols comprise auction administration and bidding protocols.

22. The computer network auction server according to claim 21 , wherein said aucfion administration includes parameters comprising names of said participants, identification of access communication ports to said auctioneer means by said bidder means for respective said participants, identification of said winner of said participants, time reference for said auction, time when said auction is to start, time when said, auction is to be finished, time when a current one of said bids becomes a final bid, number of accumulated said bids at any one time, number of said bids a particular one of said participants has left to submit in said auction, and how long a particular one of said bids must remain highest of said bids to become a winning one of said bids.

23. The computer network aucfion server according to claim 13, wherein said bidding protocols 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 said participants, notions of time of said aucfion 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 aucfioneer 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 aucfion, and number of said participants.

24. A method for implementing an aucfion system on a communication network, said method comprising: communicafing bids by input computer equipment of respective participants of an auction across a network to aucfion computer equipment; processing received said bids by said aucfion computer equipment; providing by said auction computer equipment across said network receipts of said bids to said input computer equipment; determining by said auction computer equipment a winner of said participants based on said bids received from said input computer equipment; and communicating by said aucfion computer equipment to said input computer equipment said winner of said participants; providing first and second transport protocols under which communications between said auction computer equipment and said input computer equipment are carried out, said first transport protocol being more reliable than said second transport protocol with respect to said communications arriving at an intended destination, said second transport protocol being faster than said first transport protocol with respect to time elapsed for said communicafions to be sent across said network and received by at least one of said input computer equipment and said auction computer equipment, wherein risks associated with said communications under said second transport protocol include loss of said communicafions in said network, arrival of said communicafions at one of said aucfion computer equipment and said input computer equipment in an order different from a temporal order in which said communications were sent from respective one of said input computer equipment and aucfion computer equipment, and duplicates of said communicafions arriving at one of said auction computer equipment and said input computer equipment, said risks being an aspect of said aucfion in respect of said determining said winner of said participants.

25. The method according to claim 24, further comprising processing accounts of said participants.

26. The method according to claim 24, further comprising storing results of said auction.

27. The method according to claim 24, wherein said network comprises one of a public mail network, a telephone network, a telefax network, and a computer network.

28. The method according to claim 24, wherein said network comprises the Internet, said first transport protocol comprises a Transport Control

Protocol/Internet Protocol (TCP/IP), and said second transport protocol comprises a User Datagram Protocol (UDP).

29. The method according to claim 24, further comprising carrying out communications related to said bids between said aucfion computer equipment and said input computer equipment under auction protocols layered on top of one of said first and second transport protocols.

30. The method according to claim 29, wherein said auction protocols comprise auction administration and bidding protocols.

31. The method according to claim 30, wherein said auction administration protocols include parameters comprising names of said participants, identification of access communication ports to said auctioneer means by said bidder means for respective said participants, identification of said winner of said participants, time reference for said aucfion, time when said auction is to start, time when said aucfion is to be finished, time when a current one of said bids becomes a final bid, number of accumulated said bids at any one time, number of said bids a particular one of said participants has left to submit in said auction, and how long a particular one of said bids must remain highest of said bids to become a winning one of said bids.

32. The method according to claim 30, wherein said bidding protocols 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 said participants, notions of time of said aucfion 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.

33. A method for implementing an auction on a computer network server, said method comprising: processing bids communicated from participants of an aucfion across a computer network, communicating information across said computer network to said participants in response to said bids communicated from said participants, determining a winner of said participants based on said bids received across said computer network; communicating across said computer network said winner to said participants; communicafing across said computer network under one of a first transport protocol and a second transport protocol, arrival of communicafions at an intended destination being more reliable but slower under said first transport protocol than under said second transport protocol, risk of communications being lost, delayed and duplicated under said second transport protocol being an aspect of said aucfion in respect of determining said winner of said participants.

34. The method according to claim 33, wherein said first transport protocol comprises a Transport Control Protocol/Internet Protocol (TCP/IP), and said second transport protocol comprises a User Datagram Protocol (UDP).

35. The method according to claim 33, wherein said bids are communicated from said participants under aucfion protocols layered on top of one of said first and second transport protocols.

36. An aucfion system based upon submittal of stake-supported bids from aucfion participants within pre-established time limits, said system possibly comprising a communication network for communication between an aucfioneer and the participants, said aucfion 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 said-detector means, and

- a decision means for deciding on an aucfion result, the auction result being a function of the bid time points.

37. The aucfion system of claim 36, wherein said 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 aucfion 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.

38. The aucfion system of claim 36, wherein said interface means are computer terminals attached to a real time data-transmitting communication network, possibly via modem, and wherein the auctioneer is attached to the same network by means of a computer terminal in a similar manner.

39. The aucfion system of claim 38, wherein the aucfioneer clock, the detector means and the decision means are comprised in an auctioneer computer adapted to manage an aucfion in accordance with programmed aucfion algorithms.

40. The aucfion system of claim 39, wherein the auctioneer computer algorithms are adapted to manage bids submitted in real time from the participants during the course of the auction, and wherein said computer is adapted for possible correction due to transmission delay from the computer terminals of the participants.

41. The aucfion system of claims 37 and 40, wherein one of said aucfioneer computer algorithms is an algorithm for varying the length of said time period as function of elapsed aucfion time or current bid submittal rate from all participants.

42. The auction system of claim 40, wherein the participant computer terminals and also the communication network are adapted for transmission of real time informafion from the aucfioneer computer, in order to present to each participant the running auction progress and activity.

43. The aucfion system of claim 39, wherein the auctioneer computer algorithms are 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, said computer can immediately simulate the total course of the aucfion.

44. The auction system of claim 43, in which the total number of bids during the aucfion is predetermined, said aucfioneer computer algorithms being adapted to manage bids submitted from each participant at the same time as the participant makes entry for the auction/pays the bids.

45. The auction system of claim 43, in which no limit is set for the total number of bids during the aucfion, said aucfioneer computer algorithms being adapted to manage a) aucfion entry/payment of bids from each respective participant within a predetermined point of time, b) thereafter calculating the total aucfion 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 said time limit, simulation of the total course of the auction.

46. The aucfion system of any of claims 43-45, wherein said auctioneer computer, participant computer terminals and communicafion network are adapted for transmission of information about the simulated course of the aucfion to each respective participant, possibly in the form of a screen presentation of the aucfion course in a real or transformed time scale.

47. The aucfion system of claim 42 or claim 46, wherein said auctioneer computer is also adapted to transmit, in accordance with special programming, side informafion to the participant computer terminals, (a) said side informafion being controlled during real time or simulated aucfion progress by the auctioneer clock and possibly by the running aucfion development, for initiafing 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) said side information comprising, during phases with entry/payment pre-bidding, animafions containing entertainment or aucfion related informafion or possibly advertising.

48. The aucfion system of claim 39, wherein said auctioneer computer comprises a memory for storing a total auction course, so that a participant may have data concerning said auction course presented in his computer terminal automatically or on request after a finished aucfion.

49. The auction system of claim 36, where 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 said number of and bidding times for simulated participants in accordance with predetermined random generator algorithms, said algorithms containing parameters adjustable so as to tune aucfion winning probability into a range that is compatible with national law.

50. The auction system of claim 36 or 37, wherein

- part of said communicafion network is any of a public switched telephone network, a cellular network, a computer network and a reverse TV channel network,

- said interface means are any of telephones, cellular phones, telefax units, computer terminals, and TV sets having two-way communicafion capabilities,

- the auctioneer broadcasting any of a radio program, a TV program and a Text TV program via another part of said communicafion network constituted by any of a public radio channel, a TV channel and a closed-circuit network, in which radio/TV/Text TV program real time information is transmitted regarding auction progress.

51. The aucfion system of claim 36, wherein the interface means are coupons to be completed by each participant and sent to the aucfioneer, a coupon containing informafion 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, said detector means is a coupon reader unit, said decision means is a preprogrammed computer attached to said coupon reader unit, and said clock is a simulated clock according to which the bids from the participants are ordered chronologically, said communicafion network being a public mail network, a telephone network, a telefax network or a computer network.

52. A method for an aucfion based upon submittal of stake-supported bids from auction participants within pre-established time limits, said aucfion comprising the steps of: presenting to an auctioneer bids from the participants via at least interface means, detecting by aucfioneer bid detector means bids submitted from any participant, using a real or simulated clock situated with said aucfioneer for marking start and end times for said auction, and for recording running aucfion time as well as time points for bid detection by said aucfioneer bid detector means, and deciding on an aucfion result by an auctioneer decision means, the aucfion result being a function of the bid time points.

53. The aucfion method of claim 52, further comprising testing 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, identifying the participant with the last detected bid as an auction winner, and if this is not the case during the total aucfion duration, identifying the participant having submitted the last bid before the aucfion end time, as a winner.