US008266000B1
`
`(12) Ulllted States Patent
`Harris
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 8,266,000 B1
`Sep. 11, 2012
`
`(54) REAL TIME AUCTION WITH END GAME
`
`.
`_
`(75) Inventor. Scott C. Harris, Rancho Santa Fe, CA
`(US)
`
`(73) Assignee: Harris Technology, Inc., Rancho Santa
`Fe CA (Us)
`’
`.
`.
`.
`.
`Subject‘ to any d1scla1mer, the term of this
`patent 1s extended or adJusted under 35
`U.S.C. 154(b) by 0 days.
`
`.
`( * ) Not1ce:
`
`(21) App1_ No; 12/880,110
`
`.
`(22) Flled:
`
`seP- 12’ 2010
`
`5,847,971 A 12/1998 Ladner 6t a1~
`5,890,138 A
`3/1999 Godin et a1.
`5,905,975 A
`5/1999 Ausubel
`5,924,083 A
`7/1999 Silverman et al‘
`5,960,411 A
`9/1999 Hartman et a1.
`5,978,842 A 11/1999 Noble et a1.
`6,012,045 A
`1/2000 Barzilai et a1.
`6,021,398 A
`2/2000 Ausubel
`6,023,686 A
`2/2000 Brown
`6,026,383 A
`2/2000 A b l
`6,044,363 A
`30000
`6? a1‘
`6,058,379 A
`5/2000 Odom et a1‘
`6,101,498 A
`8/2000 Scaer et a1.
`6,113,504 A
`9/2000 Kuesters
`6,161,099 A 12/2000 Harrington et a1.
`6,199,050 B1
`3/2001 Alaia et a1.
`6,202,051 B1
`3/2001 Woolston
`6,216,114 B1 *
`4/2001 Alaia et a1. .................... .. 705/37
`
`Related US. Application Data
`
`(Commued)
`
`(60) Division of application No. 12/464,706, ?led on May
`12, 2009, Which is a continuation of application No.
`09/780,248, ?led on Feb. 9, 2001, noW abandoned,
`Which is a continuation-in-part of application No.
`09/669,805, ?led on SeP- 26, 2000
`(60) Provisional application No. 60/169,728, ?led on Dec.
`8’ 1999'
`
`(51) Int‘ Cl‘
`(201201)
`G06Q 40/00
`(52) US. Cl. ....................................................... .. 705/26
`(58) Field of Classi?cation Search ............. .. 705/35i45
`See application ?le for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`4,789,928 A 12/1988 Fujisaki
`5,700,204 A 12/1997 Teder
`5,794,219 A
`8/1998 Brown
`5,835,896 A 11/1998 Fisher et a1.
`5,845,265 A 12/1998 Woolston
`
`CA
`
`FOREIGN PATENT DOCUMENTS
`2305834
`10/2001
`
`OTHER PUBLICATIONS
`Prince D.,Aucti0n ThislYour Complete Guide to theWorld of Online
`Aucnons’ Pnma Tech’ pp‘ 136437’ 1999'
`(Continued)
`
`Primary Examiner * Thomas M Hammond, 111
`(74) Attorney, Agent, or FirmiLaw Ol?ce of Scott C.
`Harris’ hm
`
`(57)
`
`ABSTRACT
`
`A real time auction system operates in a non real time mode,
`and an end game mode in Which the users are placed in a
`forum. In both modes the users are capable of placing bids
`along With times When those bids should be executed. An
`agent treats the bids as secret until the time, and then at the
`time executes those bids.
`
`26 Claims, 9 Drawing Sheets
`
`200\
`DJSPLAY i TEA/2’
`
`205 \
`
`DETECT 11X
`EEFORE C1055
`
`270
`
`CALL END GAME
`
`220\
`SEND MESSAGE
`TO ALL REGJSTREES
`
`eBay Ex. 1001, Page 1 of 18
`
`

`

`US 8,266,000 B1
`Page 2
`
`US. PATENT DOCUMENTS
`6/2001
`6,243,691
`Fisher et al.
`Shoham
`9/2001
`6,285,989
`Dinwoodie
`7/2002
`6,415,269
`9/2002
`6,456,232
`Milnes et al.
`12/2002
`6,499,018
`Alaia et al.
`Gobush
`6,533,674
`3/2003
`Ewing et a1.
`6,774,932
`8/2004
`6,847,939
`Shemesh
`1/2005
`Seymour et al.
`6,871,190
`3/2005
`7,220,187
`5/2007
`Schmidt et a1.
`7,255,649
`McConnell
`8/2007
`
`2001/0032175 A1
`2002/0013763 A1
`2002/0188545 A1
`2003/0158804 A1
`
`10/2001 Holden et a1.
`1/2002 Harris
`12/2002 Wiesehuegel et a1.
`8/2003 Francis et a1.
`
`OTHER PUBLICATIONS
`
`eBay “Frequently Asked Question about Auction Types,” Nov. 22,
`1999 archived at wwwwaybackmachineorg.
`http://pages.ebay.com/aW/proXy-bidding.html, Feb. 1999.
`
`* cited by examiner
`
`eBay Ex. 1001, Page 2 of 18
`
`

`

`US. Patent
`
`Sep. 11,2012
`
`Sheet 1 of9
`
`US 8,266,000 B1
`
`REMGTE
`
`REMQTE
`
`REMQTE
`
`INTERNET
`
`gggygg
`
`2?(}\
`QiSFLAY ITEM
`
`EEYECT EX
`BEEQRE CLGSE
`
`200
`
`0011 EM; GAME
`
`SEND MESSAGE
`T6 ALL REGiSTREES
`
`eBay Ex. 1001, Page 3 of 18
`
`

`

`US. Patent
`
`Sep. 11, 2012
`
`Sheet 2 0f 9
`
`US 8,266,000 B1
`
`AGENT‘IMG
`
`35?
`
`
`
`
`
`5mm MAXiMU?/f BID (MAX-5w)
`
`QiSPLAY MAX-:BiQ/TZME
`
`CHANGE PRGFZLE
`BY Giff,
`
`m? ENTRY
`M145“, MAX 5529M
`
`HQ 3
`
`34?\
`
`SQMETIMES/BIQS
`AS RULES
`
`35Q\
`
`QPIiQNs
`
`35@\ AS SPEQHED W5,
`RELEASE EA CH m5
`
`eBay Ex. 1001, Page 4 of 18
`
`

`

`US. Patent
`
`Sep. 11,2012
`
`Sheet 3 of9
`
`US 8,266,000 B1
`
`5 50m GAME
`
`1
`
`42f}
`
`’
`
`422
`\
`GETAMQUNT
`
`41%
`
`‘f
`
`
`
`MQRE BIQQER m “0003501? 5:05 " AREA
`
`v
`426 \
`@Aii AGENT W00
`
`405
`
`CHECK i3
`
`0
`404\
`A00 m PARTMPANIFS
`us?"
`
`455\
`
`V
`ASSiGAi AN
`AGENT/AGENT#
`
`"
`ISPLAY W/ iCGN
`
`40
`
`'q;
`minim/m! “NEW
`S10E53” AREA
`(upmrm @0050 00m
`
`v
`4Q5\
`0500530 NEW
`
`eBay Ex. 1001, Page 5 of 18
`
`

`

`US. Patent
`
`Sep. 11,2012
`
`Sheet 4 of9
`
`US 8,266,000 B1
`
`EXPIRED
`
`DiSPL/QY GGING
`
`i?/FMUTE HAT?
`
`UPQATE ALL
`WAiT 2@ SEC
`
`445
`
`V
`GOING...
`
`V
`QISPLAY <QUiCK BIB >
`:‘CQN
`
`4'5?\
`
`V
`UPKJATE ALL
`
`0,
`455
`WAIT 26 S56’)
`
`eBay Ex. 1001, Page 6 of 18
`
`

`

`US. Patent
`
`Sep. 11,2012
`
`Sheet 5 of9
`
`US 8,266,000 B1
`
`CURHENT
`WINNER
`
`GREEN
`FLASHING
`
`J95 514W
`
`STREAMING
`ViQEQ 05050?
`
`10%
`
`NEW
`
`00/0050‘?
`
`@QMPL’TER
`
`/
`STAHSHCS
`40 PEQPLE
`
`M /
`50
`
`SUCK
`
`HGW MUCH
`mum ‘my
`LIKE T0 0:0
`
`5 i Q \
`
`NEW
`5500510
`
`ME
`
`53%
`
`QUICK
`15
`53%
`
`@565’
`WW Big
`
`00%
`AMGUNT
`
`5.
`
`QURRJM 05mm
`Eli/WW5!
`MIN i5
`US$10 NAME-AGENHé
`
`eBay Ex. 1001, Page 7 of 18
`
`

`

`US. Patent
`
`Sep. 11,2012
`
`Sheet 6 0f9
`
`US 8,266,000 B1
`
`:j ' AQEN?‘ WW
`
`
`
`42G
`GET NEW
`
`NEW M3 MW Big WW BID CU}??? BIB
`
`Bi}?
`-
`SEN!) TO
`ALL PARTICIPANTS
`
`,
`
`MQDERATGRS
`
`
`
`DiSPLAY NEW BED
`FLASH 513053 AT
`TOP 8F SCREEN
`
`3
`
`3
`
`
`
`is
`0151/1!mb
`
`.,:;;::.:.:..
`”
`
`MA’N 31
`33:53-33:3-
`'
`«:;;.;.;.;.._
`
`““““““'“““““
`
`
`
`smmmflgmm Wifiifiifl 1 we
`
`525
`
`CUHRB‘B
`
`NEWfiifi-
`
`eBay Ex. 1001, Page 8 of 18
`
`eBay Ex. 1001, Page 8 of 18
`
`

`

`US. Patent
`
`Sep. 11,2012
`
`Sheet 7 of9
`
`US 8,266,000 B1
`
`mm?
`QE
`
`@m Ea @még
`
`WE qmég “mm agémw q
`
`A
`
`gm 2% M mmwu
`
`gm {3%
`
`émbmm
`
`Kg
`
`my
`
`
`
`w ,. 50%
`
`A
`
`% Emmmg
`
`my
`
`eBay Ex. 1001, Page 9 of 18
`
`

`

`US. Patent
`
`Sep. 11,2012
`
`Sheet 8 of9
`
`US 8,266,000 B1
`
`$27
`
`QUiCK 3w
`
`{CLICK
`
`QUiCK 315
`> AMQUNT A?
`$3; UK?
`
`y
`m
`
`QUIQK WW i0
`
`wax
`
`QUiCK WIN
`p AMQUNT i$
`031; GA’?
`
`Y
`‘Y,
`
`eBay Ex. 1001, Page 10 of 18
`
`

`

`US. Patent
`
`Sep. 11,2012
`
`Sheet 9 019
`
`US 8,266,000 B1
`
`ANT! 5515505 555555
`
`5155
`
`799
`
`8&9
`
`391
`
`
`
`,
`
`"
`
`
`
`555555
`55555155
`I?
`
`"a
`
`‘5‘“52:95
`
`
`fi§ES
`
`
`555
`875
`...........................................
`NEngQ ‘ NOTGN.............. W..............
`55555550” 5:57 SSW/5F??? 7'5 MST
`,
`5
`5515155
`% QBFfiEWQUSEE”
`ACHGN i
`
`
`F%§.§
`
`eBay Ex. 1001, Page 11 of 18
`
`eBay Ex. 1001, Page 11 of 18
`
`

`

`US 8,266,000 B1
`
`1
`REAL TIME AUCTION WITH END GAME
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`This application claims the bene?t of the US. Provisional
`Application No. 60/169,728 ?led on Dec. 8, 1999 and US.
`application Ser. No. 09/669,805, ?led Sep. 26, 2000.
`
`BACKGROUND
`
`The present invention describes a new paradigm for con
`ducting an auction on a remote information server such as the
`Internet.
`The Internet is an extremely powerful tool for conducting
`auctions. Literally millions of users can simultaneously take
`part in a single auction. Auction sites such as E-bay have
`popularized the Internet auctions. Each of these auctions
`allows bidding between virtually every person who has
`access to the Internet.
`The auctions often last over an extended period of time, e. g.
`over one week. Many of these auctions use agents which
`automatically handle the bidding. The bidder instructs the
`agent with information about the bidder’s maximum desired
`bid. The agent will bid only up to that amount. Moreover, the
`agent does not immediately bid its maximum amount; it only
`bids an amount when the price of the item rises to a level that
`forces the agent to bid in order to keep the high bid.
`It has been found that the most serious and competitive
`bidding can occur at the end of the auction. Conversely,
`bidding early in the auction tends to cause the product to sell
`for more money than it would have sold for otherwise. There
`fore, people often wait until the last instant, eg the last
`minutes or seconds of the auction, before bidding.
`Auction sites such as E-bay often have ?xed times for the
`auction ending. The auction ends at that moment, even if
`bidding may be most intense at that moment. If a bid is placed,
`but not received before the instant of the auction end, the item
`will sell. Therefore, Internet delays can cause a product to sell
`for less money than it otherwise would have sold for.
`
`SUMMARY
`
`The present invention recogniZes that the standard model
`of Internet auctions is actually ?awed. Auctions should be
`carried out more like a real live auction. While live auctions
`are known in the Internet art, a different kind of live auction is
`described herein. This live auction includes certain re?ne
`ments which improve it for use on the Internet.
`This includes an identi?cation system with each of a plu
`rality of bidders being identi?able.
`Another aspect includes a combination of an on-line auc
`tion and off-line auction, with the off-line auction forming
`effectively a display period for the merchandise during which
`the users can place bids, and the on-line auction forming a
`?nal bidding period for the goods during which the goods are
`actually sold.
`Another aspect is an agent for use in an online auction, in
`which not only the amounts of the bids, but also the time when
`those amounts are release, are speci?ed.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`These and other aspects will now be described in detail
`with respect to the accompanying drawings, wherein:
`FIG. 1 shows a block diagram of the hardware used by the
`bidding system of the ?rst embodiment;
`
`65
`
`2
`FIG. 2 shows a ?owchart of operation according to a ?rst
`mode;
`FIG. 3 shows a ?owchart of the special “agent” used in this
`auction system;
`FIG. 4 shows a ?owchart of operation of an end game;
`FIG. 5 shows a diagram of the forum showing the multiple
`users
`FIGS. 6A and 6B shows ?owcharts of bidding;
`FIGS. 7A and 7B show a quick bid embodiment; and
`FIG. 8 shows an embodiment that may prevent last minute
`bidding.
`
`DETAILED DESCRIPTION
`
`FIG. 1 shows a basic structure of a ?rst embodiment of the
`bidding system. The bidding is actually carried out within a
`virtual environment created by the central “server” computer
`100. The server may be more than one computer, which
`operate to execute a program as described herein.
`Server 100 keeps track of all the bids, and produces the
`graphical environment that is displayed on each of the remote
`terminals, where only three remote terminals: 110, 120 and
`130; are shown. Literally every computer on the Internet
`could be included. Each of the remote terminals preferably
`obtains a view that is partly the same as the others, and partly
`different.
`Server 100 runs the ?owchart shown in FIG. 2. The main
`?owchart runs the beginning part of the auction as a conven
`tional Internet auction, shown generally as step 200. The item
`to be sold is displayed. It is listed in some kind of index, or
`under a category. This can be thought of as the advertising
`part. Using an analogy to a real auction, this is the portion of
`the auction where the items can be viewed.
`In a particularly preferred embodiment, the item is viewed
`in three dimensions. A picture of the item is shown. The
`picture of the item can be a two-dimensional picture or a
`three-dimensional picture. If a three-dimensional picture is
`used, the system ?rst displays a two-dimensional “splash” of
`the image while the system is loading the three-dimensional
`information. The three-dimensional information is then used
`to enable viewing the item three-dimensionally. This can be
`done using the techniques described in our application
`entitled “Touch and Feel on the Internet”; Ser. No. 09/505,
`646.
`In whatever form the item is displayed, this is the period
`during which the users can see and ?nd the items of interest.
`As conventional, this portion of the auction also accepts bids,
`eg via a bid agent. A special bid agent can be used as
`described herein.
`This bid form continues until some speci?ed time period
`(x) before auction close, eg one hour prior to auction closing.
`Step 205 shows detecting that predetermined time, shown as
`time T-X. The auction mode changes to a mode that indicates
`the higher energy and interest associated with this portion of
`the auction. Step 210 shows calling the “end game”, which is
`the routine that runs this higher energy portion of the auction.
`This changes the auction mode to a more interactive atmo
`sphere.
`At step 220, all of the people who have registered for the
`auction and indicated a desire to participate in the end game
`are sent a message. This message can be sent in a number of
`different ways. An e-mail can be sent to each person on the
`list. Pager numbers can also be contacted to leave an alpha
`numeric page indicating the URL of the auction site. These
`two techniques are especially advantageous when the email
`or page is sent to a cellular phone of a type that allows web
`
`eBay Ex. 1001, Page 12 of 18
`
`

`

`US 8,266,000 B1
`
`3
`browsing. The endgame can be carried out on the cellular
`phone, by clicking on the URL that is sent.
`An automated agent can leave an audio message (voice
`mail) on a person’s normal telephone, indicating that the end
`game has started.
`After an endgame has started, and while still in progress, a
`user can log into the auction site. The user enters their name
`and password, as conventional. Upon entering their name and
`password, the user receives an indication, eg via a pop up
`window with a prompt, that the end game for this auction is in
`progress. The pop up window can take them directly into the
`end game environment.
`The special agent program used herein takes into account
`the realities of such a system. Bidding too early in the process
`can increase the price for an item. Usually the prices in the
`early part of the auction are kept moderate. The bidding often
`does not reach levels approximating the actual value until
`later in the auction.
`The previously-used system automatically immediately
`made its bid based on current bid amount. If two people gave
`instructions to their systems, those two people would auto
`matically and immediately bid against each other, until one
`was outbid. Consequently, users often do not place their bids
`early, to avoid starting such a bidding war.
`The present application describes an agent which avoids
`this issue by using a time pro?le. The agent allows setting
`bids, including maximum bids, and also setting times at
`which those maximum bids will be provided.
`Another operation describes a graphical user interface sim
`plifying that operation.
`The ?owchart shown in FIG. 3 represents the agent man
`ager (AGENTiMG).
`The user is ?rst prompted for a maximum bid (MAXiBID) at
`step 301. That maximum bid indicates the maximum that the
`agent will be authoriZed to bid on the item. The agent will not
`bid any amount, however, until authorized to do so.
`At step 310, a graphical representation of times and the
`maximum bid is displayed. The graph can initially show any
`desired pro?le of bid vs. time; here it shows the agent being
`authoriZed to bid the MAXiBlD amount, immediately. This
`pro?le, however, can be changed. Step 320 shows one tech
`nique in which the graph is edited. The user may, for example,
`not allow any bids until the end game or allow a very moderate
`bid initially, and more bids in the end game. The pro?le as
`edited in step 320 shows no bids being authorized until a time
`y. That time y can be determined with precision by resting the
`cursor over a time, and waiting for a “screen tip” to be dis
`played. This graphical system can be easily edited on many
`different platforms, e.g., a cellular phone that allows web
`browsing.
`At any point, instead of using the graphical user interface,
`the user can select, e.g., right click, on a portion of the line,
`and use a text entry system. Step 330 shows a textual inter
`face. The user can enter information, e.g.,
`AT TlME tl ,
`ALLOW A MAXIMUM BlD or $x l, where the underlined informa
`tion is entered.
`However entered, the maximum bids and the times at
`which those maximum bids are allowed to be released, are
`stored at 340. This information is entered as a function of
`time, and hence can be stored as rules, for example. A rule
`might read:
`At time AUCTIONiEND40Z30 (30 minutes before auction
`end), bid up to $10.
`Option entry is carried out at step 350. Options can include:
`Overriding previous bids during the end game. This can be
`important with an agent. If the agent has been instructed to bid
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`up to $20, a later bid may actually bid against the agent’s
`previous bid, and force the agent up to its maximum. This
`system enables overriding previous bids placed with the
`agent, in order to allow placing a higher bid. In some
`instances, that overriding can be allowed, for example, only
`when a higher bid is desired.
`The ability to cancel a previously-entered rule.
`Contact information to contact (at step 220) during the end
`game, and/or a request to enter the end game.
`AuthoriZation to automatically raise the bid for a reserve
`auction.
`Other options are possible.
`Each of these options are preferably written as rules that
`drive the automated bidding program.
`These rules written by the agent are kept secret until the
`time they are executed. Each of the rules includes an execute
`time. For example, for the bid rules shown in step 330, each
`rule starts with at time t1, do x. The present application con
`templates placing multiple different bid/ time combinations in
`this way. For example, a ?rst one could allow bidding up to
`$xl at time t-l hour; and a larger bid of up to $x2 at time t-1/2
`hour.
`Prior to this time to execute, the main process running on
`the server computer cannot obtain the contents of the rule.
`Only the person who made the rule can read the rule.
`After the time t1, the agent will bid up to the maximum
`amount speci?ed, not placing any bid until the time speci?ed.
`However, since the time for the rule has passed, the server at
`that point knows certain information about the contents of the
`rule, and can use that information as described herein.
`Therefore, before the speci?ed times, the rules are abso
`lutely secret. No one except the bidder can ?nd these rules.
`After the time, the contents of the rules can be known to the
`server. The disclosure provided herein describes how these
`bids allow faster bid processing, e. g. bid rejection and the like.
`Step 360 shows the agent generally carrying out a time pro
`cessing routine. At the speci?ed time, each rule e.g. bid, is
`released.
`For rules such as reserve handling, the time of release is the
`auction end.
`As described above, at the speci?ed time, AUCTIONiENDiX,
`the end game routine is called, and the auction form changes.
`The end game is shown in FIG. 4. Step 400 detects a new
`bidder entering the end game. As described above, this can be
`done by the bidder signifying their intention to enter the end
`game, or can be an automatically-created pop up window
`when a previously-registered user logs in to the auction’s
`website. The ?owchart shows verifying the identity of the
`new bidder at step 402. Once the identity is veri?ed, e.g., by
`usemame and password, the user is added to the participants
`list for the end game at step 404.
`The endgame is carried out in a graphical forum. Each user
`is shown in the forum, along with other users. The forum 500
`is shown in FIG. 5. Once the new user has been added at step
`404, the user is displayed in the forum, with an icon indicating
`the user’s status. The status can include credit rating or other
`information. The user is initially displayed in the new bidder
`area 510. Step 406 illustrates displaying the new user in the
`new bidder area.
`In this embodiment, the user signs in, and thereafter can
`place bids without entering their name/password. This is dif
`ferent from other online auction paradigms, in which each bid
`requires the user’s name/password. This is more dif?cult for
`the user, and also slows down the operation. In this paradigm,
`a session key can be established after login, so that the com
`munication occurs over a secure channel.
`
`eBay Ex. 1001, Page 13 of 18
`
`

`

`US 8,266,000 B1
`
`20
`
`25
`
`30
`
`5
`The check ID step of step 402 can be user veri?cation by
`any means. One such veri?cation is speci?c to use With a
`Web-broWsing cellular telephone. The caller ID of the calling
`telephone can be established. This establishes the user’ s iden
`ti?cation automatically.
`One feature of this real time auction is that the bidders must
`receive information that is frequently updated. Typical Web
`broWsers, hoWever, do not automatically update the informa
`tion that they display. Accordingly, the present application
`uses automatic information update to provide up to date infor
`mation to the bidders.
`This automatic information update can be done in different
`Ways. One Way is to send an update command to the broWser
`at speci?ed intervals. This update command causes the
`broWser to request a refresh, thereby loading the neW and
`updated forum scene.
`In another aspect, certain parts of the image that is dis
`played by the Web broWser to represent the forum are de?ned
`as being streaming video. Streaming video is Well knoWn in
`the art, and displays a continuous stream of video to the user.
`A standard streaming video stream can be used.
`Another option de?nes a special object Within the Web
`broWser environment. This object is effectively stop motion
`video. At times the object can be changing. When unchanged,
`the object remains the same. When the object receives infor
`mation, it changes, Without a need to “refresh”.
`In any case, assuming that the standard Web broWser is
`used, a command is sent to the Web broWser at step 408,
`requesting at least the neW bidder’s Web broWser to refresh.
`The neW bidder sees himself added to the neW bidder section
`51 0. Others might not see this addition until some other action
`causes them to refresh. HoWever, a neW bidder being added is
`not necessarily important to all bidders.
`The add to participants list at step 404 includes assigning
`an agent to the participant at 405, if necessary. The participant
`may already have an agent assigned from previous participa
`tion in the auction during the display mode 200. If so, the user
`retains that agent. If not, a neW agent instance is de?ned, eg
`by auction number and agent number. The agent is assigned
`40
`one-to-one With the user so that the user has his oWn agent. As
`described above, that agent can keep secrets during the bid
`ding process, even though that agent may be running Within
`the same server that runs many of the other agents.
`Also, after the ID is veri?ed at 402, the user name is
`displayed along With the results of the id check. For example,
`the system may operate a rating system for users. This rating
`system may include a credit rating of the user, for instance a
`maximum bid that the user is authorized to make.
`Another rating is based on the user having entered a guar
`antee of bid. For example, the user may use a credit card as
`part of the bid/bid pro?le process. When the bid is accepted
`and the auction is ended, that credit card is automatically
`charged for the bid amount.
`Another option forces the user to post a bond, and can
`charge the auction against that bond in case the bid is not
`satis?ed.
`Yet anotherpossibility is that other participants rate the one
`participant, and provide a rating scheme that depends on the
`number positive and negative comments. This is similar to the
`rating scheme used by E-bayTM. According to all of these
`systems, the user’ s name as displayed at step 406 may include
`an indication of the users rating.
`Therefore, the user may be displayed as:
`JOE BLOW;
`RATING A;
`BOND POsTED
`
`50
`
`6
`until the amount of the bid reaches the amount of the posted
`bond. After the bid exceeds the posted bond, the display can
`say:
`JOE BLOW;
`RATING A;
`BOND AMOUNT ExcEEDED
`If a credit card is used, the display can say
`CREDIT CARD ON FILE.
`Another option displays information about the user in color
`based on the rating. A green rating means that the user has a
`good credit rating. A blue rating means a guaranteed bid. A
`red rating may mean that the credit line is exceeded.
`At step 420, a neW bid is detected. Step 422 obtains the
`amount of the neW bid. At step 424, the bidder Who placed the
`bid is moved to the “current bids” area 520. TheAGENT WIN
`routine (described herein With reference to FIGS. 6A and 6B)
`is called at step 426. The current bid amount is fed to this
`routine to determine if the current bid is a Winner, and to take
`action based thereon.
`The agent Win routine can be done in one of tWo different
`Ways shoWn in FIGS. 6A and 6B. These depend on the Way
`that the system handles bids.
`A number of variables are de?ned associated With the
`bidding process.
`NEWiBID is the amount of a neWly-placed bid.
`MINiBID is the minimum amount that needs to be bid to
`place a bid. This value is related to the current bid (OURRiBID),
`and the bidding increment (BIDiINC).
`WINiBID is the amount that is necessary to Win the current
`auction (until outbid). This value may or may not be knoWn to
`the local agent.
`The local agent is partially resident on the client computer,
`e.g., as an applet running on the client computer. This is done
`to alloW faster reaction to bids. Preferably at least a part of the
`agent, runs on the users terminal. This part of agent includes
`certain numbers Which facilitate accepting or rejecting bids.
`For example, the applet is continually updated With minimum
`bid amounts and, to the extent possible, With Winning bid
`amounts. During the end game, When the user places a bid, the
`agent is able to accept or reject the bid substantially immedi
`ately. Then the agent can send a speci?ed signal to the main
`frame computer that is actually moderating the bid. The
`speci?ed signal can include an indication that an acceptable
`bid is folloWing. This can substantially speed the process,
`since an indication of an acceptable bid can be quickly sent
`and received by the client computer.
`FIG. 6A is executed When the maximum among the
`released bids are knoWn to all agent applets. The neW bid is
`detected at step 420. All agents are continually updated With
`MINiBID, WINiBID, cuRRENTiBlD at step 610. At step 612, all
`the values are updated to all participants.
`At step 614, the current bid (OURRiBID) is compared With
`the value of the Winning bid (WINiBID). If the current bid is
`found to be less than the Winning bid at 614, a message is
`returned to the user placing the bid, indicating “outbid” at
`620. The current bid is also set to the value of neW bid at step
`625, thereby increasing the neW minimum bid (:CURRiBID+
`BlDiINc).
`These neW variables are sent to the mainframe, and at steps
`610/612 are sent to all agents. All agents therefore store the
`values from Which it can be immediately ascertained Whether
`a locally-placed bid Will Win or not.
`If the neW bid is greater than the Winning bid at step 614,
`then the neW bid becomes a Winning bid at step 630. The
`current bid is set to the value of the Winning bid at step 630.
`Note that the current bid is not set to the neW bid, unless the
`neW bid?he Winning bid. Instead the agent manager is called
`
`35
`
`45
`
`55
`
`60
`
`65
`
`eBay Ex. 1001, Page 14 of 18
`
`

`

`US 8,266,000 B1
`
`7
`as described below. At step 635, the new amount is displayed,
`and the bidder is moved to the top of the screen showing the
`forum. The system also sends a global update, to update all
`users to indicate a new winning bid, and a new order of users.
`The previously-winning bid is placed to the current bidder’s
`area.
`If the new bid is greater than the winning bid at 640, the
`agent manager is called at 645 to de?ne the bids to be released
`as a function of time.
`FIG. 6B shows the alternative in which the winning bid
`variable is not known globally to all agents. In this case, a new
`bid at 420 causes a test to be made at step 650 to determine if
`the current bid is greater than the minimum bid. If so, the
`minimum bid is posted to the agent holding the winning bid
`(AGENTfWIN'BlD) at step 655. AGENTiWIN'BID determines, from
`its rules database, if it is authorized to place a bid that is high
`enough to win at the present time, at step 660. If so, then the
`current bid and minimum bid variables are appropriately
`increased at step 665, and a notice of outbid is returned at 670.
`If AGENTfWIN'BlD is not authoriZed to bid high enough, then the
`current bid variable is set to the new value at step 675, and the
`process returns an indication that the current bidder is now the
`winner. All variables are updated and sent to the mainframe
`for sending to all agents. The new bidder’s agent also
`becomes the new AGENTiWIN'BID at 680. An update is posted
`globally at 685.
`The difference between the two routines is the amount of
`information held locally. In the FIG. 6A routine, all agents
`have information allowing them to determine locally whether
`any bid will win. The do not necessarily display it, but they
`store the information. They can accept or reject a bid locally.
`In the FIG. 6B routine, the agents keep the bids secret. A
`bid can be posted to the agent holding the bids to determine if
`there is a winning bid. However, this takes longer to effect.
`In both routines, the information is not available at all
`before the scheduled release time.
`Returning to FIG. 4, step 430 illustrates that the time for
`auction is about to expire. This may happen, for example, at
`the time of auction expiration or 2-10 minutes before. The
`?rst thing that happens at step 432 is the global display of the
`word “going .
`.
`. ”. This is like a real auction, where the
`auctioneer warns the audience with this key word. In this
`embodiment, the word may be displayed in a balloon coming
`from the auctioneer’ s or agent’s mouth, as shown in the forum
`ofFIG. 5.Anupdate is sent at 434, so that all users will see this
`message. Alternatively, a new streaming video object is
`de?ned coming from the auctioneer’s mouth so that the users
`see the “going” symbol. At this point, time is of the essence.
`Another paradigm becomes possibleithe quick bid para
`digm.
`The quickbid is shown in FIGS. 7A and 7B.Again there are
`two modes for the quick bid. In one mode, the agent knows all
`values. In this case, the agent can enable not only posting a
`quick bid, but also posting a quick winning bid. The agent in
`FIG. 5 shows the options for bidding when they are available.
`For instance, the quick bid 530 may be displayed as shown in
`FIG. 5, along with the quick winning bid 535. Passing the
`cursor over either value displays a “screen tip” that allows the
`user to view what the quick bid or quick winning bid amount
`will be. Since these values are known to the agent, they are
`stored in the local browser, and can be displayed quickly. The
`quick win bid may be displayed or not displayed, depending
`on rules, options and circumstances of the auction. In one
`mode of operation, users are provided with an incentive to
`share the winning bid with others. For instance, users may get
`a discount or other incentive to allow the quick bid to be
`
`50
`
`55
`
`60
`
`65
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`8
`known. Even if the quick bid quick win is known, it may only
`be allowed during the going, going, gone, during which time
`emotions become higher.
`The quick winning bid is also shown in FIG. 7B. In either
`case, when the user clicks on the amount, they receive an
`instantaneous indication of the amount they have bid and a
`con?rmation. By clicking yes, the bid is instantly posted,
`hence stopping the going, going, gone process for at least one
`minute as illustrated in step 440. After no further bids have
`been received, the moderator once again enunciates the going
`(step 432), beginning the end of the process. This can enable
`the quick bids as described above.
`In a normal auction, enunciating the ?rst word “going”
`would be quickly followed by another going. However, in this
`auction, the system must allow time for users to get their bids
`in over the Internet. Hence, preferably at least thirty to sixty
`seconds elapse prior to the second going at 445. After each
`instance of going, a global update is sent at 450 or the going
`going gone is displayed in streaming video. After additional
`time has elapsed at step 452, without addi