A software-based system for implementing a modified Dutch auction

Abstract

A modified Dutch auction system 10 includes a server application and at least one client application. Each client application has a front-end 12 for displaying a real-time price value of a listing, a bid processing engine 14 for processing client-side purchase actions (e.g. immediate purchase or holding bid), and a dynamic pricing algorithm 16 to adjust the real-time price value. The server application has a bid management system communicable with the bid processing engine of each client application. Synchronisation between the bid management system and bid processing engine(s) is performed on initiation of a client-side purchase action and on completion of a client-side purchase action. This synchronization ensures consistency between the real-time price values at the server and client applications. The client application may also periodically synchronise the real-time price value with the bid management system.

Description

The present invention relates to a software-based system for implementing a modified Dutch auction. The invention further relates to a method implemented by said system. In a traditional Dutch auction, the auctioneer commences with a price higher than the expected final bid and reduces it successively until a participant is willing to accept the auctioneer's price, or a predetermined reserve price is achieved. This is straightforward where the auction has been conducted in a single location, as the auctioneer is able to determine visually which vote is currently winning. However, in an online environment, it becomes difficult to maintain synchronization between each bidding party and the auction provider. Since the auction ends when a threshold price is met, but that threshold decreases over time, loss of synchronization obscures the winning bid, and leads to database conflicts where multiple bids arrive. It is an object of the present invention to reduce or substantially obviate the aforementioned problems. According to a first aspect of the invention, there is provided a software-based system for implementing a modified Dutch auction, comprising: a server application and at least one client application; wherein the or each client application comprises: a front-end visualization layer configured to display a real-time price value of a listing; a bid processing engine designed to process client-side purchase actions; and a dynamic pricing algorithm to adjust the real-time price value; and wherein the server application comprises: a bid management system communicable with the bid processing engine of the or each client application; wherein synchronisation between the bid management system is performed on initiation of a client-side purchase action and on completion of a client-side purchase action to ensure consistency between the real-time prices values at the server application and the or each client application. The present invention allows for prompt processing of client-side bids in a modified Dutch auction, to ensure consistency of the auction across multiple locations. This is achieved by the synchronisation process between the bid processing engine at the client side with the bid management system or database at the server side. This system allows for the implementation of the dynamic price variation without leading to conflicts within the system as a whole. This can be achieved by having dynamic price calculation performed both at the client-side and the server-side, with regular synchronisation to ensure that there is no significant deviation between the applications involved. Optionally, the client-side purchase action may be an immediate purchase action or a holding bid action. The synchronisation procedure of the present invention allows for both buy-it-now and holding bids to be contemporaneously managed without causing conflicts within the system. Preferably, the real-time price value may have a minimum value of zero. The use of a dynamic pricing algorithm allows for pricing to be more easily controlled according to supply and demand in real-time, which may even mean dispensation of stock at zero price. The bid management system may be optimised for high-frequency operations, storing holding bids, user data, and transaction logs. The bid management system needs to be robust and capable with handling the number and frequency of synchronisation updates which are utilised within the present invention. Preferably, the dynamic pricing algorithm may include a market-parameter input for determining the adjustment to the real-time price value. The dynamic pricing algorithm is influenced by market forces, and thus provides the user with a means of price adjustment according to demand. As such, price optimisation can be achieved for the auctioneer. The bid processing engine may be configured to initiate the auction at a pre-defined starting price. In one embodiment, the dynamic pricing algorithm may decrease the real-time price value from the pre-defined starting price. The modified Dutch auction is designed to decrease, or increase in certain circumstances, from a pre-determined value intended to tempt customers into making bids, and thereby driving interest in the auction. Preferably, the bid processing engine may compare the real-time price value in real-time against client-side purchase actions to determine a winning bid. The functioning of the present system is based on ensuring consistency between the central price as known at the server, and the price displayed at the client application. In doing so, the risk of lag-based auction problems can be significantly mitigated. The front-end visualization layer may be configured to display a highest holding bid in real-time. Display of the highest pending bid will help customers identify opportunities for further bidding, driving the auction forward and hopefully ensuring a better auction return for the auctioneer. Optionally, the client application may periodically synchronise the real-time price value with that of the bid management system. Periodic synchronisation between the bid management system and bid processing engine allows for consistency to be maintained therebetween, so that client-end freezing of a price where there is lag does not cause database conflicts. The bid processing engine may pre-authorises a user payment prior to submitting a bid to the bid management system. Pre-authorisation of payments has the advantage of not submitting bids to the bid management system which block the continuation of the auction, and can therefore impede the process for all users. This is preferably performed at the client application, so that only verified bids are accumulated in the central database. The software-based system may further comprise an e-commerce platform integration interface. It is desirable to integrate the system into existing e-commerce platforms as a means of implementing the modified Dutch auction process within as many businesses as possible. The software-based system may further comprise a notification server configured to process notifications. Notifications being issued via a separate server may reduce the burden on the bid management system. The software-based system may further comprise a payment server configured to process payment. There will likely be a discrete interface for management of payments, in order that the connectivity with existing payment providers can be utilised. According to a second aspect of the invention, there is provided a method for implementing a modified Dutch auction, the method comprising the steps of: a] displaying, at a front-end visualisation layer of a client application, a real-time price value of a listing; b] processing, using a bid processing engine of the client application, clientside purchase actions; c] adjusting the real-time price value using a dynamic pricing algorithm; and d] using a bid management system of a server application which is communicable with the client application, determining a status of the or each client-side purchase action, wherein synchronisation between the bid management system is performed on initiation of a client-side purchase action and on completion of a clientside purchase action to ensure consistency between the real-time prices values at the server application and the client application. The present method allows for the implementation of a modified Dutch auction without causing database conflicts due to the synchronisation steps performed. Optionally, the client-side purchase action may be an immediate purchase action or a holding bid action. For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made by way of example only to the accompanying drawings, in which: Figure 1 shows a diagrammatic representation of a first embodiment of a software-based system in accordance with the first aspect of the invention; Figure 2 shows a representation of a front-end visualisation layer, in the form of a customer user interface, of the software-based system of Figure 1; Figure 3 shows a representation of the front-end visualisation layer of Figure 2 in an expanded state; Figure 4A shows a first part of a diagrammatic representation of a method of implementing a modified Dutch auction in accordance with the second aspect of the invention; Figure 4B shows a second part of the representation of Figure 4A; Figure 4C shows a third part of the representation of Figures 4A and 4B; and Figure 4D shows a third part of the representation of Figures 4A, 4B, and 4C. Referring firstly to Figure 1, there is indicated an indicative software-based system for implementing a modified Dutch auction, being referenced globally at 10. The software-based system 10 comprises a software application which is architecturally partitioned into a front-end visualisation layer 12, a bid processing engine 14, a dynamic pricing algorithm 16, and a bid management system 18, which may be referred to as a database management system or bid database. The front-end visualization layer 12 is responsible for rendering real-time descending price values 20 and displaying a highest extant holding bid 22. This ensures that participants are continually informed, instigating strategic bidding behaviours. The bid-processing engine 14 is an intricate module that concurrently processes immediate purchase actions at the descending price and any number of holding bids 22. It leverages advanced data structures to ensure optimal time complexity during bid retrieval and insertion operations. The dynamic pricing algorithm 16 is an algorithmic component which continually calculates the rate of price descent based on parameters like demand intensity, historical data, and holding bid trends, ensuring market-relevant price adjustments. The bid management system 18 is a robust system for storing holding bids, user data, and transaction logs, optimised for high-frequency read-write operations to support the real-time nature of the auction. Figure 2 shows a first representation of the front-end visualisation layer 12 which would be visible to a customer. There is indicated one or more listings 24, identifying any or all of: the product 26 to be sold; the real-time price value 20; the highest current bid 22; and the remaining auction time 28. One or more user inputs may be provided, such as a ‘Buy’ button 30 allowing a user to immediately freeze the price of the listing 24 at the real-time price value 20, and a ‘Bid’ button 32, allowing a user to input a holding bid which will with the auction if it remains the highest bid when the remaining auction time 28 elapses. Figure 3 shows a more detailed representation of the listing 24 in the front-end visualisation layer 12. The user’s highest bid 22 is displayed again, with more options to either improve the bid via a ‘Bid Again’ button 34 or cancel the bid via a ‘Cancel Bid’ button 36. There may also be a display portion 38 showing the current holding bids currently made against the listing 24. With reference to Figures 4A to 4D, the method of implementation of the software-based system 10 is described in detail. The split between the operations of the listing server application 40 and the client application 42 is shown for clarity. A notification application 44, bid management system 46, and payment system 48 are also provided, which are separate of the client application 42. It will be apparent that any or all of the server application 40, notification application 44, bid management system 46, and payment system 48 may be implemented on a single server, a central server, a decentralised server, a plurality of servers, or any combination thereof. When a user wishes to engage with the software-based system 10, then the client application 42 is activated, which communicates with the server application 40. The listing server application 40 may authenticate the user account, and send initial listings 24 for display on the client application 42 via the front-end visualization layer 12. Also transmitted from the server application 40 to the client application 42 is a master timestamp, referred to as a heartbeat server time. This is the true time from which auction countdowns for each listing 24 is determined, and against which bids are referenced. On the client application 42, initial listing prices are set, based on the master timestamp, the initial price, and the dynamic pricing algorithm 16. Once received, the client application 42 initiates a local clock, which allows for the real-time descending price values 20 to be calculated at the client side. As the local clock progresses, this may trigger one or more client-side requests. The client application 42 may periodically communicate with the listing server application 40 to retrieve listing updates, where new listings 24 can be added, and old listings 24 removed. The client application 42 may also retrieve data relating to other customers from the listing server application 40, for instance, displaying the highest bids from other users, or identifying a number of watchers of a particular listing 24. Furthermore, the client application 42 may request a synchronisation between the local clock and the current master timestamp, which will identify and rectify and discrepancies. The notification process is shown in Figure 4B in detail. The client application 42 can be configured to allow a user to add a listing 24 to a watchlist, and may be able to set triggerable notifications based on specific price points. The notification record may then be transmitted to the notification server 44 which then transmits notifications to the client application 42 as the real-time price value 20 for the listing 24 descends. To achieve this, the notification server 44 must have knowledge of the real-time price value 20, either by communication with the listing server application 40, or by hosting the listing server application 40 directly. When bids are placed, the user enters a bid amount. This will then take the user to a payment input stage, which may require input of payment details by the user, or may import payment details already saved to the client application 42. This logs a deferred payment authorisation, which may be verified by the bid processing engine 14 and / or an interface with a payment verifier such as the user’s banking software. In the event of failure, the bid processing engine 14 will notify the user of the failure, and may allow further attempts. If pre-authorisation is successful, the bid processing engine 14 transfers the bid from the client application 42 to the bid management system 46, which may be a component part of the listing server application 40. The user bid is added to a bid table for the listing 24. The bid management system 46 then identifies whether the user bid is the highest bid; the user is notified through the client application 42 either way, but may be prompted to make a further bid should they not be determined to be the highest bidder. To cancel a bid, a request is made to the bid processing engine 14, which then sends a request to cancel the bid from the bid table, which may in turn trigger notifications to the new highest bidder where appropriate. For each listing 24, the bid management system 46 will be determining whether the current bid price is greater than the real-time price value 20, in which case, the listing 24 is sold to the highest bidder, and the highest bidder is notified. Where the current bid price is less than the real-time price value 20, the listing 24 is not sold, which allows the generation of the ‘Buy’ button 30. This enables the freezing of the real-time price value 20 for a user to secure purchase of the listing 24 at that price, rather than risk being outbid during the Dutch auction. When the ‘Buy’ button is triggered, the user is able to purchase the listing 24, and as such, the bid management system 46 can mark the listing 24 as sold. Users with unsuccessful bids are notified, and the successful bidder is notified separately. At the point of purchase, the real-time price value 20 becomes frozen, and this is where complications can arise in the system, since the client application 42 needs to update the server application 40 to avoid having multiple conflicting bids. In the present system 10, the real-time price value 20 is frozen, and payment information is entered, thereby creating a deferred payment authorisation. Pre-authorisation checks are therefore performed within the client application 42 to confirm that the payment could be successfully made. This is performed by the bid processing engine 14 for a clientside purchase action. This is, in effect, a synchronisation of the bid processing engine 14 with the server application 40 on initiation of the purchase action. The pre-authorisation confirmation is then sent to the bid management system 46, which ratifies whether the purchase instruction is the first one received, and whether the frozen real-time price value 20 is within a pre-determined tolerance value from the current price, to ensure that a real-time purchase action is being submitted. If authorised, the purchase proceeds at the frozen real-time price value 20, and the listing is marked as sold. This then triggers a purchase-completion synchronisation of the server application 40 with the bid processing engine 18, and both successful and unsuccessful users are notified. The payment system 48 may be provided as a separate server purely dedicated to processing payments following completion of the listings 24, so that all listings 24 bought by each user are collated, allowing listings 24 to be combined into purchase orders. Payments can be taken and orders confirmed. Said payment system 48 may an e-commerce platform integration interface. Whilst a Dutch auction is typically configured to decrease in price over time, using the dynamic pricing algorithm, it will be apparent that price increases to accommodate high demand could also be implemented, either as a separate auction type, or a hybrid Dutch auction. It is therefore possible to provide a modified Dutch auction in which the handling of realtime price changes is optimised to avoid bid overlap without end users needing to rely on a constant update feed from a remote server. This significantly removes the risk fo conflicting bids being submitted. The words ‘comprises / comprising’ and the words ‘having / including’ when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps, or components, but do not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination. The embodiments described above are provided by way of example only, and various changes and modifications will be apparent to persons skilled in the art without departing from the scope of the present invention as defined by the appended claims.

Claims

1. A software-based system for implementing a modified Dutch auction, comprising:a server application and at least one client application;wherein the or each client application comprises:a front-end visualization layer configured to display a real-time price value of a listing;a bid processing engine designed to process client-side purchase actions; anda dynamic pricing algorithm to adjust the real-time price value; andwherein the server application comprises:a bid management system communicable with the bid processing engine of the or each client application;wherein synchronisation between the bid management system is performed on initiation of a client-side purchase action and on completion of a client-side purchase action to ensure consistency between the realtime prices values at the server application and the or each client application.

2. A software-based system as claimed in claim 1, wherein the client-side purchase action is an immediate purchase action or a holding bid action.

3. A software-based system as claimed in claim 1 or claim 2, wherein the real-time price value has a minimum value of zero.

4. A software-based system as claimed in any one of the preceding claims, wherein the bid management system is optimised for high-frequency operations, storing holding bids, user data, and transaction logs.

5. A software-based system as claimed in any one of the preceding claims, wherein the dynamic pricing algorithm includes a market-parameter input for determining the adjustment to the real-time price value.

6. A software-based system as claimed in any one of the preceding claims, wherein the bid processing engine is configured to initiate the auction at a pre-defined starting price.

7. A software-based system as claimed in claim 6, wherein the dynamic pricing algorithm decreases the real-time price value from the pre-defined starting price.

8. A software-based system as claimed in any one of the preceding claims, wherein the bid processing engine compares the real-time price value in real-time against clientside purchase actions to determine a winning bid.

9. A software-based system as claimed in any one of the preceding claims, wherein the front-end visualization layer is configured to display a highest holding bid in realtime.

10. A software-based system as claimed in any one of the preceding claims, wherein the client application periodically synchronises the real-time price value with that of the bid management system.

11. A software-based system as claimed in any one of the preceding claims, wherein the bid processing engine pre-authorises a user payment prior to submitting a bid to the bid management system.

12. A software-based system as claimed in any one of the preceding claims, further comprising an e-commerce platform integration interface.

13. A software-based system as claimed in any one of the preceding claims, further comprising a notification server configured to process notifications.

14. A software-based system as claimed in any one of the preceding claims, further comprising a payment server configured to process payment.

15. A method for implementing a modified Dutch auction, the method comprising the steps of:a] displaying, at a front-end visualisation layer of a client application, a real-time price value of a listing;b] processing, using a bid processing engine of the client application, client-side purchase actions;5 c] adjusting the real-time price value using a dynamic pricing algorithm;andd] using a bid management system of a server application which is communicable with the client application, determining a status of the or each client-side purchase action, wherein synchronisation between the bid10 management system is performed on initiation of a client-side purchase actionand on completion of a client-side purchase action to ensure consistency between the real-time prices values at the server application and the client application.15 16. A method as claimed in claim 15, wherein the client-side purchase action is animmediate purchase action or a holding bid action.

Images