A software-based system for implementing a modified dutch auction

Abstract

There is provided a system (10) for an algorithmic model based on dynamic pricing which integrates a modified Dutch auction system with holding bids in e-commerce and auction-based marketplace space. By harnessing the power of real-time data analytics, dynamic pricing strategies can be achieved.

Description

[0001] A Software-Based System For Implementing A Modified Dutch Auction

[0002] 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.

[0003] 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.

[0004] 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.

[0005] It is an object of the present invention to reduce or substantially obviate the aforementioned problems.

[0006] 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 and the bid processing engine of the or each client application 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 ; and wherein the dynamic pricing algorithm comprises a time-based factor determined at least following periodic synchronisation between the bid management system and the bid processing engine of the or each client application.

[0007] 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.

[0008] Optionally, the client-side purchase action may be an immediate purchase action or a holding bid action.

[0009] 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.

[0010] Preferably, the real-time price value may have a minimum value of zero.

[0011] 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.

[0012] The bid management system may be optimised for high-frequency operations, storing holding bids, user data, and transaction logs.

[0013] 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.

[0014] Preferably, the dynamic pricing algorithm may include a market -parameter input for determining the adjustment to the real-time price value.

[0015] 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.

[0016] The bid processing engine may be configured to initiate the auction at a pre-defined starting price.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] The front-end visualization layer may be configured to display a highest holding bid in real-time.

[0021] 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.

[0022] Optionally, the client application may periodically synchronise the real-time price value with that of the bid management system.

[0023] 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.

[0024] The bid processing engine may pre-authorises a user payment prior to submitting a bid to the bid management system.

[0025] 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.

[0026] The software-based system may further comprise an e-commerce platform integration interface.

[0027] 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.

[0028] Notifications being issued via a separate server may reduce the burden on the bid management system.

[0029] The software-based system may further comprise a payment server configured to process payment.

[0030] There will likely be a discrete interface for management of payments, in order that the connectivity with existing payment providers can be utilised.

[0031] Optionally, the auction duration may be adjustable.

[0032] Preferably, the bid management system may apply leniency measures to accommodate any discrepancy between the server application and the at least one client application on completion of a client-side purchase action.

[0033] Optionally, the dynamic pricing algorithm may incorporate a dynamic demand coefficient determined based on at least one of: a bid frequency factor; a watcher engagement factor; a user interaction factor; and the time-based factor.

[0034] 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, and wherein the dynamic pricing algorithm comprises a time-based factor determined at least following periodic synchronisation between the bid management system and the bid processing engine of the or each client application. The present method allows for the implementation of a modified Dutch auction without causing database conflicts due to the synchronisation steps performed.

[0035] Optionally, the client-side purchase action may be an immediate purchase action or a holding bid action.

[0036] 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:

[0037] Figure 1 shows a diagrammatic representation of a first embodiment of a software-based system in accordance with the first aspect of the invention;

[0038] 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 ;

[0039] Figure 3 shows a representation of the front-end visualisation layer of Figure 2 in an expanded state;

[0040] 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;

[0041] Figure 4B shows a second part of the representation of Figure 4A;

[0042] Figure 4C shows a third part of the representation of Figures 4A and 4B; and

[0043] Figure 4D shows a third part of the representation of Figures 4A, 4B, and 4C.

[0044] Referring firstly to Figure 1 , there is indicated an indicative software-based system for implementing a modified Dutch auction, being referenced globally at 10.

[0045] 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.

[0046] 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. In this setting, a holding bid 22 is a placeholder, expressing interest by the participant for a particular price point which is less than the current price. If no-one purchases the item at the listed price, and the price descends to a level matching one or more of the holding bids 22, the bid-processing engine 14 will prioritize fulfilment of holding bids 22 in chronological order.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] There may also be a display portion 38 showing the current holding bids currently made against the listing 24.

[0053] 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 18, 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 18, 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] If pre-authorisation is successful, the bid processing engine 14 transfers the bid from the client application 42 to the bid management system 18, 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 18 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.

[0063] 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.

[0064] For each listing 24, the bid management system 18 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.

[0065] 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.

[0066] When the ‘Buy’ button is triggered, the user is able to purchase the listing 24, and as such, the bid management system 18 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.

[0067] 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.

[0068] The pre-authorisation confirmation is then sent to the bid management system 18, 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.

[0069] 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.

[0070] The determination of the price of a listing 24 over time is determined using several factors.

[0071] There is an initial demand coefficient, which is a predetermined coefficient which determines an initial rate of price descent. This coefficient may be determined via a market interest input, a market interest-adjusted demand input, and an auction performance input to calculate an accurate starting price descent rate based on anticipated demand.

[0072] The market interest input is an estimate of market interest, quantifying baseline interest in the item using historical sales and views from previous e-commerce sales data, serving as a predictor for auction engagement. This may be calculated initially as a ration between total sales and total views of the listing 24.

[0073] The market interest-adjusted demand input may be a normalised version of the market interest input, where the coefficient for the listing 24 is adjusted based on interest from similar listings.

[0074] The auction performance input may be quantified as an auction performance score which uses historical auction data to assess demand, integrating watcher count, bid activity, and final price ratios. This may be determined as a weighted score. An example contributory score may be a watcher score, where the number of current watchers is compared to historical averages. Another example contributory score may be a bid score, which is a measure of competitiveness on bid volume, where the number of bids is compared to an average number of bids on similar items. Another example contributory score may be a selling price score, where the item value is assessed based on past final prices relative to starting prices. The contributory scores may be weighted in any manner deemed appropriate.

[0075] There is also a dynamic demand coefficient, which is applied once the system 10 initiates the Dutch auction. This can be modified during the auction allowing real-time adjustments to the price descent rate based on one or more of ongoing user engagement, bid activity, and time remaining in the auction. This demand-responsive mechanism maintains an adaptive and competitive pace for the auction.

[0076] The dynamic demand coefficient includes data from real-time inputs to adjust the price descent accordingly. This can be modified based on, for instance: a bid frequency factor, proportional to a ratio of the number of bids received against an anticipated number of bids; a watcher engagement factor, proportional to a ratio of the number of watchers against an anticipated number of watchers; a user interaction factor, proportional to a ratio of the number of interaction received, such as clicks or views, against an anticipated number of interactions; or a time based factor, which is a function of a proportion of the time remaining.

[0077] Dynamic weighting of the various factors can be incorporated, allowing for real-time modification by the operator. This can result in the system 10 slowing descent during periods of high demand, accelerate descent when demand drops, and stabilise where applicable, automatically based on the inputs provided. The determination of expected data, such as the expected bids or expected watchers, is estimated based on several data sources. In particular, historical auction data will be used as the primary source of information, with additional modifiers applied, for instance, data relating to similar items or seasonal patterns. Current market information or trend data can also be used to modify the expected information.

[0078] There is further a client-side price calculation, in which the pricing adjustments are calculated directly on the client side, where each user’s device runs the dynamic pricing algorithm incorporating the dynamic demand coefficient independently. Periodic server synchronization ensures uniformity across all clients, even as they respond to real-time demand factors.

[0079] As noted, the client servers periodically synchronize with the server, which acts as a central clock - the so-called heartbeat synchronization. This process corrects minor timing and pricing drifts, ensuring that each client’s price remains aligned with the auction’s official status.

[0080] The timing from the heartbeat synchronization is used as a factor within the dynamic demand coefficient, in particular for the timing-based factor, which maintains accuracy despite the dynamic behaviour occurring on the client application 42.

[0081] Given the periodic synchronization between the server and the client, and the potential for some drift, the bid management system 18 applies leniency mechanisms to bid acceptance.

[0082] A tolerance range could be inbuilt as a precautionary measure, for example, in the form of a defined price margin allows bids that are close to the server’s official price to be accepted, accounting for minor client-side variations. This range might be 5-10% lower than the current server-calculated price. The bid management system 18 may adjust the tolerance margin based on network conditions, activity levels, or the auction phase, tightening the range during high activity periods to maintain tight price alignment and loosening slightly during lower activity.

[0083] Furthermore, there may be a delay mechanism applied when handling holding bids 22. When the descending price of the listing 24 reaches the level of an existing holding bid 22, there is a slight delay before automatically accepting the holding bid 22. During this delay, the bid management system 18 prioritizes any incoming Buy Now bids at the current, higher price point, allowing users who wish to buy immediately to secure the item over holding bidders. If no Buy Now bid arrives within this brief window, the bid management system 18 proceeds to fulfil the holding bid 24 in the order it was placed. This approach preserves the Buy Now option's immediacy and priority while also honouring the holding bids 24 if no immediate buyer steps forward. If bid cancellations are permitted, this also allows the holding bid 24 that was made to be cancelled right up until the point that the order would complete, allowing for network latency and delays.

[0084] This leniency ensures smooth bidding while preserving a competitive and fair auction environment. By verifying bids within an acceptable range, the bid management system 18 minimizes risks of manipulation while providing a consistent user experience.

[0085] 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.

[0086] Two possible mechanisms for handling the present invention could be considered, with different results on auction time modulation. The auction duration can be kept constant, or the auction duration can itself be made to be dynamic.

[0087] In the former approach, the auction duration remains fixed from the user’s perspective, regardless of adjustments made by the dynamic demand coefficient. Any impact the coefficient has on the price descent rate is balanced by compensatory speed adjustments to maintain the overall end time.

[0088] This could be achieved by adjusting descent rate in real-time, as the dynamic demand coefficient reacts to demand by slowing or speeding up the descent based on demand, with he changes being logged as adjustments. Alternatively, there could be compensation by future modulation, in which the bid management system 18 recalculates the rate of descent for the remaining auction time, balancing it to ensure the item reaches the minimum price threshold at the pre-defined end time. There could also be invisible adjustments, in which the auction timer remains constant, but the descent rate visibly fluctuates.

[0089] This approach has the advantage of being predictable to the end user, and users may be encouraged to bid at a premium since they are aware of when the auction will end based on current demand. This is, however, a more technically complex arrangement to adopt.

[0090] The alternative approach is to have a dynamic auction duration with visible timer adjustments. In this fully dynamic approach, auction duration adjusts based on live demand with no fixed end time. Instead, the dynamic demand coefficient actively modulates the auction’s progress, slowing down or accelerating the timer in real time based on user engagement and demand factors. This approach may display real-time adjustments to the user, or the timing changes can be partially hidden depending on the design.

[0091] This can be achieved by real-time timer modulation, for instance, where, during periods of high demand, the timer might slow, giving users more time to place competitive bids at higher prices and during periods of lower demand, the timer accelerates, bringing the auction closer to its conclusion and encouraging “Buy Now” actions or final bids. Furthermore, extensions can be provided to the auction if demand is high, continuing to slow the price descent to encourage bids. Conversely, if demand is low, the auction duration shortens as the timer moves quickly to completion.

[0092] This approach uses a visible, dynamic timer where users see the time remaining change in real-time based on demand, or a partially visible timer where only critical adjustments are shown. With a visible dynamic timer, users can directly see the effects of high demand as the timer slows, allowing them to react accordingly. With a partially visible timer, the auction may signal when high demand leads to an extension or low demand to a quicker end, but without showing every adjustment.

[0093] This approach has the advantage of being responsive to the demand in the auction, whilst remaining transparent and fair, since participants in the auction understand that their engagement directly affects auction duration, encouraging active bidding. Clear explanations to the participants would be necessary, however, where duration is altered.

[0094] The first approach provides better predictability for participants, whereas the second approach has greater flexibility and demand responsiveness, rewarding active participation.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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

CLAIMS1. A software-based system (10) for implementing a modified Dutch auction, the software-based system comprising: a server application (40) and at least one client application (42); wherein the or each client application (42) comprises: a front-end visualization layer (12) configured to display a realtime price value of a listing; a bid processing engine (14) designed to process client-side purchase actions; and a dynamic pricing algorithm (16) to adjust the real-time price value; and wherein the server application (40) comprises: a bid management system (18) communicable with the bid processing engine of the or each client application; wherein synchronisation between the bid management system (18) and the bid processing engine of the or each client application 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; and wherein the dynamic pricing algorithm (16) comprises a timebased factor determined at least following periodic synchronisation between the bid management system (18) and the bid processing engine of the or each client application.

2. A software-based system (10) 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 (10) as claimed in claim 1 or claim 2, wherein the realtime price value has a minimum value of zero.

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

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

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

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

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

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

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

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

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

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

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

15. A software-based system (10) as claimed in any one of the preceding claims, wherein the auction duration is adjustable.

16. A software-based system (10) as claimed in any one of the preceding claims, wherein the bid management system (18) applies leniency measures to accommodate any discrepancy between the server application (40) and the at least one client application (42) on completion of a client-side purchase action.

17. A software-based system (10) as claimed in any one of the preceding claims, wherein the dynamic pricing algorithm (16) incorporates a dynamic demand coefficient determined based on at least one of: a bid frequency factor; a watcher engagement factor; a user interaction factor; and the time-based factor.

18. A method for implementing a modified Dutch auction , the method comprising the steps of: a] displaying, at a front-end visualisation layer (12) of a client application (42), a real-time price value of a listing; b] processing, using a bid processing engine (14) of the client application (42), client-side purchase actions; c] adjusting the real-time price value using a dynamic pricing algorithm (16); and d] using a bid management system (18) of a server application (40) which is communicable with the client application (42), determining a status of the or each client-side purchase action, wherein synchronisation between the bid management system (18) 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 (40) and the client application (42), and wherein the dynamic pricing algorithm (16) comprises a time-based factor determined at least following periodic synchronisation between the bid management system and the bid processing engine (14) of the or each client application.

19. A method as claimed in claim 18, wherein the client-side purchase action is an immediate purchase action or a holding bid action.

Images