(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2002/0049664 A1
`(43) Pub. Date: Apr. 25, 2002
`
`Hofl'man et al.
`
`US 20020049664A1
`
`(54) MULTIPLE, CONCURRENT DYNAMIC
`AUCTION EMULATION FOR NETWORKED
`ENVIRONMENTS
`
`(76)
`
`Inventors: Kenneth E. Holfman, Bellevue, WA
`(US); David M. Vice, Seattle, WA (US)
`
`Correspondence Address:
`Stephen M. Evans
`Graybeal Jackson Haley LLP
`Suite 350
`155-108th Avenue NE
`
`Bellevue, WA 98004-5901 (US)
`
`(21)
`
`Appl. No.:
`
`09/898,899
`
`(22)
`
`Filed:
`
`Jul. 2, 2001
`
`Related US. Application Data
`
`application No.
`(63) Non-provisional of provisional
`60/215,346, filed on Jun. 30, 2000. Non-provisional
`of provisional application No. 60/215,350, filed on
`Jun. 30, 2000. Non-provisional of provisional appli-
`cation No. 60/215,349, filed on Jun. 30, 2000. Non-
`provisional of provisional application No. 60/215,
`347,
`filed on Jun. 30, 2000. Non-provisional of
`provisional application No. 60/215,348, filed on Jun.
`30, 2000.
`
`Publication Classification
`
`(51)
`
`Int. C1.7 ..................................................... G06F 17/60
`
`(52) us. Cl.
`
`................................................................ 705/37
`
`(57)
`
`ABSTRACT
`
`The invention concerns systems and methods for imple-
`menting systems that permit multiple, concurrent real time
`live or dynamic auction emulations in a networked environ-
`ment. The systems include an auction database manager
`(ADM) component operatively linked to a rules based
`auctioneer (RBA) component and auction user interface
`manager (UIM) component. The ADM component manages
`data relevant to the auction environment such as bid param-
`eters, lot data parameters, and user preference parameters;
`auction history data such as bid history data; and completed
`auction archive data. The RBA component manages the
`interactive nature of the live auction emulations by defining
`the parameters for data presentation to bidders, and causing
`the same to be delivered to relevant bidders via the UIM
`
`component. It also handles basic input and output calls to
`and from the ADM component. The UIM component trans-
`forms the RBA component output to specific display and
`communications protocols for devices possessed or acces-
`sible by the bidders based upon data acquired from each
`participating bidder. Input from active bidders is trans-
`formed by the UIM component and delivered to the RBA
`component for processing. These components, when inte-
`grated into a networked environment, permit multiple, con-
`current, real
`time auctions that emulate real world live
`auctions wherein the price for an auction lot is determined
`not by an expiration of time but by a final highest bid.
`Methods are disclosed for carrying out the operations of the
`described components, as well as converting conventional
`static online auctions into dynamic auctions.
`
`Real-time Auction Database
`
`Manager
`
`
`
`Oveale Realauma
`Aucllon Dabsbase
`
`‘
`
`
`
`
`Process and sum
`
`Auction am Dam (mm
`Real-lime
`REA
`
`Auumn
`Dalalzzsa
`
`
`
`Wamm and uracaas
`
`
`MN
`
`ew REA to Stan
`ms Aucnun Pmbess
`and supp‘y me Stan
`Data
`
`
`Stored Aucnon
`Stan Data
`
`RAE
`
`Process Flow
`—+
`Data Flow
`”3*
`
`
`
`Wamm Stanlng Data
`from RBA
`
`. Data Requests lrom
`REA
`
`
`‘ f
`Has REA 52m and
`
`End at Amen
`Mes 5399
`
`
`
` P2:kaga Auclvon
`Daubau for Newsm...)
`Database
`
`
`
`Comwaxed
`Audion Arcmve
`Dalsbzse
`
`001
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`001
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 1 0f 6
`
`US 2002/0049664 A1
`
`Real—time Auction Data Flow
`
`Client/ User Software
`
`
`
`Formatted
`Descriptlons
`
`Formatted
`RBA Messages
`
`Text and Usage Formatted
`Data
`Bids
`
`
`
`
`Auction Data
`RBA Messages Text and Usage
`Bids
`
`RBA
`
`Auction
`
`User Data
`
`Bids
`
`I
`I
`I
`'
`I
`I
`I
`I
`I
`I
`I
`
`Il
`
`I
`I
`I
`'
`:
`l
`1
`l
`I
`.
`
`——-m——_—_u—————_—un——_—l
`
`002
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`002
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 2 0f 6
`
`US 2002/0049664 A1
`
`Real-time Auction Database
`
`Manager
`
`Stored Auction :
`Start Data
`
`
`
`
`"2.3,?
`
`
`
`7 U
`
`‘7
`
`Create Real-time
`
`Auction Database
`
`
`
`
`Notify REA [0 Start
`the Audit)“ Process
`
`and supply the Starl
`Data
`
`
`
`
`Wan fDI Starilng Data
`from RBA
`
`
`
`
`
`Process and Store
`
`Auction Bid Daia from
`Real-Time
`REA
`Auction
`Database
`
`
`
`
` .-
`Wait for and process
`
`. Data Requests from
`RBA
`
`Has RBA sent and
`
`End of Auctlon
`
`Message
`
`
`
`
`
`
`
`
`RAB
`
`Process Fiow
`__‘>
`
`Data Flow
`W
`
`Package AUCIIOn
`Database for Archive ,
`Database
`
`FIG. 2
`
`Completed
`Aucnon Archive
`
`Database
`
`003
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`003
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 3 0f 6
`
`US 2002/0049664 A1
`
`Rules-based Auction
`
`User Interface Manager (UIM)
`
`Sytem User Profile
`dalabse
`
`§
`
`Setup Processe s for
`Ulmanagmenl
`Supply Auction
`System Wilh entry
`paints lor all support
`Ul types
`
`
`Ul capabllltres
`Table"
`
`
`
`Wait for Bids , New
`users. or Ul updates ‘1
`
`
`
`REA Start Data
`
`§
`
`
`Auction
`
`system
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`f"
`Create New
`
`
`Start custom Ul
`
`5 user on syste
`Gel Ulparameters
`
`entryin Ul
`
`With Custom UI
`Store Ul pomter in
`for Userfrom
`
`
`
`
`
`capabilities
`available
`Ul cap table
`Profile
`
`table
`
`
`
`
`‘ re there user
`
`
`ready t 0 enter
`Send supported
`auction
`
`
`
`layout data to
`More users
`dispatcher
`
`waiting to enter
`
`N0
`
`
`
`RBA updates to
`
`
`data Video .texl,
`
`A re there Ul
`Use Ul capablmes
`DlSpalCh Ul updates
`
`audio ,
`UPdaies
`tableluformal
`Io
`ll
`I
`331
`s
`
`
`
`updateforeach user I a appica eu ers
`xy bids from RAB
`
`
`
`Is there a bid
`
`wanng
`
`
`Message
`
`Dispatcher
`
`
`Formal new High Bid
`info for each UI and
`
`
`
`dispalch
`
`
`as Auction
`
`Ended
`
`"‘ Reno same Ul Cap
`Table
`
`
`Create Final Auction
`
`data including
`Formal for each UI
`
`
`Winning EMS)
`using Ul Cap Table
`and link to exil
`
`
`Auction
`
`
`Process Flow
`——>
`Data Flow
`
`Yes
`
`Send Bid to RAB
`
`
`
`
`
`M
`
`FIG. 3
`
`004
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`004
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 4 of 6
`
`US 2002/0049664 A1
`
`
`System
`
`
`
`
`Auction
`
`
`SellerAuctlon Request
`Creates
`Created
`
`
`request
`
`Seller's Responses
`form
`
`
`
`Auctlon Lot
`
`
`Descnptlon
`Stored for Revrew
`
`
`
`Request Revrewed
`
`
`(May be automated or
`
`revuewed by operator
`
`
`
`(1)
`
`
`Was Lot Accepted
`for Auction?
`
`
`
`Yes
`
`No
`
`Does Lot meet
`
`Crrtena for Auction
`
`
`
`Converswn?
`
`
`No
`
`Yes
`
`Does Auctlon Lot meet
`Dnd Seller request or
`
`
`authorize Auction
`specral cntena for Operator
`
`
`
`Conversron'?
`0 Request a Conversron"
`
`
`No
`
`‘z
`
`Operator Contacts Seller
`
`to request Auctlon
`Conversran (e—marl)
`
`:Lot Database Descrlpllon
`
`Seller Agrees2
`created wrlh Auction
`
`
`Conversron Enabled
`
`No
`
`
`
`Conversron Data Decrsron pomt 5 may default to yes
`
`Auction Lot Data w1th
`
`by havmg the operator reserve the
`right to create converatble auctions
`as part of usage aggreement
`
`Decrslon pomM
`m ay default to "no "
`The operator may
`choose notto ever
`request converston
`
`Lot Database Descrrptlon
`created wrthout
`Conversron Enabled
`
`Auction Lot Data
`wnhout Conversron
`
`Into
`
`DeClSIon pornts 1,2.
`or 3 may default to
`"yes" by policy or be
`a discrete part of
`the revrew and
`Auction Lot creation
`process r
`
`Proces
`Flow
`
`D ata
`MFlow
`
`FIG. 4
`
`005
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`005
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 5 0f 6
`
`US 2002/0049664 A1
`
`
`
`
`
`Auction Bld Histnry
`Auctiun Conversian timer
`
`
`
`(Rules Based)
`
`standard Static
`Are Cntena fur
`
`Auction
`Internet Style
`
`Auction Conversion
`
`
`Satisfied?
`
`
`
`Auction Lot Database
`Description
`
`Auction Explres
`winning Bidder and
`
`Create List of Bidders
`with Contact Info
`
`Auctlan Bid
`
`History
`
`
`List of Potential
`
`V
`I
`Bidders genarated by
`
`liller for duplicates or
`operator
`lntegrnte ell hats and
`
`
`List of potential
`bidders from 3rd
`parties (inwte s)
`Scrsen users and
`
`provide Contact
`information
`
`invalid entries
`
`
`
`..
`
`
`Final list
`
`Stored user pmiiies
`
`Flow
`Process
`
`Data%Flow
`
`
`
`Ounce Control
`at Auction h as
`been handed all
`to the Live
`Auction II must
`expire there
`Thls process
`never happans
`in the static
`Auction Model
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`The Criteria may be as slmple as
`10 minutes before scheduled
`expiration They may include
`more detailed ruloa based an
`number at bidders, recent
`activity, and value of the item
`
`Live Auciion receives
`location of “'5 copy of
`
`Auction Data and returns it's
`location to conversion
`process
`
`
`
`
`Newly created
`Activate Autuin atad
`
`Automated
`Auction and wait for it to
`le3 Auction
`return It's locatian
`
`(pointer, hypedink, ar
`
`ofher Incator)
`
`
`
`
`Messaging Dispatch
`System
`
`
`__§__
`LlVB Auctten takes
`Replace Bld controls In
`StalicAuclion With Link
`
`control of All Auction
`to Live Auction
`
`Date
`
`{open inwtarion)
`Lwe Auction
`
`Lecauun
`
`Auction Lul Data
`8. Auction Bid
`
`History
`
`
`Yes
`
`
`s bidder logged on
`(6 system?
`
`
`Message
`Farm at Message for
`
`Notily Hidden/la
`chosen massagin
`Local Message
`
`
`system
`
`
`
`
`Dispatch Irlvllatlon vla
`pmiened messaging
`
`
`system
`
`
`
`
`
`'
`
`lnslanl Messaglng
`
`No
`
`completed? Yes
`
`w art for noiiiicaliun iiem
`reaHime auciien or
`com plataian of the
`EUCKIO"
`
`Contact Stalic Auction
`system Remove Ullor
`entering Real-tun
`system Frovrde linal
`sales into to STaic
`System for publication
`
`
`
`
`
`
`
`other
`(Pager, Interactive TV.
`at: )
`~4———-————-———
`
`
`Finish Data and Storage
`Clean up
`
`
`Conversion I: cumin-mi
`
`
`FIG. 5
`
`006
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`006
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 6 0f 6
`
`US 2002/0049664 A1
`
`Sales peuern Cntena
`Sales and Inventory
`lrwsntory Ilem
`watcher
`Records
`
`
`Descrrpuen
`
`
`
`(Alsa m ey dynlmcelly set
`start price for Auction)
`
`Standard Static
`Are Gnlena for
`
`Aucnnn Conversicm
`Catalog system
`
`
`
`S Itisfied?
`
`
`
`
`crilena may Include Inventory
`levels, sales Vales, pnce to sales
`relationships. lime to Inveniory
`refresh Manuel activallon is
`always pessxble
`
`Live Auciiun receives
`localion of It's copy at
`Auction Data and returns Il's
`location to cunversion
`process
`
`
`
`
`
`_l_e
`Dispatch animation vie
`preferred messaging
`sysiem
`
`
`
`
`
`lnstanl Massaglng
`Has Iisl been
`
`completed?
`
`
`
`
`
`
`
`
`Newly creeied
`Acirveie Auinm eted
`
`
`Automated
`Auction end wenrorrua
`
`
`
`Live Auction
`return “'5 location
`
`
`(pointer, hyporllnk. er
`aiher locate!)
`
`
`
`
`Replace Stanard Sele
`Live Auction takes
`contmlls In Siam:
`
`control 91 All Auctlon
`
`Auction wllh Llrlk to Live
`Dala
`Auction
`
`(a: an Invrrairan
`
`Live Au ciIon
`
`Location
`
`Messegmg
`spetch
`
`
`System
`
`{Kerri Inventory
`
` Details
`
`s bidder logged er.
`to sysiem7
`
`
`No
`
`
`Format Message (or
`
`Notify Bidder v-e
`
` Message |
`chosen massing In
`
` Leeei Message
`system
`
`
`
`
` Olber
`(Page r, in leracliva TV,
`eic
`
` Wait fer notification Yrem
`reel—limo auction 0'
`
`com pleleion or Iire
`auclmn
`
`
`
`
`Inirasled
`Create List Of Bidders
`
`
`User List
`with Conlacl Info
`
`Lisl 01 Potential
`
`
`Bidders generated by
`integrate all lists and
`Operator
`filler for eupiiceies or
`
`Invalid enlnes
`Llst 6! potential
`bidders from 3rd
`
`
`parties (InVlKUSJ
`
`
`
`
`
`_;Ll_
`Screen users and
`pravxde Contact
`Inform alien
`
`
`Final list
`
`
`
`
`
`
`
`
`
`
`
`
`
`S tnred user profiles
`
`Procesa
`Flow
`
`Data
`WFlow
`
`
`
`
`
`
`
`
`
`Coniact Stain: Sale
`
`
`sysiem Remove uxier
`
`enierrng Real-lime
`Auclion PmVIde llnel
`sales info Io Stale
`
`
`System for records
`
`
`
`Finlsh Dale and Siorege
`
`Clean up
`
`
`Convonlon I: complelod
`
`
`FIG. 6
`
`007
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`007
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`US 2002/0049664 A1
`
`Apr. 25, 2002
`
`MULTIPLE, CONCURRENT DYNAMIC AUCTION
`EMULATION FOR NETWORKED
`ENVIRONMENTS
`
`FILED OF THE INVENTION
`
`invention pertains to systems and
`[0001] The present
`methods for implementing systems that permit multiple,
`concurrent dynamic auction emulations for wide area net-
`work environments. More particularly,
`the invention is
`directed to means for permitting a plurality of bidders to
`simultaneously bid on a plurality of auction lots using
`established criteria for conducting each auction. The inven-
`tion also is directed to converting a traditional online static
`auction into a dynamic auction.
`
`BACKGROUND OF THE INVENTION
`
`[0002] Real world or dynamic auctions are intended to
`maximize the value received for an auction lot subject to
`bidding. As is well known, a lot is presented to a discrete
`group of interested bidders by an auctioneer. The auctioneer
`establishes the minimum starting bid, and moderates the
`bidding by a) accepting a valid bid offered by at least one
`bidder in the group of bidders, and b) offering a new bid for
`acceptance by at least bidder in the group of interested
`bidders. The process continues until no additional bidders
`for a given accepted bid will accept the next bid offered by
`the auctioneer.
`
`the group of bidders is
`[0003] As is also well known,
`generally fixed; the number of participants is unique during
`the bidding process for any given lot. Moreover, because
`each lot auction is unique, the composition of the auctioneer
`is also generally fixed. The consequence of this auction
`model is that a given group of bidders can only participate
`in a single auction at any given time, and an auctioneer can
`only moderate a single auction at any given time, since a
`person can only be in one place at any given time.
`
`[0004] Attempts have been made in the online environ-
`ment to emulate a dynamic or real auction environment.
`Commercial undertakings as exemplified by eBay.com rep-
`resent the most common approach. Taking advantage of a
`computer network environment, these attempts provide mul-
`tiple simultaneous auctions wherein bidders have a set time
`limit for presenting their bids for a given lot. For any given
`lot, a starting bid is presented to all potential bidders, and the
`bidders are given unlimited opportunities to offer money for
`the lot within the set time period. As the auction data is
`updated and the user ascertains the state of bidding, the user
`may elect to increase his or her bid, usually in an amount
`pre-established by the auction software. However,
`it
`is
`common for a bidder not to increase his or her bid to a
`
`maximum until more information concerning other bidders
`in the group is known, e. g., waiting until near the close of the
`auction for the possibility of being the last bidder prior to the
`close and not having to reach his or her maximum bid.
`
`[0005] While the foregoing approach may be good for the
`bidder in that he or she may obtain the lot without having to
`present a maximum bid, it is deficient in two ways: first, the
`maximum possible price is usually not obtained since other
`bidders, willing to offer more money for the lot, may have
`missed the close; second, some bidders may be frustrated
`since they were not given sufficient time in which to place
`higher bids in order to obtain the desired lot. In a conven-
`
`tional live or dynamic auction, neither of these deficiencies
`would have been encountered.
`
`is clear that present
`it
`[0006] Based on the foregoing,
`online auction models do not approximate the experience of
`dynamic live auctions, nor meet the expectations of its users
`or providers. What is needed is a more realistic emulation of
`live auctions for use in an online environment, and an ability
`to convert static online auctions into dynamic online auc-
`tions that approximate the real world experience.
`
`SUMMARY OF THE INVENTION
`
`[0007] The present invention concerns systems and meth-
`ods for creating multiple, concurrent real
`time dynamic
`auctions in a networked online environment. By changing
`the paradigm relating to online auctions, it is now possible
`to achieve a faithful emulation of a real world dynamic
`auction where the bidding experience is preserved and
`maximum price for an auction lot is obtained, while exploit-
`ing the benefits of conducting online commerce. The inven-
`tion is directed to both establishing online one or more real
`time dynamic auctions as well as converting traditional
`static auctions to one or more real time dynamic auctions.
`
`[0008] An aspect of the invention is implemented in a
`networked computer environment wherein at least one bid-
`der is operatively linked to a central computer. The operative
`linking of the bidder is accomplished preferably in the form
`of at least two computing or network client devices having
`a processor, memory, an input device such as a keyboard
`and/or pointing device, an output device such as a monitor,
`and network communications abilities such as a network
`
`interface or modem, wherein the computers are linked to the
`central computer by way of a communications link, e.g.,
`wireline, wireless, or radio frequency. In this basic environ-
`ment, a competitive bidding environment with one live
`bidder is created by using one or more proxy bidders, which
`will be described in more detail below.
`
`[0009] Most desirably, a large plurality of bidders is so
`linked to the central computer as may be found in a global
`communications network, e.g., the Internet. Preferably, bid-
`der computers will have conventional operating systems,
`e.g., Linux, Macintosh 088; Windows 95, 98, me, 2000, XP;
`Palm OS; and conventional client applications, e.g., HTML
`compatible, Java-based, or XML compatible browser appli-
`cations, or native platform specific browser applications, as
`well as notification client applications, e.g., e-mail (POPS),
`instant messaging, and paging applications. Alternatively or
`in addition to traditional network client devices such as
`
`computers, other forms network client devices include wire-
`less devices, set top boxes, and similar consumer technolo-
`gies.
`
`[0010] The central or server computer may comprise one
`or more computers, but shall be referred to in the singular for
`convenience. The central computer, which may be a server-
`type computer, is linked to the same communications net-
`work as the at least one network client device, although the
`communications link need only be able to transmit data to
`and receive data from the at least one user regardless of the
`mode of communication. In addition to the communications
`
`link, the central computer has sufficient resources to operate
`computer applications capable of carrying out aspects of the
`invention. While the specifics shall be identified below,
`general attributes include an operating system such as
`
`008
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`008
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`US 2002/0049664 A1
`
`Apr. 25, 2002
`
`Microsoft’s Windows NT/2000, Linux, Unix, and other
`multitasking or multithreading operating systems. Applica-
`tions adaptable to the invention include Oracle products and
`Microsoft SQL. In addition to the foregoing, implementation
`of the invention can use a variety of programming languages
`and shelf-based applications. Nevertheless, preferred pro-
`gramming or pseudo programming languages include Java,
`JavaScript, C, C++, Visual Basic, VBScript, and ActiveX
`controls. Data presentation and acquisition across the net-
`work is preferably carried out by common browser-based
`protocol such as HTML code, XML code, Active Server
`Pages (ASP), JSP, SOAP, JMS, and others. However, any
`form of data presentation and acquisition is considered
`within the scope of the invention, e.g., instant messaging.
`
`In preferred form, the central computer comprises
`[0011]
`three discrete server-class computers operatively linked
`together, although a single computer or more than three
`computers can be used and is considered a design factor. The
`central computer is responsible for a given set of processes,
`which will now be described. The first set of processes
`relates to the acquisition, processing, and dissemination of
`auction related data and is handled by the Auction Database
`Manager (ADM) component or
`layer. The ADM layer
`includes one or more data tables having information com-
`prising auction lot data, proxy and pre-existing bid histories,
`previous and current bidder identification and profiles, and
`communications protocol and addresses. This information
`may be obtained from a pre-existing database and/or from
`information obtained from other components or layers of the
`invention embodiment. In addition to acquiring, processing,
`and disseminating the aforementioned data, the ADM ini-
`tiates the Rules-Based Action (RBA) component or layer,
`stores data obtained from the RBA, provides historic data to
`the RBA upon query, and provides historic data to a main
`auction archive.
`
`[0012] The RBA layer operates to control operation of the
`overall invention, and utilizes the data resources of the ADM
`and a User Interface Manager (UIM) component or layer,
`which will be described later. Using a pre-determined rule
`set
`that depends upon the information presented by the
`ADM, a series of actions are carried out. While the order of
`the actions may be relevant to any given situation, they are
`presented here in a non-limiting order.
`
`[0013] One action that the RBA must undertake is the
`resolution of any proxy bids that may apply to the given
`auction. As noted previously, bidder information may com-
`prise proxies for certain auction lots. Because the auction
`will accept bids up to a certain limit, it is often desirable to
`compare proxy maximums to ascertain the composition of
`proxy bidders. Naturally, a software simulation can be used
`so that as the auction information is refreshed for the benefit
`
`of the active bidders to appear that there is more activity, and
`thus increases the “auction experience” of the bidders.
`
`[0014] Presuming that the proxy bids are resolved prior to
`the start of the auction, the UIM is called to begin bidder
`notification and/or solicitation actions, as determined in part
`by the data stored in the ADM database. In turn, bidder
`information obtained by the iterations of the UIM is passed
`to the RBA and ADM. Once established criteria such as
`
`minimum bid, reserve price, identification of bidders, and
`possible resolution of proxy bids are met,
`the auction
`commences. Once started, bid offer and acceptance infor-
`
`mation is passed between all layers of the invention, and
`similar information is passed to all active bidders. The
`bidding and accepting process will continue until there is no
`higher bid acceptance by any of the participants for a given
`period of time.
`
`[0015] As noted previously, the UIM handles all bidder
`interface issues. Depending upon presentation features
`ascertained from a bidder by bidder polling and/or by profile
`information present
`in the ADM,
`the UIM will control
`multimedia matters. Outgoing data will be presented to a
`bidder based upon preferences and bidder devices, while
`incoming data from the bidders will be parsed and trans-
`ferred to the ADM and RBA components.
`
`[0016] Another aspect of the invention comprises methods
`and systems for converting an online static auction with an
`expiration time to a dynamic real-time auction that ends
`when the absolute highest bid for a lot has been reached. As
`a condition prerequisite to auction conversion, there must
`exist a valid and operational static online auction. While not
`considered to be part of the invention, the existence of the
`static auction is necessary for this aspect of the invention to
`be carried out. Therefore, to provide the reader with suffi-
`cient background, the essential components of a static auc-
`tion will be described.
`
`[0017] Because the primary purpose of the static auction
`as relative to this aspect of the invention is to provide
`information concerning the seller, the lot, the bidders, and
`the static auction bidding history, the mode of static auction
`operation is not critical. However, it is necessary that at least
`part of the previously described information be accessible by
`the dynamic online auction software applications described
`earlier. Thus, the form of invention implementation may be
`driven in part by a desire or need to remain compatible with
`the existing static auction software and operating system
`platform such that acquisition of data from the static auction
`database is not unnecessarily complicated. Consequently,
`interapplication data exchange is desired, but not necessary
`(a separate conversion application can be used instead). In
`preferred form, the existing static online auction and the
`invention operate in a server environment such as Windows
`NT, Windows 2000, Unix (and common variations thereof),
`Linux, and others, and the application software is similarly
`based, e.g., Microsoft SQL Server and Access, Oracle data-
`base products and others.
`
`the invention concerns a
`In one embodiment,
`[0018]
`dynamic online auction. A method for conducting such an
`auction uses a communications network having a central
`computer for hosting the dynamic auction and providing/
`receiving electronic data. The central computer is opera-
`tively linked to a first group having at least one bidder and
`has at least one auction lot subject to bidding. The method
`then comprises a) providing electronic data to the first group
`comprising information relating to the first auction lot and
`an initial bid; b) receiving bid information from at least one
`bidder of the first group concerning the first auction lot; c)
`providing electronic data to the first group comprising
`information relating to the received bid information con-
`cerning the first auction lot; d) repeating b) and c) until no
`further bid information is received from any bidder con-
`cerning the first auction lot when no bid higher than the last
`received bid is received within a pre-established period of
`time, thus concluding bid receiving; and f) providing elec-
`
`009
`
`SERVICENOW |NC.'S EXHIBIT 1004
`
`009
`
`SERVICENOW INC.'S EXHIBIT 1004
`
`

`

`US 2002/0049664 A1
`
`Apr. 25, 2002
`
`tronic data to the first group comprising information relating
`to the last received bid information
`
`[0019] An aspect of this embodiment addresses the issue
`of proxy bidders. In the event that an interested user cannot
`participate in the dynamic auction, it is possible to submit a
`proxy bid. The proxy bid can be handled in several ways,
`including submitting it at any time during the dynamic
`auction, at a predetermined threshold (as determined by
`duration of the auction or present bid value), or incremen-
`tally (a percentage of the total bid value is submitted based
`upon the duration of the auction or present bid value, up to
`the full value of the proxy bid). In this manner, the auction
`remains dynamic even if the number of live bidders is low.
`Moreover, in this manner and if done incrementally, a proxy
`bidder may not have to reach his or her authorized maximum
`as the host administers submission of the incremental proxy
`bids.
`
`[0020] Another aspect of this embodiment permits more
`than one auction to be concurrently run. In this situation, a
`second or more groups are identified and participate in the
`dynamic auction. The various groups are not necessarily
`discrete; a bidder in one group can also be a bidder in
`another group.
`
`[0021] Having addressed several foundational matters and
`what constitutes a dynamic auction, the conversion aspect of
`the invention will now be described. A method for convert-
`
`ing an online static auction with an expiration time into an
`online dynamic auction comprises a) establishing an agree-
`ment between a seller and an auction provider to permit a
`conversion from a static auction into a dynamic auction; b)
`meeting predetermined criteria for permitting conversion of
`the auction; c) passing control of the auction from the static
`software application to a dynamic software application; d)
`establishing a list of at least one dynamic bidder (in the case
`where there is only one live bidder, it is necessary to have
`at least one proxy bid established, which may be presented
`to the live bidder or may be incrementally presented to
`emulate a live auction; e) communicating with the at least
`one bidder to indicate the beginning of the dynamic auction;
`and f) conducting the online dynamic auction. Because
`overall implementation of this feature of the invention is
`highly situation specific, numerous variations exist. The
`following examples are intended to illustrate the flexibility
`of the invention, and should not be construed as limitations
`thereof.
`
`[0022] The agreement in a) can be handled simply as
`default system policy that the seller agrees by placing an
`item on the system for auction. In this case, a seller wishing
`to submit his or her lot for auction impliedly agrees to permit
`a conversion to take place upon the occurrence of predeter-
`mined conditions or events. Alternatively, the agreement can
`be made as part of the application process whereby the seller
`authorizes or requests that
`the lot be made eligible for
`conversion and the auction operator explicitly approves the
`lot for auction conversion. Additionally, the auction operator
`may, based on criteria including but not limited to price, item
`type, auction activity for similar items, etc. request autho-
`rization from the seller for the item to be made eligible for
`conversion. The request for authorization may be accom-
`plished in a similar manner as with respect
`to bidder
`notification as set forth below, or by other means such as
`telephone contact.
`
`[0023] The meeting of criteria to begin conversion in b)
`also has great flexibility, and can be generally stated as being
`dependent upon one or more auction variables: expiration of
`static auction, fixed time, reserve price,
`last bid for lot,
`bidding activity, subject matter of lot, size of lot, seller
`defined criteria, etc., as well as resource constraints such as
`server computing resources. For example, the rules or poli-
`cies for conversion to take place may depend upon the
`expiration time of the static auction. Thus, conversion may
`take place “10 minutes before expiration of the static auc-
`tion.” Another example is to establish a fixed time for
`commencement, e.g.,
`the time of day. In this example,
`having a predetermined time for commencement can be used
`to load balance the system or provide more opportunities to
`bid during times of high activity. Another possibility is based
`upon price of the lot: the operator may limit conversion to
`items that have reached a reserve price or other price target.
`Still another viable variable for beginning the conversion
`process relates to the total number of bidders that have
`engaged in the static auction. For example, it may be a more
`efficient use of system resources to only convert popular
`items that have already had specific level of activity. Alter-
`natively,
`the conversion criteria can be based upon the
`number of bidders presently participating in the static auc-
`tion. This would limit even more the number of items that
`
`would actually undergo the conversion process. In this case
`the conversion would only take place if a predetermined
`number of active bidders were participating in the static
`auction.
`
`In order to assess the state of the aforementioned
`[0024]
`variables in addition to others not specifically identified
`above, the static online auction database and the dynamic
`online database should be constructed to track at least some
`
`of these variables. In a preferred embodiment, the ADM
`component or layer will either have this information ported
`to it, or will access the static auction database for selected
`information.
`
`[0025] The passing of control in c) can be accomplished
`by several means. For example, the passing of control can be
`by issuing a stop static auction command and directing
`further I/O operations to the dynamic auction application.
`An alternative would be to utilize existing static auction
`system interrupts that permit such actions. Another alterna-
`tive would be to modify the static auction source code and
`related compiled iteration to include porting of the desired
`information. At the same time that auction control is passed
`to the dynamic auction application, bidders wishing to
`participate in the static auction are notified of the change in
`status, e.g., the expected auction interface is replaced by a
`suitable notification of the conversion to dynamic mode.
`
`[0026] The list of bidders in d) can be ascertained from
`many different sources, many of which derive importance
`based upon auction operator criteria. The final list of bidders
`to contact and invite to the dynamic auction can come from
`numerous sources, three of which are particularly relevant.
`
`[0027] A first source of users for the dynamic auction
`notification list is derived from bid data stored in the static
`
`auction database. The bidders may be those presently engag-
`ing in active bidding in the static auction, those who are
`currently or have bid in the static auction, and/or those who
`have at any time and for any reason utiliz