Classifications

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

Definitions

• 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.
• a network e.g. a computer network or a TV network
• 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 bids are communicated from the bidder means to the auction means under the second transport protocol
• 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.
• 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)
• the second transport protocol includes a User Datagram Protocol (UDP).
• TCP/IP Transport Control. Protocol/Internet Protocol
• UDP User Datagram Protocol
• 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.
• 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.
• 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
• the first transport protocol comprises a Transport Control Protocol/Internet Protocol (TCP/IP), and the second transport protocol comprises a User Datagram Protocol (UDP).
• TCP/IP Transport Control Protocol/Internet Protocol
• UDP User Datagram Protocol
• 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
• 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).
• TCP/IP Transport Control Protocol/Internet Protocol
• UDP User Datagram Protocol
• 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.
• 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.
• 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.
• 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 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
• 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.
• 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.
• the participant computer terminals and also the communication network may be adapted for transmission of real time information from the auctioneer computer.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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
• 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.
• a method for an auction based upon submittal of stake-supported bids from auction participants within pre- established time limits 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.
• 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.
• 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.
• 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
• fig. 12 shows an example of a bid board display for an auction participant in a sealed bid type auction.
• 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:
• 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.
• 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.
• 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.
• 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.
• 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).
• 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.
• the auction protocols are divided into an auction administration protocol and a bidding protocol that are handled separately.
• one aspect is the avoidance of data conversions, and another aspect is reduction of message traffic.
• 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.
• the auction organizer takes a cut (e.g. 20%) of the total income, the rest (the pot) is paid back to the participants (winners)
• 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.
• the participant At the start of the auction the participant must log on to the server with a Login mesage.
• the server auctioneer
• the server will reply with an Accept message or an Error message.
• 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):
• the auctioneer 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.
• 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.
• 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.
• Each participating bidder should get a notification of new bids "immediately" when a new bid is accepted from a legitimate bidder.
• Such notifications 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
• 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.
• a real auction should be handled using (at least) two web servers, see figs. 1 , 2 and 7.
• fig. 7 is shown an example of connections between the closest central
• 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
• 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):
• the auctioneer is preferably a normal Unix program, and can be started from the command line:
• 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.
• 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.
• 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 are printed whenever a new status message is broadcast.
• Bid time-stamp B bid id serial time disp
• 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.
• 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
• 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
• 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.
• 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.
• 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 must provide signed (or possibly encrypted) messages.
• 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).
• 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.
• 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.
• 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.
• a safety precaution for the auction 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.
• 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.
• Strategy game log - analysis of individual strategy compared to other participants/winner after auction end - or alternatively during auction
• the auction has full "real-time” interaction as one sees all actions of other participants, and your own actions are re-action to this.
• 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.
• 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:
• 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.
• the auction log may be used to define:
• 2 nd tier 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)
• 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.
• 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.
• the auction machine 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.
• 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.
• the actual simulation is instant. However, a participant will use the time it takes to bid. Total individuality of when done.
• This auction may be played at any time, but may have a delay in selection of winner.
• 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).
• 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).
• 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.
• 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.
• 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).
• 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.
• the auction machine 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 length of the auction is independent of the number of participants/bids.
• 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
• Jamming/unauthorized acccess - protection Such protection may be an issue if a participant can manipulate the auction machine before auction starts.
• 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.
• 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.
• 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.
• 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 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:
• 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.
• 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.
• 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.)
• 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.
• normal TV, text TV or radio channels public or closed-circuit
• a telephone network cellular or public switched network
• 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.
• 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.
• 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.
• 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.

Landscapes

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

Applications Claiming Priority (3)

Publications (1)

Family

ID=22070713

Family Applications (1)

Country Status (13)

Families Citing this family (41)

Family Cites Families (2)

• 1998
  • 1998-11-25 DE DE1032902T patent/DE1032902T1/de active Pending
  • 1998-11-25 WO PCT/NO1998/000348 patent/WO1999027476A2/en not_active Application Discontinuation
  • 1998-11-25 ID IDW20001247A patent/ID28134A/id unknown
  • 1998-11-25 CN CN98811540A patent/CN1279795A/zh active Pending
  • 1998-11-25 AU AU16956/99A patent/AU1695699A/en not_active Abandoned
  • 1998-11-25 EP EP98961693A patent/EP1032902A2/en not_active Withdrawn
  • 1998-11-25 EA EA200000577A patent/EA002514B1/ru not_active IP Right Cessation
  • 1998-11-25 CA CA002311353A patent/CA2311353A1/en not_active Abandoned
  • 1998-11-25 JP JP2000522544A patent/JP2001524719A/ja active Pending
  • 1998-11-25 KR KR1020007005791A patent/KR20010032547A/ko not_active Application Discontinuation
  • 1998-11-25 ES ES98961693T patent/ES2177484T1/es active Pending
  • 1998-11-25 BR BR9815030-8A patent/BR9815030A/pt not_active IP Right Cessation
  • 1998-11-26 AR ARP980106002A patent/AR018522A1/es not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events