EP1664987A2

EP1664987A2 - Auction engine connector

Info

Publication number: EP1664987A2
Application number: EP04784564A
Authority: EP
Inventors: David Elliston; Winston Li; Kayhan Demirel
Original assignee: Individual
Current assignee: SAP SE
Priority date: 2003-09-19
Filing date: 2004-09-17
Publication date: 2006-06-07
Also published as: WO2005029283A2; WO2005029283A3; EP1664987A4

Abstract

A bidding system may include an auction engine which may manage a live auction between clients at user sites (e.g., purchaser (or initiator) and bidder sites). The auction engine may communicate with messaging clients at the user sites using an XML over HTTP protocol. The auction engine may include an XML connector to translate communications to and from the messaging clients into messages conforming with the protocol. The XML connection may also provide real-time updates to the messaging clients.

Description

AUCTION ENGINE CONNECTOR

CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to U.S. Provisional Application Serial No.

60/504,266, filed on September 19, 2003.

BACKGROUND [0002] In electronic commerce, dynamic systems for commercial transactions provide a number of advantages not available in static systems. In general, a dynamic system is one in which the characteristics of potential transactions, as well as the universe of available transactions, may change over time. An online auction is an example of a dynamic system. In contrast, a static system is one in which the characteristics of a potential transaction generally do not change. An offer to sell a product at a fixed price on a company's web site is an example of a static system. [0003] Conventional dynamic systems for commercial transactions, such as online auction sites, generally provide companies or other entities with an efficient avenue for buying and selling goods and services. For example, an auction may be opened to a much wider range of participants when conducted online. However, conventional online systems tend to be limited in flexibility, security, and/or functionality.

SUMMARY [0004] An auction system may include an auction engine to manage an auction between a number of clients, e.g., computers at purchaser and bidder sites. The auction system may include an XML connector to provide an interface between the auction engine and clients. The auction engine may store a list of clients participating in the auction, and, for each participating client, a log of auction data sent to that client. The XML connector may generate and send an update XML message to a participating client in response to an update request from that client. The update XML message may include only a selected portion of available auction data for that client based on the log of auction data already sent to that client, so that the client is "incrementally" updated, which may facilitate a real-time environment for the auction. The update data may be sent in an auction header of the update XML message. [0005] The update XML message may include message types corresponding to a live auction XML schema that defines a protocol for the XML connector. The XML connector may send a number of other messages to the clients using the protocol. For example, the XML connector may send an XML message including data corresponding to a bid received from said client, which may include a reason for rejection of a bid or a new rank for the client based on a bid. The XML connector may send XML messages including chat data. The XML connector may also send an XML message to a participating client including data operative to terminate that client's participation in the auction, e.g., in response to not receiving an update request within a timeout period. BRIEF DESCRIPTION OF THE DRAWINGS [0006] Figure 1 is a block diagram of a networked computer system including an auction engine. [0007] Figure 2 illustrates an auction obj ect format. [0008] Figure 3 is a flowchart describing interactions between a messaging client and the auction engine during an auction. [0009] Figure 4 shows a state chart for a live auction messaging client.

DETAILED DESCRIPTION [0010] FIG. 1 illustrates a networked computer system 100. The system may include a client computers at a purchaser site 105 in an enterprise system 107 and client computers at bidder sites 110. The client computers may be connected to the Internet 115 through other networks (e.g., local area networks 120 (LANs) or intranets) and/or a portal 125. [0011] A purchaser can use an auction engine 130 to create an auction event on which potential bidders may place bids. The purchaser may be a human operator interacting with software running on a computer system, or an automated software process executing without human intervention, or various combinations of both. The auction engine 130 may reside, at least partially, at the purchaser site 105 and/or a server. The auction engine may be implemented on a back end system 135, e.g., an enterprise software system such as SAP AG's R/3 system. [0012] "Live" auctions may be carried out between the bidders and purchaser in a real-time environment. Live auctions may simulate the experience of an actual auction by utilizing technology to provide instantly updated information on all auction activity. Unlike other auction systems (e.g., eBay) that require the user to check back periodically for bids from other users, the auction engine allows a user interface to update itself automatically in real time as bids occur. [0013] The live auctions created using the auction engine may be reverse auctions. A reverse auction is an auction that uses the bid-down principle, in which the price being bid descends during the auction and the lowest bid is the winning bid. In general, the bidders are sellers or suppliers of goods or services who are offering to supply the requested good or service at the bid price. A reverse auction can provide buyers with significant cost savings by better leveraging competition among bidders. [0014] Auctions may be represented as objects in the auction engine. The auction objects may share a similar format 200, such as that shown in FIG. 2. An auction may include a header 205, one or more line items 210, and attachments 220. The header may include general information about the auction, such as a product category, bidding rules and conditions, duration, and auction status e.g., published or active). Line items identify products or services to be sourced and include item details and reserve price. Attachments can be of any file type and can be added to line items in the auction, e.g., an internal note or vendor text uploaded from a PC. Live auctions may be started, ended, and extended automatically according to the time parameters set by the purchaser when creating the auction. [0015] The purchaser and bidder client computers may each include a messaging client that provides a user interface for that purchaser or bidder and also provides a number of features to facilitate the real time auction environment. For example, the messaging client may enable the purchaser and bidders to monitor an auction and bidding activity in real time. The messaging client user interface may be simple or rich, e.g., with real-time charts and graphs to provide a visual representation of the auction data and a chat function to provide instant messaging capability. The messaging client may provide the comiection status of each invited bidder to the purchaser and the connection status of the purchaser to the bidders, and a bid calculator may provide bidders with an overall total bid price before they submit their bids. [0016] The messaging framework for the messaging clients and the auction engine may be technology platform independent. For example, the auction engine may run inside an J2EE server, whereas the messaging clients may be run as, e.g., Java applets, ActiveX controls, Visual Basic applications, .NET web applications, etc. The technology platform independence of the system may enable bidders outside the enterprise system 107 the freedom to create their own messaging clients using a preferred technology platform. [0017] The protocol for communication between the auction engine and the messaging clients, and between messaging clients, may be XML (Extensible Markup Language) over HTTP (Hypertext Transfer Protocol): that is, each message corresponds to an XML snippet, which is delivered via HTTP. Communications between the auction engine and messaging clients may be transferred as XML documents using message types corresponding to a live auction XML schema. The different message types in the protocol are described in the APPENDIX following this description, which is an XML schema defining the grammar (acceptable) content of the XML documents according the protocol used by the XML connector. The message types are bundled into either a RequestEnvelope (wliich the client sends to the server) or a ResponseEnvelope (which the server sends to the client).

[0018] A live auction XML connector 140 may be used by the auction engine 130 to translate the serialize Java objects used by the auction engine into XML messages. The messaging clients may also have an XML interface to generate and parse XML documents according to the protocol. In an embodiment, the messaging client may also bypass the XML connector 140 to speak a different (legacy) protocol with the auction engine, e.g., native Java objects. [0019] Figure 3 is a flow chart describing interactions between a messaging client and the auction engine during an auction. When the client first connects to the server (representing the auction engine 130 and XML connector 140) (block 302), the client authenticates itself with the server (block 304), e.g., by sending an authorization token in each HTTP request. The client then subscribes to a specific auction (block 306). The server updates its subscription list (block 308) so it knows this client will need to be notified of bids on this auction. The server then returns the current auction data to the client (block 310). [0020] Subscribing to an auction is tantamount to logging in. The client is expected to log out eventually. If the client fails to contact the server periodically to receive updates, the server will consider the client dead, and log it out automatically. Also, all other clients are notified when a client logs into or out of an auction. [0021] Once the client subscribes to the auction, the client may issue bids and chat commands in response to a user actions (block 312). The client also periodically polls the server, e.g., every few seconds, while subscribed to request updates to the auction that have occurred since the client last queried the server. The XML connector may utilize an "incremental update" approach to support the real-time aspect of the live auction. The auction engine may keep a log of data previously sent to the various clients, e.g., in a database 145, and only send update information when polled by a particular client (block 314). This may improve performance by delivering only changed information, not the entire auction, to the client. If another user has placed a bid, sent a chat message, or altered the auction since the last time the client received an update, these changes are returned to the client for it to display as it sees fit. [0022] Figure 4 is an exemplary state chart for a live auction messaging client, which demonstrates the actions available to the client at different points in the protocol. A user may enter an auction by starting the messaging client and entering an INITIAL state 402. In the INITIAL state, the messaging client can neither send nor receive messages. The user may log in to an auction by calling a start method (startQ). Once in the LOGIN state 404, the messaging client can attempt to log in to the auction by sending a HelloReq message, which may contain a partnerlD identifying the user, an auctionlD identifying the auction, and clientType identifying the user's role (e.g., purchaser or bidder). The user may also quit the messaging client by calling a stop method (stop()), which will cause the messaging client to transition to a TERMINATING state 406. The messaging client can send a GoodbyeReq message to indicate to the auction engine that the messaging client is being terminated. [0023] hi order to transition from the LOGIN state 404 to an ACTIVE state 408, the messaging client must receive a WelcomeResp message from the auction engine (via the XML connector) in response to its HelloReq message. The WelcomeResp message may include such information as clientGuid, which is a unique ID for the client generated by the back end system, the partnerlD for confirmation, and all auction information. For the purchaser, the WelcomeResp message may additionally contain the full bid history and the invitation list, including the connection status (partnerlD, name, isLoggedln) of the bidders. For the bidders, the WelcomeResp message may additionally contain the bidder's bid history and the purchaser's connection status (partnerlD, name, isLoggedln). The auction engine may also send a TerminatedResp message to the messaging client in the LOGIN state, which is sent when the messaging client is terminated by the server, e.g., due to a ping timeout, a login timeout (user management logon ticket expired), or another login from this user ID. The TerminatedResp message may contain a description explaining which event occurred. For a ping timeout, the messaging client may reconnect; otherwise, the messaging client should exit. [0024] In the ACTIVE state 408, the messaging client may call the stop method to terminate, call a sendMethod () method to send messages, and/or call a getCurrentTimeMillis() method to get a current time. [0025] The messages the messaging client can send in the ACTIVE state 408 are a BidReq message to submit a bid, a ChatReq message to send a chat message, and/or a GoodbyeReq message to terminate the session. The ChatReq message may contain the chat text and the partnerlD of the recipient (or a null value if this is a broadcast from the purchaser). [0026] The messages the messaging client may receive in the ACTIVE state 408 from the auction engine include the following: AuctionChangedResp; BidRejectedResp; ChatResp; NewBidResp; UserChangedResp; and TerminatedResp. The AuctionChangedResp message may be sent when the auction changes. Auction changes may occur when an auction becomes open for bidding (when previously it was in the published state), becomes closed (because time ran out, or because the purchaser changed the status), or is extended. The AuctionChangedResp may contain the auction header, from which the change may be deduced. The BidRejectedResp message indicates that a bid was rejected, and may contain the LineltemID, a reason code, and/or text describing rejection reason. The ChatResp message may be sent for a chat message and may contain chat text, the partnerlD/name of the sender, and a flag indicating whether it is a broadcast. The NewBidResp message notifies that a bid was submitted and may contain the LineltemID, price, partnerlD, and an indication of whether the reserve price was met, if applicable. Also, for a bidder, the NewBidResp message may contain a new rank for the bidder. The UserChangedResp message may be sent when a user joins or leaves the auction, and may contain the partnerlD/name of the specified user and a flag indicating whether that user joined or left. [0027] Once a messaging client session is terminated, whether initiated by the messaging client (by calling the stop method or sending a GoodbyeReq message) or by the auction engine (by sending a TerminatedResp message), the messaging client may enter a TERMINATED state 410 and shut down. [0028] As described above, the live auction XML connector facilitates a real-time auction environment based on the exchange of XML documents. Also, the XML connector allows the connection of clients built using different technology platforms (e.g., Java, ActiveX, .NET, etc.) to promote flexibility in the messaging framework. [0029] The applications described herein (also known as programs, software, or code) may include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the term "machine-readable medium" refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor. [0030] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), and the Internet. [0031] A number of embodiments have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.

APPENDIX

<?xml version=" 1.0" encoding="UTF-8"?>

<xs : schema targetNamespace="http : //www. sap.com/SRM_LA" xmlns :xs="http: //www.w3. org/200l/XMLSchema" xmlns="http: //www. sap. com/SRM_LA" elementFormDef aτ_ιlt= "qualified" attributeFormDef ault= "unqualified" > <xs : element name="RootElement "> <xs : com le:xType> <xs:cho±ce> <xs : element name= "request" type= " RequestEnvelope " / > <xs : element name=" response" type= "ResponseEnvelope " / > </xs:choice> </xs: compl exType > </xs : element> <xs :simpleType name="GUID" > <xs : restriction base="xs : string" > <xs:minL.ength value="32"/> <xs : axLength value="32"/> </xs : restr iction> </xs : simpleTγpe> <xs : simpleType name=" Client Type" > <xs : restriction base="xs : string" > <xs : enumeration value=" Initiator" /> <xs : enumeration value= "Respondent "/> </xs : restr iction> </xs : simpleType> <xs : simpleType name="DisplayColumn" > <xs : restriction base="xs : string" > <xs : enumeration value= COMP_BIDS"/> <xs : enumeration value= BEST_BID"/> <xs : enumeration value= NEXT_VALID_BID " / > <xs : enumeration value= RANK"/> <xs : enumeration value= RESERVE_PRICE " / > <xs : enumeration value= BID_DECREMENT " / > </xs : restr ±ction> </xs : simpleType > <xs : complexType name= "Locale "> <xs : all> <xs : element name =" Count ry " > <xs : sdmpleType> <xs : restriction base="xs : string" > <xs cminLength value="2"/> <xs : maxLength value="2"/> </xs : restriction> </xs : simpleType> </xs : element> <xs : element name="Language"> <:xs : simpleType> <xs : restriction base="xs : string" > <xs : minLength value="2"/> <xs :maxLength value="2"/> </xs : restriction> </xs : simpleType> </xs : element> </xs:all> </xs : comp1exType> <xs : complexType name="Price" > <xs:all> <xs: element name="amount" type="xs : decimal "/> <xs : element name=" currency" type="xs : string"/> </xs :all> </xs : complexType> <xs : complexType name="ReasonCode" > <xs :all> <xs : element name="messageText " type="xs : string" /> <xs : element name="isFatal" type="xs :boolean" > <xs : annotation> <xs : documentation>if true, client should exit; if false, client should restart</xs : documentation> </xs : annotation> </xs : element> </xs :all> </xs : com lexType> <xs : complexType name="PreciseDateTime"> <xs :all > <xs : element narαe="dateTime" type="xs : dateTime "/> <xs : element name= "milliseconds "> <xs : annotation> <xs :documentation>Millseconds past the second indicated in the dateTime element . </xs : documentation> </xs : annotation> <xs : simpleType> <xs : restriction base="xs : integer" > <xs :minlnclusive value="0"/> <xs :maxlnclusive value="999"/> </xs : restriction> </xs : simpleType> </xs : element> </xs :all> </xs : complexType> <xs : complexType name="AuctionProfile" > <xs : all> <xs:element name="description" type="xs : string" /> <xs : element name="decrementType "> <xs : simpleType> <xs : restriction base="xs : string" > <xs : enumeration value="Percent "/> <xs : enumeration value="Amount " /> <xs : enumeration value="None"/> </xs :restriction> </xs : simpleType> </xs : element> <xs : element name="displayColumns"> <xs : complexType> <xs : sequence> <xs : element name="displayColumn" type="DisplayColumn" maxOccurs="unbounded"/> </xs : sequence> </xs : complexType> </xs : element> </xs : all> </xs : complexType> <xs : complexType name="AuctionStatus" > <xs : all> <xs : element name="id"> <xs : simpleType> <xs : restriction base="xs : string" > <xs : enumeration value="Complete"/> <xs : enumeration value="Published"/> <xs : enumeration value="Active"/> <xs : enumeration value="Paused" /> <xs : enumeration value="Closed"/> </xs : restriction> </xs : simpleType> </xs :element> <xs : element name="description" type="xs : string" /> </xs :all> </xs : complexType> <xs : complexType name="AuctionParticipant "> <XS:all> <xs:element name= "partnerlD" type="GUID"/> <xs : element name="isConnected" type="xs : boolean" /> <xs : element name="displayName" type="xs : string" /> <xs : element name="clientType" type="ClientType "/> </xs:all> </xs : complexType> <xs : complexType name="AuctionHeader"> <xs :all> <xs : element name="auctionlD" type="GUID"/> <xs : element name="externalID" type="xs : string" /> <xs:element name="partnerIDOwner" type="GUID"/> <xs : element name="creatorDisplayName" type="xs : string" /> <xs : element name="name" type="xs : string" /> <xs : element name= "description" type="xs : string" /> <xs : element name="startDate" type="xs : dateTime" /> <xs .element name="endDate" type="xs : dateTime" /> <xs : element name="auctionProfile" type="AuctionProfile"/> <xs : element name="auctionStatus" type= "Auct ionStatus " /> </xs : all> </xs : complexType> <xs : complexType name= "ChatRecord" > <xs :all> <xs : element name="chatID" type="GUID"/> <xs : element name="auctionlD" type="GUID"/> <xs .element name="partnerIDSender" type="GUID"/> <xs : element name="partnerIDRecipient" type="GUID"/> <xs : element name="text" type="xs : string" /> <xs: element name="timestamp" type="xs : dateTime "/> </xs : all> </xs : complexType> <xs : complexType name="BidRecord" > <xs :all> <xs : element name="bidID" type="GUID"/> <xs : element name="auctionlD" type="GUID"/> <xs : element name="auctionItemID" type="GUID"/> <xs : element name="price" type=" Price"/> <xs : element name="quantity" type="xs : decimal "/> <xs : element name="baseUnit " type="xs : string" /> <xs : element name="partnerIDBidder" type="GUID"/> <xs : element name="timestamp" type="xs : dateTime "/> </xs : all> </xs : complexType> <xs : complexType name="BidUpdate"> <xs:all> <xs : element name="bidRecord" type="BidRecord"/> <xs : element name="nextValidBid" type="Price"/> <xs : element name="bidDecrementAmount " type= "xs : decimal " /> <xs : element name="isReservePriceMet " type="xs :boolean"/> <xs : element name="currentRan " type="xs : integer" /> </xs :all> </xs : complexType> <xs : complexType name="AuctionItem" > <xs :all> <xs : element name="auctionItemID" type="GUID"/> <xs:element name="externalID" type="xs : string"/> <xs : element name="item ame" type="xs : string"/> <xs : element name="description" type="xs : string"/> <xs : element name="startPrice" type="Price"/> <xs:element name="bidDecrement" type="xs : decimal "/> <xs : element name="quantity" type="xs : decimal "/> <xs : element name="baseUnit" type="xs : string"/> <xs : element name="reservePrice" type="Price"/> <xs:element name="priceUnit " type="xs : integer"/> </xs:all> </:xs : complexType> <xs : complexType name="AuctionltemDetails" > <xs : all> <xs : element name="auctionItem" type="AuctionItem"/> <xs : element name="bidHistory"> <xs : complexType> <xs : sequence> <xs : element name="bidRecord" type="BidRecord" maxOccurs="unbounded" /> </xs : sequence> </xs : complexType> </xs :element> <xs : element name="bidUpdate" type="BidUpdate"/> </x : all> </xs : complexType> <xs : complexType name="AuctionDetails"> <xs : all> <xs : element name="auctionHeader" type= "AuctionHeader"/> <xs : element name="itemDetailsList" > <xs : complexType> <xs : sequence> <xs : element name="itemDetails" type= "AuctionltemDetails" maxOccurs="unbounded"/> </xs : sequence> </xs : complexType> </xs : element> <xs :element name="chatHistory" > <xs : complexType> <xs : sequence> <xs: element name="chatRecord" type="ChatRecord" minOccurs="0" maxOccurs="unbounded"/> </xs : sequence> </xs : complexType> </xs : element> <xs : element name= "participantList " > <xs : complexType> <xs : sequence> <xs: element name= "participant " type="A^"uctionParticipant " maxOccurs= "unbounded" /> </xs : sequence> </xs : complexType> </xs : element> </:xs : all> </xs : complexType> <xs : complexType name="LAMessage"> <xs:all> <xs : element name="clientID" type="GUID"/> <xs : element name="creationTime" type="xs : dateTime" /> </xs :all> </xs: complexType> <xs : complexType name="RequestMessage" > <xs : complexContent> <xs : extension base="LAMessage"> <xs :all> <xs:element name="clientSeqno" type="xs : long"/> <xs : element name= "partnerlD" type="GUID"/> <xs: element name=" locale" type= "Locale "/> </xs :all> </xs : extension> </xs : complexContent> </xs : complexType> <xs : complexType name= "HelloReq" > <xs : complexContent> <xs : extension base="RequestMessage"> <xs : all> <xs : element name=" clientType" type= " ClientType " /> <xs : element name="auctionlD" type="GUID"/> <xs : element name="userID" type="GUID"/> </xs :all> </xs :extension> </:- s : complexContent> </xs : complexType> <xs : complexType name="GoodbyeReq"> <xs : complexContent> <xs :extension base="RequestMessage"/> </:xs : complexContent> </xs : complexType> ocs : complexType name="ChatReq" > <xs : complexContent> <xs : extension base="RequestMessage"> <xs :all> <xs:element name="chatRecord" type= "ChatRecord" /> </xs : all> </xs : extension> </xs : complexContent> </xs : complexType> <x:s : complexType name="BidReq"> <xs : complexContent> <xs : extension base= "RequestMessage " > <xs : sequence> <xs : element name="bidRecord" type="BidRecord" maxOccurs= "unbounded" /> </xs : sequence> </xs : extension> </xs : complexContent> </xs :complexType> <xs : complexType name="ResponseMessage"> <xs : complexContent> <xs : extension base="LAMessage"> <xs : all> <xs:element name="serverSeqno" type="xs : long"/> </xs :all> </xs : extension> </xs : complexContent> </xs : complexType> <xs : complexType name="AuctionChangedResp" > <xs : complexContent> <xs : extension base="ResponseMessage" > <xs :all> <xs : element name="auctionHeader"/> </xs:all> </xs : extension> </xs : complexContent> </xs : complexType> ocs : complexType name="BidRejectedResp"> <xs : complexContent> <xs : extension base="ResponseMessage"> <xs :all> <xs : element name="auctionlD" type="GUID"/> <xs : element name="auctionItemID" type="GUID"/> <xs : element name="reasonCode" type= "ReasonCode" /> </xs : all> </xs : extension> </xs : complexContent> </xs : complexType> <xs : complexType name="ChatResp"> <xs : complexContent> <xs : extension base="ResponseMessage"> <xs :all> <xs:element name="chatRecord" type="ChatRecord"/> </xs:all> </xs : extension> </xs : complexContent> </xs : complexType> <xs : complexType name= "NewBidResp"> <xs : complexContent> <xs : extension base="ResponseMessage"> <xs : all> <xs : element name="bidUpdate" type="BidUpdate"/> </xs :all> </xs : extension> </xs : complexContent> </xs : complexType> <xs : complexType name="TerminatedResp"> <xs : complexContent> <xs :extension base="ResponseMessage"> <xs :all> <xs : element name="reasonCode" type="ReasonCode"/> </xs :all> </xs : extension> </xs : complexContent> </xs : complexType> <xs : complexType name="UserChangedResp" > <xs : complexContent> <xs : extension base="ResponseMessage"> <xs : all> <xs : element name="participant " type= "AuctionParticipant " /> </xs :all> </xs :extension> </xs : complexContent> </xs : complexType> <xs : complexType name= "WelcomeResp"> <xs : complexContent> <xs : extension base="ResponseMessage"> <xs :all> <xs : element name="clientID" type="GUID"/> <xs:element name= "partnerlD" type="GUID"/> <xs : element name="auctionDetails" type= "AuctionDetails" /> </xs : all> </xs : extension> </xs : complexContent> </xs : complexType> <xs : complexType name="RequestEnvelope" > <xs : all> <xs:element name="transmit_time" type="PreciseDateTime" > <xs : annotation> <xs : documentation>Time request sent by client</xs :documentation> </xs : annotation> </xs : element> <xs : element name="clientID" type="GUID"/> <xs:element name="userID" type="xs : string"/> <xs : element name=" locale" type="Locale"/> <xs : element name="serverSeqno" type="xs : long"/> <xs : element name="sapClient " type="xs : string" /> <xs : element name="requests"> <xs : complexType> <xs : sequence> <xs : choice minOccurs=" 0" maxOccurs= "unbounded" > <xs:element name="bidReq" type="BidReq"/> <xs : element name="chatReq" type= "ChatReq" /> <xs : element name="helloReq" type= "HelloReq" /> <xs : element name="goodbyeReq" type= "GoodbyeReq" / > </xs : choice> </xs : sequence> </xs : complexType> </xs : element> </xs : all> </xs : complexType> <xs : complexType name= "ResponseEnvelope"> <xs : all> <xs : element name= "originateTimestamp" type= " PreciseDateTime " > <xs : annotation> <xs :documentation>Time request sent by client</xs : documentation> </xs : annotation> </xs :element> <xs : element name="receiveTimestamp" type= " PreciseDateTime" > <xs : annotation> <xs :documentation>Time request received by server</xs : documentation> </xs : annotation> </xs : element> <xs : element name="clientID" type="GUID"/> <xs:element name="transmitTimestamp" type= "PreciseDateTime " > <xs : annotation> <xs :documentation>Time response sent by server</xs : documentation> </xs :annotation> </xs :element> <xs : element name="responses "> <xs : complexType> <xs :sequence> <xs : choice minOccurs="0" maxOccurs= "unbounded" > <xs : element name="auctionChangedResp" type="AuctionChangedResp"/> <xs : element name="bidRej ectedResp" type="BidRejectedResp"/> <xs : element name="chatResp" type="ChatResp"/> <xs : element name="newBidResp" type= "NewBidResp" /> <xs: element name="terminatedResp" type= "TerminatedResp" /> <xs : element name="UserChangedResp" type= "UserChangedResp" /> <xs : element name="welcomeResp" type= "WelcomeRes "/> </xs : choice> </xs : sequence> </xs : complexType> </xs :element> </xs:all> </xs : complexType> </xs : schema>

Claims

CLAIMS 1. An auction system comprising: an auction engine to manage an auction between a plurality of clients; a storage device to store a list of clients participating in the auction, and, for each of said participating clients, a log of auction data sent to said participating client; and a connector to provide an interface between the auction engine and the plurality of clients, the connector operative to generate and send an update XML message to a participating client in response to an update request, said update XML message including a selected portion of available auction data for the participating client based on the log of auction data corresponding to the participating client.

2. The system of claim 1, wherein the update XML message comprises one or more message types conesponding to a live auction XML schema.

3. The system of claim 1 , wherein the update XML message includes an auction header including said selected portion of available auction data.

4. The system of claim 1, wherein the connector is operative to send a participating client an XML message including data corresponding to a bid received from said client.

5. The system of claim 4, wherein said data corresponding to the bid comprises a reason for rejection of the bid.

6. The system of claim 4, wherein the data corresponding to the bid comprises a new rank for said client.

7. The system of claim 1, wherein the connector is operative to send an XML message including chat data.

8. The system of claim 1, wherein the connector is operative to send an XML message to a participating client including data operative to terminate said client's participation in the auction.

9. The system of claim 8, wherein the connector is operative to send said XML message in response to not receiving an update request from said client within a timeout period.

10. An auction system comprising: means for managing an auction between a plurality of clients; means for storing a list of clients participating in the auction; means for storing a log of auction data sent to each of said participating clients; and a connector including means for providing an interface between the means for managing the auction and the plurality of clients, means for generating and sending an update XML message to a participating client in response to an update request, said update XML message including a selected portion of available auction data for the participating client based on the log of auction data corresponding to the participating client.

11. The system of claim 10, wherein the update XML message comprises one or more message types corresponding to a live auction XML schema.

12. The system of claim 10, wherein the update XML message includes an auction header including said selected portion of available auction data.

13. The system of claim 10, wherein the connector includes means for sending a participating client an XML message including data conesponding to a bid received from said client.

14. The system of claim 13 , wherein said data corresponding to the bid comprises a reason for rejection of the bid.

15. The system of claim 13 , wherein the data corresponding to the bid comprises a new rank for said client.

16. The system of claim 10, wherein the connector is operative to send an XML message including chat data.

17. The system of claim 10, wherein the connector includes means for sending send an XML message to a participating client including data operative to terminate said client's participation in the auction.

18. The system of claim 17, wherein the connector is operative to send said XML message in response to not receiving an update request from said client within a timeout period.