Technical Field

[0001] The present invention relates to an electronic auction system and process for use in the control of auctions, particularly webcasts of auctions, conducted by an auctioneer.

Background

[0002] An electronic auction system (EAS) is a computer-based platform which facilitates the undertaking of an auction for an item (also referred to as a "lot"), where the auction involves offering the item for bid by any of a number of individuals, taking bids on the item, and then selling the item to the highest bidding individual. These systems are often used to allow individuals to observe, and/or submit, bids during the auction procedure (referred to as "participating" in the auction) via the use of an electronic device (e.g. a computer, mobile phone, or other electronic peripheral). Electronic auction systems are often deployed for the purpose of allowing individuals that are located remotely to the physical auction environment to participate in the auction via the exchange of data over communication networks. For example, wide area networks, such as the Internet, are often used to connect one or more of the participants' electronic devices to a base, or server, device which performs the auction management operations. Electronic auction systems are advantageous in improving the accessibility of the auctioning procedure, resulting in a wider range of potential purchasers and thereby offering increased value to the vendor.

[0003] Systems in which some individuals participate in the auction remotely via the Internet are often referred to as webcast (or "simulcast") systems. Even in situations where participants are located in the physical auction environment, the use of an EAS may increase the security and integrity of the auctioning process. Conventional electronic auctioning systems track parameters associated with the auctioning of an item, including, for example, the current bid, the participant who placed the current bid, and the history of bids made throughout the auctioning process. This is referred to as the "state" of the auction, as maintained by the EAS.

[0004] An auctioneer is often employed by the vendor to facilitate the auctioning procedure for the particular item(s) being auctioned. The presence of an auctioneer is particularly beneficial where at least some of the participants are physically located at a common physical venue (referred to as the "auction environment"). To fulfil their role, the auctioneer speaks to the participants continuously throughout the auctioning process, providing a verbal indication of the current bid and the acceptance of a bid placed by a participant. The auctioneer's oration may also be for the purpose of soliciting further bids and informing the participants of events related to the auction process (e.g. when the auction commences for bidding, and when the item is sold or passed-in). Participants may respond by placing bids for the auctioned item. When the bid of a participant is accepted (as called by the auctioneer) the state of the auction is updated. This preserves the integrity of the auction, and also allows the EAS to confirm the state of the auction to all participants (irrespective of whether they are in the physical auction environment) in real-time.

[0005] Despite the convenience of these technologies, there remains room for improvement. It is desired to provide an electronic auction system and process that alleviate one or more difficulties of the prior art, or to at least provide a useful alternative.

Summary

[0006] In accordance with some embodiments of the present invention, there is provided an electronic auction process for conducting an auction of a lot, the process including: generating speech signal data representing speech of an auctioneer of the auction; processing the speech signal data to generate auction command data representing one or more commands spoken by the auctioneer in relation to the auction, each command being one of: an indication of the acceptance of a bid for the lot; and an instruction in relation to conducting the auction; and processing the generated auction command data to update auction state data representing the state of the auction; and generating auction interface data representing an interactive control panel interface that, when rendered on a display of a computing device, provides, at least, a visual representation of the current state of the auction.

[0007] In some embodiments, processing the speech signal data involves performing automatic speech recognition (ASR) to produce text stream data representing a corresponding textual transcription of the speech of the auctioneer. [0008] In some embodiments, the generation of the auction command data involves processing the text stream data to perform: i) phrase recognition, involving the determination of one or more phrases from the speech of the auctioneer, each phrase corresponding to one or more words of the textual transcription; and ii) command identification, involving the parsing of each phrase to determine whether the phrase represents at least one command spoken by the auctioneer.

[0009] In some embodiments, command identification involves performing pattern matching on a determined phrase using one or more auction command patterns.

[0010] In some embodiments, the auction command patterns include one or more regular expression patterns, and where performing pattern matching involves determining whether particular symbols of one or more of the regular expression patterns match to one or more elements of the corresponding determined phrase.

[0011] In some embodiments, the auction command patterns are specified by one or more auctioneer specific command models obtained by performing supervised learning on training speech data of the auctioneer.

[0012] In some embodiments, processing the generated auction command data involves executing a command identified from the auction command data, the execution being conditional on a verification of the command in the context of the current state of the auction.

[0013] In some embodiments, if the identified auction command is an indication of the acceptance of a bid, the verification of the command involves comparing a value of the indicated accepted bid with an asking price for the lot, wherein the asking price is: set to the current top bid value plus a bidding increment value, when one or more bids have been previously accepted; or determined based on a reserve price of the lot, when no bids have been previously accepted.

[0014] In some embodiments, the processing of the generated auction command data involves analysing one or more of the identified commands to determine whether a current state of the auction, as represented by the auction state data, is correct.

[0015] In some embodiments, the analysis includes: determining a number of the current lot on offer; and comparing the number of the current lot on offer to a current lot number of the auction state data.

[0016] In some embodiments, the analysis includes: determining a current top bid price; and comparing the current top bid price to a top bid price of the auction state data. [0017] In some embodiments, the analysis includes: determining a live state of the top bid as a "live" bid or an "Internet" bid; and comparing the live state of the top bid with a corresponding live state of the top bid of the auction state data.

[0018] In some embodiments, on determining that the current auction state is incorrect as a result of the analysis, the current auction state is corrected via the automatic generation and execution of auction state correction data by an auction logic unit.

[0019] In some embodiments, the auction interface data provides functionality allowing the auction state data to be modified in response to user input to the control panel interface, wherein the functionality of the control panel interface is determined dynamically based on the auction state data.

[0020] In some embodiments, the functionality is provided by one or more interactive graphical user interface elements that are configured to receive input from a user of the device.

[0021] In some embodiments, in response to receiving user input by the interactive graphical user interface elements, a control panel unit generates input command data representing the issuance of one or more input commands by the user; and processing, at the auction logic unit, the one or more input commands to cause the state of the auction to be updated without the processing of a corresponding auction command.

[0022] In some embodiments, the one or more interactive graphical user interface elements are a plurality of selectively enabled buttons, where each button element has associated element parameter data describing a set of parameters of the element, including: the position of the element in a display area of the panel; an activity state of the element; a command associated with the element; and a corresponding value of the command.

[0023] In some embodiments, the element parameter data of particular ones of the interactive button elements is dynamically adapted based on the auction state data updated by the auction logic unit.

[0024] In some embodiments, the interactive graphical user interface elements facilitate the issuing of one or more input commands to update the state of the auction in a manner that is most likely to be desired based on the current auction state.

[0025] In accordance with some embodiments of the present invention, there is provided an electronic auction system, including an electronic auction device having : a speech control unit configured to: generate speech signal data representing speech of an auctioneer of an auction of a lot; process the speech signal data to generate auction command data representing one or more commands spoken by the auctioneer in relation to the auction, each command being one of: an indication of the acceptance of a bid for the lot; and an instruction in relation to conducting the auction; an auction logic unit configured to: process the generated auction command data to update auction state data representing the state of the auction; and a control panel unit configured to: generate auction interface data representing an interactive control interface that, when rendered on a display of a computing device, provides, at least, a visual representation of the current state of the auction.

[0026] In some embodiments, the electronic auction system further includes: a database configured to store data in relation to participants, auctioneers, and users of the system; and an auction control unit device connected to the database, and to the electronic auction device via a communications network, and wherein the electronic auction device has at least one network interface configured to transmit data to the communications network, and where the auction logic unit is configured to transmit the updated auction state data to the auction control unit device via the communications network.

[0027] In some embodiments, the auction control unit device is connected to a plurality of participant devices, each device corresponding to a respective participant of the auction for the lot, and wherein at least one network interface of the electronic auction device is configured to receive data from the communications network, and where the auction logic unit is configured to receive, via the communications network, an indication of a bid by any one of the plurality of participants.

[0028] In some embodiments, the electronic auction device is configured to execute any of the electronic auction processes described herein above.

[0029] In accordance with some embodiments of the present invention, there is provided a computer-readable storage medium having stored thereon instructions that, when executed by at least one processor of a computing system, cause the at least one processor to execute any of the electronic auction processes described herein above.

Brief Description of the Drawings

[0030] Some embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:

Figure 1 is a block diagram of an electronic auction system in accordance with some embodiments of the present invention;

Figure 2 is a block diagram of a computing device within the electronic auction system;

Figure 3 is a flow diagram of an electronic auction process in accordance with some embodiments of the present invention;

Figure 4a is a flow diagram of an auction command data generation process of the electronic auction process of Figure 3;

Figure 4b is a screenshot of a textual speech transcription produced by the speech control unit of the electronic auction system of Figure 1;

Figure 5a is a flow diagram of an auction command identification process of the auction command data generation process of Figure 4;

Figure 5b is a table showing an exemplary pattern matching sub-process performing during the auction command identification process of Figure 5a;

Figure 6 is a flow diagram of a process for updating the state of an auction of the electronic auction process of Figure 5a;

Figure 7 is a flow diagram of a process for generating auction interface data of the electronic auction process of Figure 3;

Figure 8 is a screenshot of an auction control panel configured in a starting configuration in accordance with some aspects of the present invention;

Figure 9 is a screenshot of an auction control panel configured in a first bidding configuration in accordance with some aspects of the present invention;

Figure 10 is a screenshot of an auction control panel configured in a second bidding configuration in accordance with some aspects of the present invention;

Figure 11 is a screenshot of an auction control panel configured in a sale configuration in accordance with some aspects of the present invention; and Figure 12 is a transition state depiction illustrating the transitions between the starting, bidding and sale configurations of an auction control panel in accordance with some aspects of the present invention.

Detailed Description

Overview

[0031] With current electronic auction systems, to maintain an accurate representation of the state of the auction, the systems typically require the auctioneer (or another designated person, such as a webcaster) to manually indicate the acceptance of bids and the issuance of auction process instructions. For example, during a traditional auction webcast the webcaster (or auctioneer) enters all the bids called into the system directly, and in doing so distinguishes bids from the auction floor (i.e. from participants in the physical auction environment), from bids placed from remote participants. This is achieved by the use of an auctioning interface to the electronic system. For example, if the auctioneer called a bid of first $100 and then $120, the auctioneer/webcaster would click a button to increase the current bid by $20. This information is then passed on to any remotely located participants (e.g. by transmission of the auctioneer's speech and/or the auction state information to the participant devices).

[0032] A drawback to the conventional approach described above is that electronic auctioning systems are often complex, and the proper operation of such systems by the auctioneer or webcaster is often difficult in a live auction situation, particularly during a fast paced auction. That is, the requirement of manually entering all bid and instruction information is difficult to satisfy when the auctioneer must also focus on their primary duty of facilitating the auction. This is particularly significant during the auctioning of high-value items, such as real estate properties where it is desirable for the auctioneer to focus on attempting to obtain the largest possible bids. Furthermore, conventional auction interfaces are designed to present the auctioneer with a large number of elements representing changes that can be made to the state of the auction. Auctioneers are likely to find these interfaces to be overly complex, particularly when concentrating on their oration, leading to a high incidence of errors (e.g. entry of an incorrect bid value) when manually operating the interface. Furthermore, an auction is often a fast- paced and high-stress environment involving continuous speech from the auctioneer. Consequently, a webcaster operating the auction system may be too slow at times (e.g., resulting in bids being missed), may misinterpret the auctioneer's speech, and/or may incorrectly enter the auctioneer's instructions.

[0033] The described embodiments of the present invention include an electronic auction system (EAS) and process which manages and tracks the auctioning of items by processing the speech of the auctioneer, and controlling a unique webcast interface or control panel. This allows the system to automatically update the state of the auction for an item without requiring the manual entry of bid or instruction information into the system by an auctioneer (or other designated person). Specifically, a speech control unit of the system generates and processes speech signal data, representing the auctioneer's speech during the auction, in real-time to determine particular auction commands (i.e. as spoken by the auctioneer) which are relevant to the auctioning process. In the described embodiments, auction commands can include: accepting a bid for the item (e.g. "calling" a bid), and issuing an instruction in relation to the auction process (e.g. opening, closing, or passing-in the lot). The auction commands determined from the auctioneer's speech are processed by an auction logic unit to update action state data representing the state of the auction for the lot.

[0034] The auction logic unit generates auction interface data representing an interactive control interface (e.g., in the form of a control panel) of the system. When rendered on a display of a computing device of the system, the control panel provides, at least, indicates a visual representation of the current state of the auction. In some embodiments, the control panel provides functionality allowing the auction state data to be modified in response to user input to the panel. The functionality of the control panel is determined based on the current state of the auction, and is updated by the auction logic unit via the generation of the auction interface data. In such embodiments, the ability of a user to issue commands through direct interaction with a control panel is adapted dynamically based on the automated issuance (i.e., recognition and execution) of auction commands from the live speech of the auctioneer. This provides an intuitive and efficient means for the auctioneer (or webcaster) to: i) observe the state of the auction; ii) correct errors made by the speech processing operations; and iii) issue an auction command manually (e.g., without relying on speech recognition, such as to improve system responsiveness in particularly fast-paced auctions), all in real-time during the auction.

[0035] Existing systems process the speech of the auctioneer only for the purpose of performing speech-to-text conversion (e.g. in order to provide a transcription of the auctioneer's speech to remote participants), or to determine particular properties of the item (e.g. a starting price). However, the presented EAS is configured to perform continuous real-time processing of the auctioneer's speech, involving both speech recognition and semantic processing of recognised phrases, such that the automatic identification and execution of auction commands uttered by the auctioneer drives the auctioning procedure.

[0036] In the described embodiments, the EAS is implemented over one or more computing devices collectively configured to execute an electronic auctioning program. Processing of the auctioneer's speech is performed by a speech control unit which receives captured speech signal data, and processes this data to produce speech stream data representing a series of words uttered by the auctioneer during the auction. In the described embodiments, the speech stream data represents a text stream of the transcribed words uttered by the auctioneer (referred to as "text steam data" herein). Transcription is performed by a speech recognition engine or other language processing module.

[0037] Auction commands are determined from the transcribed text according to two sub-process, including: i) phrase recognition, where one or more words of the text stream data are grouped into distinct phrases; and ii) command identification, where each recognised phrase is analysed to determine whether it corresponds to a known auction command (i.e. accepting a bid, issuing a control instruction, or correcting an error in the described embodiments). The command identification sub-process involves: a scanning stage, in which groups of words are determined to together represent particular phrase elements (e.g. an amount of money, referred to as a "bid amount" element); and a pattern matching stage in which matching is performed to determine the auction command based on the determined elements.

[0038] In the described embodiments, each auction command can be: a bid command, which specifies that a bid is to be taken from a participant; an instruction command representing an instruction to control the auctioning process (e.g. giving a first, second or final call); or a miscellaneous command, such as commands which make corrections to the state of the auction as maintained by the system.

[0039] In some embodiments, the phrase recognition and/or command identification sub-processes utilise auctioneer specific data. For example, a set of command models may be maintained for each auctioneer enrolled in the EAS, where the models are constructed according to a supervised training process and specify a set of patterns which map to respective auction commands for the auctioneer. In some embodiments, the auctioneer specific command models are obtained via the use of classifiers, such as neural networks, which are trained for each auctioneer by sampling the auctioneer's speech and tagging the phrases which correspond to particular commands (e.g. the phrase "we have two hundred and fifty now" is tagged as a bid command, with a value of '250').

[0040] In the described embodiments, command identification is performed using a set of global (i.e. non-auctioneer specific) regular expression patterns. For example, the regular expression "$ is bid" can be applied to each phrase to identify bid commands, where "$" represents a determined bid amount element. In further embodiments, auctioneer specific modeling may be used in combination with global expression patterns to extract phrases and identify commands from the text stream data. For example, the particular regular expression patterns applied to identify commands may be determined according to auctioneer specific data. Alternatively, each expression may be weighted such that a match resulting from applying the pattern to the phrase is probabilistically scored, with the command determined based on the highest scoring pattern.

[0041] In the described embodiments, the auction state data maintained by the EAS includes: the number of the lot currently on offer; the reserve price of the lot if applicable; a list of bids placed for the lot; the asking price, being the price the auctioneer would like to take the next bid at (i.e. the price the next bid should be); and the current bid increment. If there have been no bids, the asking price is usually a value that the auctioneer wants to start the bidding at. The current bid increment is normally the difference between the current top bid and the asking price. The speech control unit determines auction commands based, in part, on the current state of the auction (as represented by the auction state data). For example, if the auctioneer says several words that match a command then there is an extremely high probability that they are giving that command. If the auctioneer only mentions the bid amount and nothing else, but the amount is the same as the asking price then it's highly likely to be a bid. If amount is close to the asking price then it is also very likely that it is a bid.

[0042] In some embodiments, the auction state data also includes a record of previous bids accepted for the item during the history of the auction. Prior to the execution of an identified bid command, the EAS compares the bid value to at least N- previous bid values recorded as part of the state data. For example, in some cases the auctioneer will call the asking price. Conventional speech recognition may be prone to mistaking the auctioneer asking for a bid with the auctioneer actually taking a bid (human webcasters also often make this mistake). Another potential mistake of a speech recognition process applied to the auctioneer's speech is to not recognize a bid. However, the speech control unit is configured to take into account that auctioneers often repeat the current bid price over and over again. Therefore, if the auctioneer is stating that the bid is just higher or just lower than the bid price recorded in the EAS, the EAS will automatically correct itself and add or remove a bid as required. This functionality assists in protecting the system against errors in the speech recognition process (e.g. due to noise or inherent inaccuracies in the recogniser).

[0043] In the described embodiments, the execution of an identified command is performed contextually based on the state of the auction for the item. A probabilistic verification process is used to check whether the identified command is valid based on its value and the current state of the auction. For example, if the identified command is a bid command, then its value is compared to an asking price for the lot, where the asking price is determined from the current state of the auction. In cases where one or more bids have been previously accepted, the asking price is the current top bid value plus a bidding increment value. However, when no bids have been previously accepted, the asking price is determined based on the reserve price of the lot.

[0044] The EAS is configured to generate a user interface, in the form of an auction control panel, configured for use by a user of the system, which may include the auctioneer, a webcaster, and/or any other designated person. The auction control panel rendered on a graphical display of an electronic device with and is configured to display, at least, the state of the auction to the user. In some embodiments, one part of the display provides feedback to the user by displaying a textual transcription of the phrases spoken by the auctioneer. The display shows the text output by the speech recognition system. When the user is the auctioneer, this allows the auctioneer to adapt their speech based on the visual feedback to achieve improved system performance (i.e. to prevent errors). For example, if the speech control system is consistently missing bids, the auctioneer may review the text stream and observe that when they say "three fifty dollars" the system displays "three" and "$50". In response, the auctioneer can adapt their speech to instead say "three hundred and fifty dollars" to assist the speech control unit with properly identifying and interpreting the command (i.e. accepting a bid with value '350'). Alternatively, if the speech control unit is not properly recognising phrases (e.g. where the text stream display shows very long phrases), the auctioneer may adapt their speech to pause briefly every now and then.

[0045] The auction control panel also includes interactive graphical user interface elements that are configured to receive input from the user of the device. These user interface elements allow the manual entry of bids and instructions into the EAS by the user. This allows an auctioneer, webcaster, or other designated person, to correct the state of the auction in the event that an error occurs in the speech recognition, phrase recognition or command identification processes.

[0046] The particular user interface elements of the auction control panel are configured to facilitate easy use of the EAS by the auctioneer. Specifically, unlike existing electronic auction systems, the functionality provided by the auction control panel is dynamic and changes based on the state of the auction. For example, in some embodiments, the panel provides a simplified webcasting interface which includes a set of user operable elements (e.g. buttons) that can be configured to represent particular commands, and where each element can be conditionally toggled between 'active and 'non-active' states. That is, the configuration of the elements changes based on a determination of the most likely operations that the auctioneer (or webcaster) would need to perform at the current stage of the auction. This dynamic display mechanism results in fewer elements displayed at any given time on the panel, and therefore simplifies its use by the auctioneer (or other designated person).

System

[0047] As shown in Figure 1, an EAS 900 includes a speech control unit 910, an auction logic unit 904, an auction control panel unit 940, an auction control unit 920, a database 905, participant devices 951-95N, and communications networks 950, 960. The speech control unit 910, auction logic unit 904 and auction control panel 940 are implemented within one or more computing devices, such as the electronic auction device 902 of the described embodiments. The speech control unit 910 is configured to perform operations associated with the processing of the speech of a user 901 (e.g. an auctioneer) to identify and generate auction commands representing an indication of the acceptance of a bid for the item, or an instruction in relation to conducting the auction (as described herein below).

[0048] The auction logic unit 904 is configured to manage information in relation to the auctioning of a particular items by the EAS (referred to herein as the "current lot"), including storing auction state data representing the state of an auction for a lot, and updating this information dynamically as the auction proceeds.

[0049] Processing of the auctioneer's speech is performed by sub-modules of the speech control unit 910, including a speech recogniser engine 912, a text stream output buffer 914, a phrase parser 916 and a command matcher 915. The auction logic unit 904 includes a command execution controller 932 and an auction state controller 934 that are collectively configured to: receive command data, such as auction command data generated by the speech control unit 910, and input command data generated by the control panel unit 940; execute corresponding auction commands of the received data to update the state of the auction; and transmit the updated auction state data to the auction control unit 920. The auction state controller 934 maintains an indication of the present state of the auction (i.e. by storing values for a set of parameters describing the auction state data, as discussed above). The command execution controller 932 is in communication with the auction state controller 934, and with each of the speech control unit 910 and auction control panel 940. The Command Execution Controller 932 executes the received command data to update the auction state data as maintained by the Auction State Controller 934. The updated auction state data is fed back into the Speech Control Unit 910 and the Auction Control Panel 940 by the Command Execution Controller 932 to assist the command generation processes (as described herein).

[0050] The auction control unit 920 is a control entity which facilitates the auction process by storing and managing data in relation to bidders ("participants"), auctioneers, and users of the system 900. In the described embodiments, the auction control unit 920 is a software module executed on one or more computing devices that are separate from the electronic auction device 902 (e.g., devices at a remote location, such as in an Internet server colocation facility). The Auction Control Unit 920 has sub- modules including a Catalogue Manager 922 which loads and maintains the auction catalogue (i.e. data representing particular information about each lot). The auction catalogue data includes: a description of the lot; an indication of the location of any photos of the lot; data indicating estimates of what the lot may sell for; and a reserve price if applicable. The catalogue manager 922 records all the sales results of all lots that have been auctioned, and the reserve prices and starting prices of all the lots that have not been auctioned yet (but that have been entered into the system).

[0051] The unit 920 also includes a Bids Manager 924 which is configured to handle the bids from the auction participants. The bid manager 924 processes bids received from participant devices 951-95N and passes them on to the electronic auction device 902 provided that the bid satisfies particular checks (e.g., the bid amount being high enough). The Participants Manager 926 maintains the connections to each of the online participants and corresponding data indicating information about the participant (e.g., IP address, bidding history, and any account registration details if applicable), in order to determine: who has logged into the system 900; and who is allowed to bid in a particular auction. The manager 926 sends the participants messages when they have been outbid or when a lot they have left a bid on comes up.

[0052] The auction control panel 940 is configured to transmit information to, and receive input from, the user 931 and includes an Auctioneer Display Panel 944 and a Command Instruction Module 942. The Command Instruction Module 942 processes the auction state data received from the command execution controller 932 and generates auction interface data representing an interactive control interface that, when rendered on a display of the device 902 (such as auctioneer panel 944), provides at least a visual representation of the state of the auction (e.g. that indicates the state of the auction process as represented by the EAS 900), and, as discussed below for some embodiments, allows the user to exercise manual control over this process.

[0053] The user 931 watches the Auctioneer's Display Panel 944 and issues commands ("input commands") by interacting with one or more interactive graphical user interface elements that, when rendered on the display of the device 902, are configured to receive input from the user 931 (e.g., by clicking on buttons on the Auctioneer's Display Panel 944). Specifically, the elements of the auctioneer display panel 944 provide functionality allowing the generation of input command data representing the issuance of one or more input commands by user 931. The input commands are processed by the Command Execution Controller 932 to cause the state of the auction to be updated without the processing of a corresponding auction command (i.e., as generated by the speech control unit). That is, the auctioneer display panel 944 provides a means for the user 931 to interact with the EAS 900 such that they can exercise manual control over the auction (as opposed to relying solely on the operation of the speech control unit 910).

[0054] The auction control panel unit 940 is configured to generate auction interface data based on auction state data provided by the Command Execution Controller 932. Consequently, the functionality provided to a user 931 by the auctioneer display panel 944 is adapted dynamically in response to the command data (i.e. representing generated auction commands and/or input commands) received by the auction logic unit 904.

[0055] In the described embodiments, the auction control unit 920 is coupled to a database 905, including a Bidders 906 table, a user table 907, an auctioneer table 908 and a command table 909. The Bidders table 906 stores data about each registered bidder. Individuals intending to bid in auctions conducted by the EAS 900 need to register with the system and be accepted before the auction. The personal information of each bidder is stored in the bidders table 906, including the maximum amount they are allowed to purchase at the auction.

[0056] The database 905 is implemented on one or more computing devices that are distinct from the device 902 in the described embodiments. For example, the database 905 may be implemented across the one or more remote computing devices implementing auction control unit 920. In some embodiments, the tables 907, 908 and 909 are accessed via a database management system (DBMS) of the electronic auction device 902. Access is achieved via communication over communications network 960. The DBMS uses SQL language to query the database, which is implemented as a relational database in the described embodiments. The skilled addressee will appreciate that, in other embodiments, the system 900 may implement a different organisation and/or structure for the database and the corresponding database tables, to that described below.

[0057] The user table 907 stores data representing the users of the EAS 900, such as one or more auctioneers, webcasters, and/or other designated persons. In the described embodiments, each entry in the user table 907 represents a user of the system 900 by: a user identifier uniquely identifying the user among all users registered with the system; a username and corresponding password used to authenticate the user (i.e. as may be used to control access to the system); a first name of the user; a last name of the user. In some embodiments, the table 907 may also record a description of other relevant information in relation to the user, such as an indication of their role (e.g. "auctioneer", "webcaster", etc.).

[0058] The auctioneer table 908 is configured to store speaker specific phrase recognition and/or command identification data for each auctioneer (i.e. to assist in the processing of the speech of the auctioneer). In some embodiments, the auctioneer specific data is in the form of parameters for speech models that are used in the phrase recognition process, and/or a set of auctioneer specific command patterns used in the command identification process, as described herein below. The phrase and/or command data for a particular auctioneer may be included over multiple records within the auctioneer table 908. For example, an individual auctioneer may have distinct speaker specific speech models which are utilised by the system during phrase recognition, and a set of regular expression patterns for bid, instruction and/or other command types which are retrieved during the command identification process (as described below). [0059] In other embodiments, speaker specific model data (e.g. phrase and/or command data for each auctioneer the system 900) may be stored in a separate table within the database 905, and/or may be provided to the speech control unit 910 by an external source.

[0060] The command table 909 stores data representing the one or more commands that may be issued by the auctioneer in relation to an auction conducted using the EAS 900. In the described embodiments, each entry in the command table 909 specifies parameters including: a command type; a command descriptor; and a list of parameters for any global classifier models and/or regular expression patterns used to identify the command from a recognised phrase. For example, a command corresponding to an indication of the acceptance of a bid for the item may be represented by an entry with a command type of 'bid', a descriptor of 'Accepting a new bid', and a list of regular expressions used to identify the command, including: '<"$ is bid", "bid is now at "we have a bid of $">'. The '$' character is a symbol designating a currency value, as described herein below. The descriptor field may be used to distinguish between commands corresponding to instructions in relation to conducting the auction. In other embodiments, some or all of the auctioneer specific phrase data are represented as a list of patterns and corresponding actions which are stored directly in the Command Matcher 915.

[0061] In the described embodiments, each pattern is stored as a record with the command type, the command name, and a number of tokens (typically between 1 and 6). The Command type is one of:

• lotPattern: for matching the lot number.

• buyerPattern: for recording the buyers number.

• commandPattern: For issuing verbal corrections like delete the top bid.

• askPattern: For the auctioneer asking for a specific bid price.

• netPattern: To match when the auctioneer takes a bid from the Internet

• livePattern: For taking a bid from someone present at the auction.

• incrementPattern: For the auctioneer asking for a different bidding increment.

• callPattern: Matches the auctioneer making a first, second or final call.

• soldPattern: To match the auctioneer selling or passing in the lot.

[0062] The command name is of a string type. Some command types only have a single command name, such as all patterns for taking a live bid have a command type of livePattern and a command name of "live". Some command types have multiple different command names, such as the patterns for the auctioneer making a call. They all have the command type of callPatern but have three different command names "first", "second" and "final'.

[0063] The tokens are of a string type. Most tokens are simply the word they represent in lowercase letters. As described above, the special tokens include "$", which matches any number or amount of money, and "#" which matches any number (but not amounts of money). Table 1 shows examples of command types, names, tokens, and matching which may occur based on these combinations.

Table 1: Pattern examples

[0064] The EAS 900 is operable to facilitate auctions involving live participants (i.e. participants who are located in a particular physical environment, referred to as the "auction environment", in which the auction takes place). An auctioneer 901 resides within the auction environment and speaks to the participants throughout the auction. The recogniser engine 912 of the speech control unit 910 may include a speech capturing module to capture the speech of the auctioneer 903, and to generate speech signal data for processing by the speech control unit 910. The speech capturing module is located in the auction environment, and positioned relative to the auctioneer 901 to enable the capturing of their speech 903 (e.g., by use of a microphone array or another type of audio signal recording device). Alternatively, or in addition, the speech control unit 910 can be configured to receive speech signal data representing the speech of the auctioneer 901 from an external source (e.g. a third-party speech capturing system).

[0065] In some embodiments, the EAS 900 is configured to facilitate an "online" auction where one or more of the participants are not physically present at the auction environment. The electronic auction device 902 communicates with a particular number N of online participants via respective devices 951-95N of each participant. The participant devices 951-951N are computing devices, such as laptops, desktops or mobile devices, such as tablets or smart phones, that are connected to the auction control unit 920 via the network 950. Communication occurs between each participant device 951-951N and the auction control unit 920 via a communications network 950, which may include one or more local area, or wide area, sub-networks.

[0066] In other embodiments, different configurations of communications networks may be used to connect the auction control unit 920, electronic auction device 902 and each participant device 951-951N. The online bidders (i.e., "participants") participate in the auction via a representation of the auction displayed by an auction program executing on their respective participant device. The representation may be in the form of textual, audio and/or video media describing the auction state (such as a live feed, or stream). For example, each participant device may receive text indicating the presently accepted bid for the item, the starting bid for the item, and a description of the item. In embodiments where the auctioneer's speech 903 is streamed to the Auction Control Unit 920, and on to the Participant Devices 951-951N, some of the speech processing functionality of the speech control unit 910 may be performed, or at least duplicated, on the one or more devices implementing the auction control unit 920.

[0067] When a bid is entered on a Participant Device 951-951N it is transmitted to the Auction Control Unit 920 and processed by the Bids Manager 924. If the bid passes the checks performed by the bids manager 924, then the bid is transmitted to the electronic auction device 902 via the communications network 960. The bid is interpreted by Auction Control Panel 940 to display a corresponding indication on the display panel 944 (e.g., via a graphical user interface element). The bid can then be taken, for example by the auctioneer issuing a spoken auction command, or by the user 931 (e.g., a webcaster) interacting with a corresponding element on the interface of the panel 944. This causes either the execution of the bid (i.e., by the generation of corresponding auction or input command data) by the Auction Control Panel 940 or the Speech Control Unit 910 respectively.

[0068] In the described embodiments of the EAS 900, the electronic auction device 902, is implemented as one or more computer systems 200, such as, for example, an Intel Architecture computer systems, as shown in Figure 2, and the processes executed by the system 200 are implemented as programming instructions of one or more software modules 202 stored on non-volatile (e.g., hard disk or solid-state drive) storage 204 associated with the computer system. Flowever, it will be apparent that at least parts of these processes could alternatively be implemented as configuration data of field programmable gate arrays (FPGAs), and/or as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs), for example. [0069] In the described embodiments, the speech control, auction logic, and auction control panel units are implemented as application program modules executing on the electronic auction device 902. However, in other embodiments the units may be implemented individually across logically separate computing devices. For example, the auction control panel unit 940 may be implemented as an application program executing on a user device of user 931. In such embodiments, the user device, and each of participant devices 951-951N, can be a computing device (such as system 200 described above), or a mobile computing device, such as, for example, a computer system having a 32- or 64-bit Advanced RISC Machine (ARM) architecture (e.g., ARMvx), which operates analogously to the standard computing system 200 depicted in Figure 2. The participant devices 951-951N execute a Javascript auction application that communicates with the auction control unit 920 securely via Secure Web Sockets through communications network 950. In some embodiments, the electronic auction device 902 can be configured as a server computing device configured to receive speech signal data from an external speech capturing system.

[0070] The system 200 includes random access memory (RAM) 206, at least one processor 208, and external interfaces 210, 212, 214, all interconnected by a bus 216. The external interfaces include universal serial bus (USB) interfaces 210, at least one of which is connected to a keyboard 218 and a pointing device such as a mouse 219, a network interface connector (NIC) 212 which connects the system 200 to a communications network, such as network 960, and a display adapter 214, which is connected to a display device such as an LCD or LED panel display 222.

[0071] The system 200 also includes a number of standard software modules 226 to 230, including an operating system 224 such as Linux or Microsoft Windows. In some implementations, the modules include web server software 226 such as Apache, available at http :/7www. a pache.org, scripting language support 228 such as PHP, available at httpi//www. php.net. or Microsoft ASP, and structured query language (SQL) support 230 such as MySQL, available from tfi _. /!. v vw, _. ET3 _. y:sQ _. l _. .com, which allows data to be stored in and retrieved from an SQL database 230. In other implementations, the system may utilise other technologies, such as HTML5, HTTPS, Java, JavaScript, Apache and Tomcat.

Process

[0072] Figure 3 illustrates the process of conducting an electronic speech-driven auction as performed by the EAS 900. At step 301, the EAS 900 is configured for use by one or more users, such as an auctioneer 901 and/or panel user 931 (as depicted in Figure 1). In some embodiments, the configuration process involves the registration of users with the EAS system 900 via the enrolment of particular registration information of each user, and the subsequent storage of this information into user table 907. The configuration step 301 also involves the initialisation of database tables 906, 907, 908, 909 with entries respectively representing information about bidders and users of the system, auctioneers for whom speech processing is to be performed, and the commands which may be identified during the speech processing. For example, the auctioneer table 908 may be initialised with data representing classifier model parameters obtained from an offline supervised training process conducted prior to the configuration step.

[0073] At step 302, the EAS 900 receives speech signal data representing the speech of an auctioneer during the auctioning of a lot. In some embodiments, the auctioneer speech 903, in the form of an analogue waveform, is captured by the speech control unit 910, or other component, of the electronic auction device 902 and is converted into a corresponding digital speech data signal. In other embodiments, this speech capturing and digitisation process may be performed by an external system and provided as input to the speech control unit 910.

[0074] At step 304, the received speech signal data is processed to generate auction command data that represents one or more commands issued (i.e. spoken) by the auctioneer 901 in relation to the auction, and where each command issued is: an indication of the acceptance of a bid for the item; or an instruction in relation to conducting the auction.

[0075] An auction command can include a command to: i) take a live bid from the auction floor; ii) take a bid from someone on the Internet; iii) ask for a specific bid; iv) set the lot number; v) change the bid increment; vi) give a first, second or final call; vii) sell, refer or pass in a lot; and viii) give the paddle number of the winning bidder. With respect to the above, (i)-(ii) are commands indicating the acceptance of a bid for the item, while (iii)-(vii) are instructions in relation to the auction. In some embodiments, the auction commands may also include other miscellaneous commands that are not bid acceptance or auction instruction commands. Miscellaneous commands can include, for example, commands to make corrections to the state of the auction, such as (viii) removing or deleting the top bid, (ix) swapping the top bid from the Internet to live or vice versa, and (x) reverting a step in the auction process.

[0076] Generation of the auction command data is performed by the speech control unit 910 according to a process described by Figure 4. At step 402, automatic speech recognition (ASR) is performed on the speech signal data representing the auctioneer speech 903. The speech signal data is processed by the speech recogniser engine 912, which is implemented as an instance of the Dragon Naturally Speaking engine (version 15) in the described embodiments. The speech recogniser engine 912 matches sounds, as represented by the digital speech signal, to parts of words in a particular designated language (i.e. English for the described configurations of the system). The speech recogniser engine 912 matches sounds to parts of words and builds these into phrases that can be parsed as English (see Jim Entwisle and Michael Groves, "A method of parsing English based on sentence form", in New methods in language processing, edited by D. B. Jones and H. Somers (UCL Press, London, 1997), pp. 269-281).

[0077] The speech recogniser engine 912 operates to convert the auctioneer speech 903 into speech stream data representing a sequence of English words uttered by the auctioneer. In the described implementation, the speech stream data is a stream of text that is output to the text stream output buffer 914 (i.e. at step 404). At step 406, the speech control unit 910 performs phrase recognition to group one or more words of the buffered text stream into a phrase.

[0078] Phrase parser module 916 performs phrase recognition based on output from the speech recogniser engine 912, and/or the text buffer 914. In the described embodiments, prosodic features, such as the presence and duration of pauses between words in the speech signal, are analysed to determine the appropriate grouping of words. For example, the phrase parser 916 may be configured to search for pauses of more than a threshold value (e.g. 0.2 seconds) and to separate the text stream into phrases based on the occurrence of such pauses.

[0079] The phrase parser 916 can be configured to utilise auctioneer specific phrase recognition models to dynamically set the prosodic feature parameters (e.g. pause length) based on the particular auctioneer who is conducting the auction. The auctioneer specific recognition model data is obtained by the speech control unit 910 from the auctioneer table 908 of the database 905, as described above.

[0080] Each recognised phrase is processed by the command matcher 915, at step 408, to identify auction commands to which the phrase corresponds. In the described embodiments, auction command identification involves: i) scanning the recognised phrases to identify groups of words within the phrase which represent particular elements of semantic significance (e.g. an amount of money); and ii) matching the contents of the phrase to one or more patterns based on the elements determined during scanning. [0081] The command matcher 915 performs pattern matching on the recognised phrases output by the phrase parser 916 using a set of regular expression patterns in the form of a sequence of one or more symbols. The symbols correspond to particular elements that can be determined from the recognised phrases. For example, symbols can be used to represent: specific words; amounts of money; and/or general numbers, as they may appear in the transcribed phrases. These symbols are represented by strings, for example where specific words are represented by themselves, amounts of money are represented by "$" and general numbers by "#". The text of the regular expression pattern string is compared to corresponding text of the recognised phrase that appears in the output text stream data (i.e. as stored in buffer 914) when the received speech data is processed. For example, '$ "is bid'" is an expression pattern for a bid acceptance command, with '$' being a symbol representing the value of the command (i.e. the bid value).

[0082] Figure 5a illustrates the command identification process 408, in which each recognised phrase is scanned for commands, and where scanning is performed in realtime as each phrase is produced (by the phrase parser 916). Scanning involves the segmentation of the phrase text to identify specific groups of one or more words which represent an amount of money, or a numerical value, and to replace these groups of words by a single token. For example, if the auctioneer says "four hundred and fifty dollars" the transcribed phrase text may correctly read "$450", but could alternatively read "400 and $50" (depending on the speech processing). In this case, the scanner will combine these three words into a single token with a value of $450.

[0083] Consider the case where the bid is at $200 and the auctioneer sees a bid for $250. Many auctioneers will not say "two hundred and fifty dollars" to indicate acceptance of a $250 bid, but will simply say "two fifty dollars". The corresponding output of the speech recognition system may be "two $50". In this case, the scanner needs to combine these two words into a token representing $250.

[0084] In another example, if the bidding is at $32,000 the auctioneer may say "thirty three" for the next bid, causing the speech recogniser to output "33" as the phrase text. In this case, the scanner will convert the numerical text to a token representing 33,000 based on the current bidding increment and the present state of the auction (i.e. the present bid value).

[0085] At step 502 the command matcher 915 performs a preliminary step of retrieving the auction command model data from the database 905. The auction command models data includes regular expression auction command patterns may be global or auctioneer specific (as described above). The availability of both global and speaker specific command identification patterns allows control to be exercised over the operation of the command matcher 915 (e.g. the identification process may be limited to global patterns where there is a scarcity of training data, or a need to minimise the amount of stored data).

[0086] Global patterns are stored in the command table 909, while auctioneer specific patterns are stored in the auctioneer table 908. Auctioneer specific pattern data is predetermined according to a training or enrolment process, and is entered into database 905 prior to the auction (e.g. during configuration 301). Model training may be conducted as a supervised learning process, either using a global dataset (i.e. consisting of a mixture of speech from multiple auctioneers) or in a speaker specific manner (i.e. where distinct auctioneer specific models are produced using respective speech samples from each auctioneer). For example, speaker (i.e. auctioneer) specific neural network models may be trained on speech signal data corresponding to auctioneer speech 903 produced during previously conducted auctions, where phrases of the speech are transcribed to identify when actual commands were issued. Regular expression patterns specific to the auctioneer can then be determined for particular bid and instruction commands.

[0087] At step 503 pattern matching is performed for each scanned phrase. Pattern matching is performed by the command matcher 915, and involves matching the contents of the scanned phrase to one or more patterns based on the elements determined during scanning. Figure 5b illustrates a pattern matching process 550 performed for the phrase "Can I have $100 anywhere". The command matcher 915 matches the phrase against each pattern in the pattern model set to determine an auction command represented by the phrase. Each line in the figure shows the result of attempting to match the phrase to one of the patterns in the set. The first symbol 572 determined in the pattern is compared to a corresponding element 562 in the phrase via an iterative process. That is, if a match is found between the first element and symbol then the next element in the phrase is compared to the next symbol in the pattern, and so on. This is repeated until the whole pattern is either matched or not.

[0088] With reference to Figure 5b, the pattern shown on the first line of the diagram starts with the word "is". This word (i.e. element) is not found in the auctioneer's phrase so the first pattern is not a match. The first symbol of the second pattern is "can" which matches the first element of the phrase. The rest of the second pattern also matches the following elements in the phrase, so there is a match for the second pattern as shown. The "$" symbol in the pattern will match any amount of money, in this case it matches with $100. The second pattern is associated with the command of the auctioneer asking for a bid of a specific amount of money.

[0089] In the described embodiments, when a match is found the text in the phrase is marked as matched and not searched again (i.e. no more matches would be found). However, consider the case where the matching process is continued. The first symbol of the third pattern is the money symbol which matches any amount of money and so matches the "$100" in the phrase. The rest of the pattern does not match the following elements of the phrase so it is not a match. The first symbol of the fourth pattern is "I" and it matches the second element of the phrase. In this case, the rest of the pattern "have" and "$" does match the following elements of the phrase and therefore the pattern is matched in the phrase. However, this pattern is a pattern for taking a bid, which is different to the command for the match with pattern two. This illustrates the importance of performing phrase element to pattern symbol matching according to the sequential order in which they appear in their respective texts, since when a pattern is matched the matched elements in the auctioneers phrase are not searched again.

[0090] When a pattern has several elements, a match to all elements indicates a very high probability of correctly identifying the actual command spoken by the auctioneer. However, auctioneers frequently take a bid by simply saying the amount of money that was bid. For example, in the ideal case an auctioneer may take three successive bids by saying "One hundred dollars is bid", "one hundred and ten dollars is bid", "one hundred and twenty dollars is bid". Unfortunately, many auctioneers simply refer to the bid amount such that the call succession may be: "one hundred dollars is bid", "one hundred and ten", "one hundred and twenty". Consequently, the command matcher 915 defines a pattern for taking a bid that has simply one element for an amount of money, the "$" element (as discussed above). This pattern is used to match any bid amount spoken by the auctioneer.

[0091] During the course of an auction, the auctioneer 901 may mention numbers, and amounts of money, for reasons other than taking a bid. Use of the simple pattern described above to produce an entirely binary command identification decision can cause errors in this case. The command matcher 915 can be configured to provide a probability of the existence of a bid command for a particular recognised phrase. The probability is determined based on the difference between the identified (i.e., matched) amount of money and the asking price of the lot (i.e., the value the auctioneer is hoping to receive for the next bid). This is depicted in the bottom line of Figure 5b, where a question mark is placed in the "Match" column indicating that the command matcher 915 identifies the command probabilistically. Since the probabilistic command identification process is based, at least in part, on the current state of the auction, updates to the auction state provided to the speech control unit 910 by the auction logic unit 904 are used as feedback to assist in improving the accuracy with which subsequent auction commands are identified by the unit 910.

[0092] In other embodiments, the pattern matching process involves scoring the scanned phrase against one or more of the retrieved auction command patterns (i.e. at step 504). In such embodiments, the extent to which the scanned phrase matches to a pattern is quantified by an identification score value that is produced by applying the pattern to the phrase.

[0093] For example, the identification score may be produced by obtaining subscores from classifying, or matching, the phrase to a plurality of models, or patterns. Thresholding may be performed (e.g. on classifier outputs) such that the identification score is binary (i.e. indicating that the phrase is either a 'match' or a 'non-match' to the model). Alternatively, the identification score can be produced as a weighted combination of a speaker specific model score and a global regular expression matching score.

[0094] At step 506, the command matcher 915 determines the appropriate auction command for the scanned phrase. In the described embodiments, the determined command auction command is the command whose pattern matches to the scanned phrase. In other embodiments where the command matcher 915 obtains a set of identification scores for the recognised and scanned phrase (i.e. in respect of multiple patterns), the auction command may be determined based on a comparison of the values in the set.

[0095] In the described embodiments, the matcher 915 is configured to identify a single auction command corresponding to the scanned phrase (i.e. being the command associated with the pattern which matched, or which produced the highest identification score of all patterns in the set). Alternatively, in other embodiments, the matcher 915 can identify a plurality of commands which correspond to the recognised and scanned phrase. For example, the matcher 915 may apply an N-best ranking process to determine the N>1 commands with the highest identification scores as the identified commands.

[0096] With reference to Figure 4a, at step 410 the command matcher 915 generates data representing each identified command (i.e. the auction command data), where the generated data includes an indication of: the command type (e.g. 'bid', 'instruction' or 'miscellaneous'); and a value of the command (e.g. '250' corresponding to accepting a bid of $250). The command value is determined during the command identification process, such as for example by performing a text-to-n umber conversion operation on the text corresponding to part of the command.

[0097] With reference to Figure 3, at step 306 the auction command data is processed by the auction logic unit 904 to update the state of the auction as maintained by the EAS 900. The update reflects a change in the state of the auction resulting from one or more commands issued by the auctioneer (i.e. where the commands are determined as described above). In the described embodiments, the processing of the auction command data involves executing one or more of the identified commands represented therein by the command execution controller 932. The command matcher 915 transmits the generated auction command data to the command execution controller 932 which performs the execution of each identified command conditionally based on a verification of the command with respect to the present state of the auction for the item.

[0098] For example, the speech recognition engine 912 may produce a text stream representing an inaccurate transcription of the auctioneer speech 903, such as by failing to recognize a number, or combining two numbers etc. This command verification process allows the command execution controller 932 to check whether an identified command is sensible in the context of the auction prior to its execution, such that mistakes in the speech recognition, phrase parsing, and/or command identification (i.e. matching) processes are less likely to cause an undesirable update to the auction state. With reference to Figure 3, at step 306 an update to the auction state is performed based on the type of the generated command data (e.g., either auction command data representing commands spoken by the auctioneer that are identified by the speech control unit 910, or input command data representing commands entered directly via control panel unit 940, as described below). Figure 6 illustrates a process for updating the auction state data performed by the auction logic unit 904.

[0099] At steps 601 and 603, the Command Execution Controller 932 receives the respective auction command or input command data from the command matcher 915 or command instruction module 942. At steps 602 and 604, the Command Execution Controller 932 processes the received data to produce an indication of the command type (e.g., a bid) and corresponding values (e.g., a bid amount). In the case of a spoken auction command, the Command Execution Controller 932 performs further processing to verify that the command is valid. Specifically, in the described embodiments, the execution of a command identified by particular auction command data is conditional on a positive verification of the command in the context of the current state of the auction.

[0100] Verification involves the Command Execution Controller 932 performing a series of checks on the command type and values. If the identified auction command is an indication of the acceptance of a bid, the verification of the command involves comparing the value of the indicated accepted bid with the present bid for the lot, and/or with one or more previous bids for the lot. For example, with a command to take a bid, if there have been previous bids the command will only be executed if the bid amount is greater than the current top bid and less than or equal to twice the current top bid. If the identified command passes the verification checks, then the Command Execution Controller 932 prepares the command for execution (e.g., by loading appropriate command data representing the type and/or values into execution data structures for accessing by the auction state controller 934).

[0101] In the case of an input command received from auction control panel unit 940, the described embodiments involve the loading of the command data without prior verification checks (i.e., at step 604). This is based on the assumption that the set of input commands that can be issued by the control panel unit 940 contain only valid commands (since this set is constrained by the current auction state, and is determined dynamically in accordance with the processes described herein).

[0102] At step 605, the Command Execution Controller 932 executes the loaded command to cause the Auction State Controller 934 to update the auction state data. The Auction State Controller 934 maintains a record of the state of a lot in an auction via a 'lot status' parameter, which can take values including: Created, Current, Selling, Withdrawn, Passed In, Vendor, and Sold. The status of a lot is initially set to Created, then when it is offered for bids the status is changed to Current. The Selling state indicates that the lot is in a period where it is being sold (e.g., when buyer numbers are being recorded). Finally the lot status can be recorded as being Withdrawn, Passed In, referred to vendor, or sold.

[0103] The auction state data maintained by the Auction State Controller 934 also includes an indication of the:

• Number of Bids: The number of bids that have been accepted for this lot;

• List of Bids: The bidder numbers and amounts of all bids for the lot;

• Top Bid: The top bid price, zero if there are no bids; • Bid Increment: The amount the next bid should be higher than the current bid if any. If there are no bids the increment is determined from the starting price or the reserve price if any; and

• Asking Price: The size of bid the auctioneer is looking for. If there have been bids then this will be equal to the current top bid plus the bid increment.

[0104] If the auctioneer takes (i.e., accepts) a bid, then the bid is added to the bid list data structure. If the auctioneer asks for a bid, then the asking price parameter value is updated. If the lot is sold (i.e., as a result of the command), the update includes storing the results of the auction in an auction record data structure of the Auction State Controller 934. The auction record structure creates a copy of the values for each auction state parameter to record the history and result of the auction of the lot. and the auction state moves on to the next lot.

[0105] Following the update to the auction state data, the updated data is transmitted from the auction logic unit 904 to the Auction Control Unit 920 (i.e., at step 606). In the described embodiments, the updated auction state data is delivered to the Auction Control Unit 920 by the transmission of an auction update message of a predetermined form. The auction update message is transmitted from the Auction State Controller 934 to the Auction Control Unit 920, and subsequently from the Auction Control Unit 920 to the Participant Devices 951-951N. Data encapsulated within the auction update message includes an indication of the: Current Lot Number; status of the lot; top bid price; current bid increment; and list of bids for the lot. The auction update message is received by each participant device 951-951 N and the corresponding data is processed by the auction application to indicate the newly updated status of the lot to each respective participant.

[0106] In some embodiments, the Command Execution Controller 932 is configured to analyse one or more of the identified commands to determine whether the auction state data is correct, the analysis being based on the current state of the auction. For example, the controller 932 may analyse one or more auction commands identified from the auctioneer's speech to determine that the auctioneer is calling a lesser top bid than the currently recorded top bid. In response, the Command Execution Controller 932 may automatically instruct the State Controller 934 to remove the top bid (i.e. without a command being issued by the speech control unit 910 or auction control panel 940). In another example, the Command Execution Controller 932 may detect, by analysing one or more commands, that the auctioneer is repeating a higher top bid, and may instruct the State Controller 934 to change the bid (i.e., add a bid) to match the price the auctioneer is now calling (as represented by the received commands).

[0107] In some embodiments, the analysis of identified commands can include specific examination of particular parameter values of the current auction state data. For example, the analysis can include determining a number of the current lot on offer and comparing the number of the current lot on offer to the current lot number of the auction state data. The auction logic unit 904 may be configured to generate warning or alert instructions to cause the control panel unit 940 to alert the user 931 (such as via an audio or visual indication on panel 944) if the numbers do not match.

[0108] The analysis can also include determining a current top bid price of the lot, and comparing the current top bid price to a value of the top bid price maintained by the auction state data. If the current top bid differs from the top bid of the auction state data, then the Command Execution Controller 932 instructs the State Controller 934 to automatically add or remove bids from the state data until the stored top bid price matches the top bid price called by the auctioneer.

[0109] The analysis can also include determining a live state of the top bid as a "live" bid or an "Internet" bid, and comparing the live state of the top bid with a corresponding live state of the top bid of the auction state data. If the live state of the current top bid differs from that of the top bid of the auction state data, then the Command Execution Controller 932 instructs the State Controller 934 to swap the live state of the stored top bid from a live bid to an Internet bid, or vice versa.

[0110] In the aforementioned examples, the auction logic unit 904 determines that the current auction state is incorrect as a result of analysing the identified commands, and the current auction state is then corrected via the automatic generation and execution of auction state correction data (i.e. to add or remove bids, or swap the live state of a bid). That is, the auction logic unit 904 functions to ensure correctness and consistency of the auction state prior to executing the identified commands (which may result in further updates to the auction state, as described above).

[0111] With reference to Figure 3, at step 308 following the updating of the auction state data, the control panel unit 940 receives feedback from the auction logic unit 904 in the form of the updated state data. The auction control panel unit 940 is configured to generate auction interface data representing a control interface that, when rendered on a display of a computing device, such as panel 944, provides a visual representation of the state of the auction (i.e., the state of the lot as updated). The control interface can also be configured to provide an indication of the speech processing operations of speech control unit 910. For example, the auctioneer panel 944 is deployed such as to be visible to the auctioneer 901 during the action allowing them to obtain feedback on how effectively their speech is driving the electronic auctioning process (i.e. how the phrase recognition and command identification operations result in updates to the auction state).

[0112] Figure 4b shows a screenshot of a voice sub-panel 450 containing a textual speech transcription produced by the speech control unit 910 and rendered on the auctioneer panel 944 to provide visual feedback to the auctioneer 901. In the screenshot, the transcription output accurately represents commands spoken by the auctioneer until the auctioneer takes a bid for $110. The unit 910 misses the $110 bid, and although the auctioneer repeats the bid the unit 910 still does not properly recognise it. Flowever, the auctioneer 901 may view the transcription output in real-time which may prompt them to remember that including the word dollars can assist the recogniser. When the auctioneer says "I have one hundred and ten dollars" the speech control unit 910 is able to correctly recognise the bid command. The transcription shows that when the auctioneer takes a subsequent bid for $120 they repeated the bid and sold the lot without a pause. The speech control unit 910 could not keep up and the lot was sold before the bid for $120 could be processed. The transcription illustrates this to the auctioneer 901, which may prompt them to consciously pause when making future bid calls in order to improve the performance of the system.

[0113] In the described embodiments, the auction control unit 940 also provides functionality allowing the auction state data to be modified in response to user input to the panel (e.g., by user 931), and where this functionality is determined dynamically based on the auction state data (i.e., as feedback from the logic unit 904). The functionality is provided on auctioneer panel 944 by one or more interactive graphical user interface elements that are configured to receive input from a user of the panel 944.

[0114] Data representing the elements of the auctioneer control panel 944 is generated by the auction control panel unit 940, and is subsequently processed by a computing device for display to a user, according to a process illustrated by Figure 7. At step 702, the auction control panel unit 940 receives auction state data representing the present (i.e. most recently updated) auction state information. The command execution controller 932 provides the command instruction module 942 with the auction state data automatically when the state of the auction is updated, such as for example using an event listener configuration. Alternatively, or in addition, the command execution controller 932 can be configured to provide the command instruction module 942 with auction state data periodically (e.g. at predetermined time instants).

[0115] At step 704, the command instruction module 942 analyses the received auction state data to determine a context for the functionality of the auction control panel. In the described embodiments, the analysis involves processing the auction state parameters including: the status of the auction; the current bid; the set of previously accepted bid values; and the current bid increment.

[0116] At step 706, the command instruction module 942 determines the specific functions to be provided by auction control panel to a user of the system 900

[0117] For example, if the auction is in progress the auction control panel may be configured to include a 'Bidding' subpanel, which allows the user to perform operations such as removing bids, swapping bids, setting a bid increment, and entering new bids with particular values. The operations are determined dynamically based on the bid information of the auction state data. For example, the values of the bids that can be entered via the Bidding subpanel may span a range including the current bid, where the range is determined by the current bid increment (as discussed further below).

[0118] Display functionality data representing the functions to be provided by the interactive user interface is generated by the Command Instruction Module 942, and subsequently transmitted to the Auctioneer Control Panel 944. At step 708, the command instruction module 942 generates interface data to represent the user interface, including the control interface (referred to as an "auction control panel" as rendered on display panel 944, and distinct from auction control panel unit 940), based on the display functionality data. In the described embodiments, the auction control panel includes graphical user interface elements in the form of a plurality of selectively enabled buttons. Each button has associated element parameter data describing a set of parameters of the element, including : the position of the element in a display area of the control panel; an activity state of the element; a command associated with the element; and a corresponding value of the command. This allows, for example, particular user interface elements (i.e. buttons) to be mapped to particular commands, such as accepting a bid, that may be identified and executed by the speech-driven processes described above, and where the mapping is dynamic based on the auction state (e.g. where the bid command value is determined by the current bid).

[0119] The parameters of each enabled button are determined from the display functionality data, and are updated in response to corresponding updates of the auction state data (as described by example below). That is, in the described embodiments, the display functionality data specifies a set of the parameters for the interface elements, which collectively define a particular configuration (or "subpanel") of the auction control panel. For example, in the starting configuration the interface elements provide functionality for operations associated with the early stages of the auction, including setting an opening bid, while the "sale" configuration allows operations associated with the closing of the auction to be performed.

[0120] The control panel dynamically transitions between configurations (or subpanels) such that, when rendered on a corresponding display (such as display panel 944), and at any given time during the auction, the elements of the control panel are configured to receive user input to cause the control panel unit 940 to generate input command data representing the issuance of one or more corresponding input commands by the user. The input command data is processed, at the auction logic unit, to execute one or more input commands to cause the state of the auction to be updated without the processing of a corresponding auction command (as described above).

[0121] In the described embodiments, the elements of the control panel are configured to facilitate the issuing of one or more commands, or the updating of the state of the auction, in a manner that is most likely to be desired by the user (e.g. for the purpose of correcting errors in the speech-driven processing based on the updated auction state).

[0122] For example, in some embodiments the interface elements include a set of buttons each operating to issue bid acceptance commands for bid values in a particular range. Consider an auction managed via the EAS 900 in which the auction state data is updated to reflect a currently accepted bid of $110, with the bid increment set to $10. The auction control panel unit 940 generates element parameter data such that the range includes bid values that a user would most likely desire in this situation (i.e. those values that are likely to correspond to actual bids placed by participants). That is, the range could be dynamically set as $90 to $130 for the aforementioned auction state, providing the user with a means for the efficient correction of an error made by the speech control unit 910 (e.g. by clicking a single button). The elements may allow other values to be taken for the next bid, such as $115 (where the increment is changed to $5), $120 (where the increment is kept at $10), or $130 (where the increment is changed to $20).

[0123] At step 710, the generated interface data is rendered on a device display such that the auction control panel 940 can be operated by the user 931. In the described embodiments, the interface is rendered on a display panel 944of the electronic auction device 902. In other embodiments, the interface data may be transmitted to a separate user device via a one or more communications networks.

[0124] With reference to Figure 3, the EAS 900 is configured to receive control input data from the auction control panel 940 (i.e., at step 303) and generate corresponding input command data (i.e., at step 305) to represent auction commands issued directly to the system by the operation of the panel 940. The control input data includes an indication of the corresponding control interface elements activated by the user 931 (i.e., via panel 944, such as when particular buttons are clicked) to result in the issuing of the command input. The corresponding bid or instruction command (as described above) is specified by the control input data, as generated by the auctioneer panel 944. The control input data is transmitted to the Command Instruction Module 942 which generates the input command data to instruct the Command Execution Controller 932 to execute the command. As discussed above, the Command Execution Controller 932 will then update the state of the auction as maintained by the Auction State Controller 934, allowing the updated auction state information to be utilised by the Speech Control Unit 910 and Auction Control Panel 940 in a feedback loop to assist with the generation of subsequent auction and input command data.

Example Auction Control Panel Interface

[0125] Figures 8 to 11 illustrate example configurations of an auction control panel forming part of an interactive control interface for the EAS 900 in accordance with some of the described embodiments. The auction control panel configuration is defined, at least in part, by the parameter data of the corresponding interactive graphical user interface elements, and can therefore change dynamically based on the state of the auction. Each configuration may be implemented over the entirety of a graphical canvas of the interface, such as a window, or as or a particular sub-part of the canvas (i.e. as a subpanel rendered in a panel window).

[0126] Configurations of the auction control panel include a starting configuration 800, as shown in Figure 8, which is displayed to the user when a lot is first offered. The starting panel configuration 800 depicts the auctioning of a lot (i.e. "Lot 10"). In each configuration, the control panel includes a set of display sub-regions 802-804 indicating the state of the auction, and a set of buttons 806-832 which are interactive elements configured to receive input from a user of the computing device on which the interface is rendered. Particular buttons are selectively enabled, in the sense that a button may enabled (i.e. in the 'active state' and able to be operated), or disabled (i.e. in the 'non- active state' and not able to be operated) on the interface at any given time. For example, in the configuration of Figure 8, button 810 and button 818 may be active or disabled. Button 810 is normally disabled, it is enabled when the lot has a starting price that does not fit any of the usual starting price buttons (i.e., buttons 812, 814, 820, 822, 824, 828 and 830). If the starting price is set at $130, then button 810 is enabled and shows $130. Clicking on button 810 then makes it the active button, and sets the asking price to $130. Clicking again on button 810 results in an opening bid of $130. Button 818 is enabled if there is an Internet bid available and disabled otherwise. In this example, the state and value of button 810, and the values of all the other buttons, vary according to the auction state. The command associated with each button is fixed for each of the three sub panels shown. In other examples, the state of each button, and the corresponding command associated with the button, may be varied according to the configuration.

[0127] A context of for the display of a starting configuration 800 may be as follows: Lot 9 has just been sold and the EAS 900 is being used to sell Lot 10. The auctioning process has just commenced as indicated by the "Starting" text in region 804. The auctioneer has commenced offering the lot by soliciting for an opening bid of $100. Button 812 is lit on the panel 800 indicating that $100 is the starting amount, either as a result of the speech control unit 910 recognising and executing the instruction for asking for a specific bid, or as a result of user input to the panel in the form of a click on button 812.

[0128] In the example starting configuration 800, the functionality provided by the buttons 806-832 is as follows. 'Go Back' 806 would take the auction back to lot nine if something went wrong. 'Final' 808 will issue a "Final Call" or "Last Chance" to bid before moving to the next lot. 'Spare Blue' 810 can show a request for a starting bid that does not fit any of the starting price buttons. That is, if the auctioneer was looking to start at $105 the spare blue button would be enabled with a value of $105, and clicking it would start the bidding at $105. '$100' 812 is the starting price button, and is highlighted because the auctioneer is looking for an opening bid of $100. '$120' 814, '$150' 820, '$180' 822, '$200' 824, '$250' 828, and '$300' 830 are starting price buttons that can be selected, either manually by the user clicking on the button or automatically by the speech control unit 910, if the auctioneer is looking for the price displayed on the button. 'Down' 816 and 'Up' 832 provide functions to decrease or increase the amount shown on the starting price buttons. The 'First Panel' region 804 shows the lot number, and that there have not been any bids yet. 'Take Net Bid' 818 allows the user to accept bids from Internet participants (i.e. clicking on this button will accept the Internet bid). The 'Second Panel' region 802 shows a picture of the lot on offer. 'Done' 826 prematurely ends the offering of the lot (e.g. if the lot is passed in or withdrawn).

[0129] When a bid is accepted for the item, the state of the auction is updated by the auction state controller 934, in accordance with the processes described herein above. For example, if the auctioneer sees and bid and calls "I have one hundred dollars" a bid of value $100 is accepted (either due to automatic speech processing, or manually clicking on the interface). This ends the starting price phase and moves the auction into the bidding phase during which a bidding subpanel is displayed.

[0130] Figure 9 depicts an exemplary bidding configuration 860 which provides the following functionality: 'Remove Bid' 806 operates to remove the top bid and reinstate the second top bid (if any). If there are no lower bids the auction re-enters the starting bid phase (causing the starting configuration to be again displayed). 'Swap Bids' 808 changes the state of the current bid from a live bid to an Internet bid, and vice versa. '$5' 810, '$10' 812, '$20' 814, '$25' 816 are bid increment buttons clicking which are operable to change the bid increment. The $10 button being highlighted shows that the current bid increment is $10. The 'First Panel' region 804 shows the lot number and that the current bid is a bid from the auction room (i.e. "Live") for $100. '$105' 818, '$110' 820, '$120' 822, '$125' 824 are the bid buttons operable to accept the next bid. '$110' 820 is configured as the main bid button for accepting a bid increased by the current increment. The '$105' 818 button is for a $5 increment and other two buttons 822, 824 are for larger increments. The 'Second Panel' region 802 shows a picture of the lot on offer. The 'Net Bid' button 826 is where bids from the Internet are shown. In this case there are no Internet bids, however if there was an Internet bid, from say bidder 234, then the button would show "234 $110". Clicking on button 826 would then take the bid from the Internet at $110.

[0131] Clicking on the "Gone" button 828 ends the auctioning of the lot normally by selling or passing in the lot at the current bid. 'Call' 830 operates to issue a first call on a first click of the button, a second call on a second click of the button, and a final call on a third click of the button. The 'Final' button 832 is operable to issue a final call.

[0132] In the case illustrated by Figure 9, the bidding configuration 860 shows that a bid of $100 has been accepted from someone at the auction, or from an absentee bidder. The bid increment value is set to $10, which means that the next bid should be $110. The user may click on one of the top row of buttons to change the increment to the amount shown on the button. [0133] Figure 10 illustrates a second bidding configuration 1000 of the auction control panel after the acceptance of a new bid. For example, if the auctioneer calls "one hundred and ten dollars is bid" the auction state is updated in respect of the newly accepted bid. As a result, the auction control panel is then updated to the configuration shown in Figure 10 (as discussed above). Alternatively, if a bid is received, from say bidder 454 on a participant device 951-951N, it is displayed on button 826. In this case, the label on button 826 then reads "454 $110". The user (e.g. a webcaster, or the auctioneer themselves) can accept this bid by clicking on button 826.

[0134] Consider the case where there is no further bidding on an item. For example, when the auction is in the bidding phase as indicated by the display of a bidding panel configuration 860, if there was no further bidding then the auctioneer might call "Sold to bidder 234". Ideally, the speech control unit 910 identifies and executes the associated instruction (i.e. a command indicating a sale of the lot, where "234" is recognised as the buyer identifier). Alternatively, and/or in addition, the user may click the "Gone" button to manually issue the sale instruction. The auctioning of this lot is now complete and the auction state data is updated to have an auction status value of "selling" and the sale configuration 1100 is now displayed on the auction control panel.

[0135] Figure 11 shows an exemplary sale configuration 1100 which provides the following functionality: O'-'9' 840-849 are number buttons that may be clicked to enter the number of the current top bidder or buyer of the lot, if required. 'Clear' 850 is operable to clear the small panel currently showing "234" (e.g. if a mistake in entering the bidder ID is made). 'Deactivate' 851 removes the top number buttons and halts the recording of the numbers of the buyers. The 'First Panel' 804 shows that the highest bid for Lot 10 was a bid of $110 from a bidder in the auction room. The button adjacent to the first panel 818 shows the number of the buyer ('234'), as entered by the top number buttons or by the speech control system. 'Not Webcast' 820 is operable to indicate that the lot is not available to bidders on the Internet. 'Withdrawn' 822 allows the user to withdraw the lot from sale. 'Swap Bids' 824 operates as described above to change the status of a bid from live to Internet, or vice versa. The 'Second Panel' region 802 shows a picture of the lot on offer. 'Pass In' 826 allows the user to indicate that the lot is passed in (as opposed to being sold). 'Go Back' 828 operates to reopen the auction process from the completed state (e.g., when the Lot is reopened, or if there is another bid), and clicking this button will cause a bidding configuration to be displayed. If there are bids for the lot, then clicking the "Go Back" button will cause the bidding configuration 1000 to be displayed. If there are no bids then clicking the "Go Back" button will cause the starting configuration 800 to be displayed. 'Referral' 830 allows the user to indicate that the lot is referred to vendor (i.e. sold, subject to an approval from the vendor). 'Sold' 832 operates to indicate that the lot is sold.

[0136] Figure 12 is a transition state depiction 1200 illustrating the transitions between the starting, bidding and sale configurations of the auction control panel. The thick arrows in the middle (Ί in', '4', '6', Ί out') and on the right ('2', '3', '5') of the depiction show the transitions involved in the normal auctioning of a lot. The thinner lines on the left of the depiction ('8 in', '8 out', '7 in', '7 out', '9', ΊO', ΊI', Ί2', Ί3') show the transitions available to correct errors.

[0137] Consider the offering of a single lot for auction. The transition depiction flowing down the page corresponds to the normal process of auctioning one lot in a series of auctions for corresponding lots (i.e. without errors). Once the previous lot has been sold the flow of the auction comes in via arrow Ί in' at the top. The flow of the auction will follow the thick arrows down and on to the next lot via the bottom arrow Ί out'. All the thick normal flow arrows stay in the same configuration or lead down the page with the normal flow of the auction. All the thin error correction arrows stay on the same configuration or flow up to remove auction events and back the auction up.

[0138] When the auctioneer issues a command (e.g. to take a bid, alter the starting price, sell a lot, etc.), the issued command may be implemented manually (e.g. by clicking on the panel) or automatically by the speech control system matching the command. In the following, the commands which are to be matched by the speech control system, or clicked on the panel, will be underlined.

[0139] Arrow 1 in: Once the previous lot is sold control passes to this lot and starts in the Starting Configuration (i.e., as shown in Figure 8). The Starting Configuration is concerned with commencing the bidding.

[0140] Arrow 2: Represents two commands both of which leave the Starting Configuration active. The first command is if the auctioneer does not get a bid at the asking price they may ask for a starting bid. The other command occurs if there is no bidding such that the auctioneer may make a first, second or final call.

[0141] Arrow 3: If there is no bidding the auctioneer may pass the lot in which results in a transition to the Sale Configuration 1100.

[0142] Arrow 4: When the auctioneer takes a bid there is a transition to the Bidding Configuration 860.

[0143] Arrow 5: Represents four main commands all of which leave the Bidding Configuration 860 active. Firstly, if the auctioneer takes a bid then the asking price will be updated and the auctioneer will be looking for another bid. Secondly, the auctioneer might choose to change the bidding increment. Thirdly the auctioneer may ask for a specific bid. Finally, if there is no bidding the auctioneer mav make a first second or final call.

[0144] Arrow 6: When the auctioneer declares the lot sold or passed there is a transition to the Sale Configuration 1100 to process the sale. The Sale Configuration 1100 offers a chance to enter the paddle number of the winning bidder, but this is not a command that changes to auction so is not represented by an arrow.

[0145] Arrow 1 out: The auctioneer can finalize the lot by declaring it sold referred to vendor, or passed in. This will take the auction on to the next lot.

[0146] Consider an auctioneer's call (i.e. speech) that illustrates most of these thicker arrows in the context of an example. The auctioneer's call will be shown in italics and the number of the arrow and the name of the subpanel on entry will be shown in (brackets).

[0147] Next we have lot 8, a lovely vase from Italy, (1 in) (enter Starting Configuration 800) what are my bids, is there $200 anywhere (2 request starting bid), 77/ take $100 (2 request starting bid), $100 I have (4 taking a bid) (enter Bidding Configuration 860). The bid is at $100 looking for $120 (5 request a bid) any advance on $100, I'll take a ten (5 change the bidding increment) $110 I have (5 taking a bid) any advance on $110, for the first and final time (5 make a call) sold (6 finalize the lot) (enter Sale Configuration 1100) to bidder 234 for $110 (1 out) (moving on to the next lot).

[0148] Now consider the thinner left-most arrows in the depiction 1200 that show the transitions that correct errors. These errors may, for example, be caused by someone operating the auction control panel incorrectly (e.g. because they misinterpret the auctioneer's commands). Alternatively, the errors could be caused by mistakes made by the speech control system. Sources of error may include errors of omission, where the speech control system fails to spot a command, and errors of inclusion, where the speech control systems matches a command that is not there. For example, auctioneers often call the bid they are looking for, which can cause a common error of inclusion if either someone using the control panel, or the speech control system, mistakenly takes this for a bid.

[0149] Arrow 7 out: If, when a lot is first offered, there is a bid on the previous lot or a problem with the previous lot, then control can be passed back to the previous lot via this arrow. However, the control panel does not return to the last configuration (the sale configuration 1100), as it usually returns to the bidding configuration 860.

[0150] Arrow 8 out: If there is a problem as described above (for arrow 7) and there are no bids on the previous lot, the control panel returns to the starting configuration 800 for the previous lot in order to seek a starting bid.

[0151] Arrow 9: Represents two main corrections that can be performed. A user of the auction control panel may take an Internet bid when it is really a live bid from the auction floor, or vice versa (i.e. take a live bid when the auctioneer wants to take a bid of the Internet). Alternatively, the speech control system may make the same mistake and take a live bid instead of an Internet bid or vice versa. To address this problem the bidding configuration 860 has a button 808 that will swap a live bid to an Internet bid or an Internet bid to a live bid. Another commonly desired correction is to remove the top bid. When an auctioneer asks for the next bid a person operating the auction control panel may think, or the speech control speech may interpret, that the auctioneer is actually taking (i.e. accepting) the next bid. In this case, the correction involves removing the top bid returning to the previous bid.

[0152] Arrow 10: If there is only one bid and as discussed above (for arrow 9) the top bid is removed, then there will be no bids and the control panel returns to the starting configuration 800 in order to facilitate obtaining a new starting bid.

[0153] Arrow 11 : As discussed in arrow 9, the top bid may be an Internet bid when it should be a live bid and vice versa. When selling the lot it is important to check that this mistake has not been made. If the bid is of the wrong type then the correction involves swapping the bid from an Internet bid to a live bid, or from a live bid to an Internet bid.

[0154] Arrow 12: Bids can come in very close to the time a lot is sold, it can be quite important to reopen the bidding rather than complete the selling of the lot. If there is already a bid on the lot, then reopening the bidding will return the control panel to the Bidding Configuration 860.

[0155] Arrow 13: If there is a need to reopen the bidding as discussed above (for arrow 12) but there have not been any bids, then the control panel will return to the Starting Configuration 800.

[0156] Arrow 7 in: If control has moved on to the next lot, but there is a late bid for this lot, or if there is a problem with the lot, then the sale of the lot can be reversed and the control panel will return to the bidding configuration 860. [0157] Arrow 8 in: If there is a reversal as discussed above (for arrow 7 in) but there have been no bids, then the control panel will return to the Starting Configuration 800 in order to seek an opening bid.

[0158] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention.