Autonomous queue management system

Abstract

An intelligent queue management system that dynamically assigns estimated processing times based on configurable settings and real-time queue data. It may introduce Queue Upgrade (QUP) rewards, which may enable controlled modifications to user positions while maintaining fairness. The system may prevent repeated position advancements over the same user, reallocate processing time based on real-time completion data, have integrated timestamp tracking, and may enhance efficiency through analytics and machine learning-driven optimizations. Additionally, this system may allow exporting rewards to a Solana-based cryptocurrency token, (e.g., QUP Coin), allowing users to cash in.

Description

TITLE:AUTONOMOUS QUEUE MANAGEMENT SYSTEM REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority from U.S. Provisional Application No.63 / 762,076 filed 02 / 23 / 2025, titled ‘'Autonomous Queue Management System with Dynamic Time-Based Priority, Real-Time Optimization, and Cryptocurrency- Integrated Reward System." tire entire contents of which are hereby incorporated herein by reference.FIELD OF THE INVENTION

[0002] This invention relates generally to autonomous queue management systems, more particularly to queue systems with automated: scheduling, queue management, dynamic prioritization, and cryptocurrency-based reward distribution.BACKGROUND OF THE INVENTION

[0003] Conventional queue management systems predominantly use a First-In-First- Out (FIFO) approach, which lacks adaptability and efficiency. Examples of existing queue management systems are taught by U.S. Pat. No. 6,529,786B1 and U.S. Pat. Pub. No. 2014 / 0089075A1. Some limitations of existing systems include:• Static wait times that fail to adjust dynamically.• Inability to allow flexible queue movement without compromising fairness. • Inefficient use of available processing capacity’ when tasks are completed earlier than expected.• Absence of real-time queue optimization teclmiques.• No mechanism to fairly compensate users who experience increased wait times due to queue reordering.

[0004] The present invention aims to address such shortcomings.SUMMARY OF THE INVENTION

[0005] The present invention is directed to systems and methods which provide an intelligent queue management system based on dynamic adjustability, fairness, and efficiency.

[0006] The invention relates to an intelligent queue management system that dynamically assigns estimated processing times based on configurable settings and real-time queue data. It may introduce Queue Upgrade Points (QUP), which may enable controlled modifications to user positions while maintaining fairness. The system may prevent repeated position advancements over the same user, reallocate processing time based on real-time completion data, have integrated timestamp tracking, and may enhance efficiency through analytics and machine learning-driven optimizations. Additionally, this system may incorporate a Solana-based cryptocurrency token, (such as QUP Coin), allowing users to receive rewards for being impacted by queue movements. These rewards may be held, staked to maintain value, or traded for real currency, resulting in a profit-sharing mechanism that ensures fair compensation for waiting times.

[0007] The invention introduces the following features:• Real-time processing and time calculations based on queue conditions. Dynamic estimation of processing times based on queue conditions.• Queue Upgrade Points (QUP) payment and reward system for controlled priority adjustments while maintaining fairness. Value of Time (VoT) ratings used to quantify value of movements, efficiencies, and timings of events.• Timestamp tracking for accurate queue analytics and real-time reporting.Timestamp logging for tracking queue events and optimizing performance. • Organically accumulating a pool of time from processing efficiency gains.• QUP (Queue-UP) movements are being absorbed into that pool without visibly impacting other users' displayed wait times. Controlled priority movement via QUP, ensuring fair queue adjustments.• Drift correction is actively preventing the pool from growing unrealistically large during low-QUP periods, keeping displayed times accurate.• Force QUP fallback is redistributing time proportionally when the pool is insufficient, with VoT scoring occurring per item. Reallocation of unused queue time to maintain efficiency.• Ledger balances are accruing for affected users simultaneously.• All of this is configurable per location and per queue mode and runs autonomously. Administrator adjustments and parameter settings are configurable.• Machine learning adaptability to refine estimated processing times based on historical data. Al-driven predictive modeling to enhance accuracy of estimated wait times.• API-based integration for seamless external application control.• A cryptocurrency-based reward system that compensates users affected by queue adjustments. A cryptocurrency-based reward system enabling users to receive, stake, or trade QUP Coin for real-world value.

[0008] QUP — Time-Based Autonomous Queuing Algorithm• Technical control of value of time• Auctioning time• Paying people fiat / cryptocurrency for loss of time• Gamification of queue position• Time pocket generating dynamic autonomous queuing like none other

[0009] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that tire conception andspecific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the scope of the invention as set forth in the appended claims. The novel features which are believed to be characteristic of the invention, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present invention.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated in and form part of the specification in which like numerals designate like parts, illustrate embodiments of the present invention and together with tire description, serve to explain the principles of the invention. In the drawings:

[0011] FIG. 1 is a simplified flow diagram illustrating Queue entry, QUP movement, and estimated time calculations according to an embodiment of the invention;

[0012] FIG. 2 is an simplified flowchart of a timestamp logging process according to an embodiment of the invention;

[0013] FIG. 3 is an simplified flowchart of a machine-leaming-driven, queueprediction model according to an embodiment of the invention;

[0014] FIG. 4 is an example flowchart of a reward-distribution model according to an embodiment of the invention;

[0015] FIG. 5 is a detailed flowchart of queue entry and QUP movement processes, and estimated time calculations according to an embodiment of the invention;

[0016] FIG. 6 is a detailed flowchart of a timestamp logging, buffering, pool accumulation, and drift correction processes according to an embodiment of the invention;

[0017] FIG. 7 is a detailed flowchart of a machine-leaming-driven, queue-prediction model according to an embodiment of the invention;

[0018] FIG. 8 is a detailed flowchart of an internal-ledger, reward-distribution model according to an embodiment of the invention; and

[0019] FIG. 9 is a detailed overview flowchart of a system architecture according to an embodiment of the invention.DETAILED DESCRIPTION

[0020] The present invention is applicable to industries with queues, such as, but not limited to:• Food and / or beverage ordering and pickup services• Event material ordering and pickup• Reservation systems• Healthcare appointment scheduling• Customer service and support operations• Logistics and supply chain management

[0021] A queue is a waiting line or ordered plurality of customers or users who have placed, or intend to place, an order for one or more items offered by a business or owner and are waiting for the order to be processed. The inventive queue management system links together softw are running on users’ devices and on an owner’s or business’s device or devices. The owner’s device carries out the management of the queue, and the users’ devices track or display the user's place in the queue, estimated time to be served, reward information, and provides user a means to provide input to the owner’s management system.

[0022] The primary focus of the invention is the dynamic autonomous queue management system running on the owner’s device. While other optional features such as the reward ledger and QUP Coin redemption pathway are useful and innovative features, the central innovation is the time-based, self-regulating queuemechanism. What makes this system distinct from all existing queue management systems is the simultaneous and continuous interaction of the following — all happening in real time, invisibly to the customer:• Pool time is organically accumulating from processing efficiency gains.• User-purchased QUP (Queue-UP) movements are being absorbed into that pool without visibly impacting other users' displayed wait times.• Drift correction is actively preventing the pool from growing unrealistically large during low-QUP periods, keeping displayed wait times accurate.• Force QUP fallback is redistributing time proportionally when the pool is insufficient.• Value of Time (‘"VoT”) scoring is occurring for each users’ position in the queue, also accounting for each item in a user’s order.• Ledger balances are simultaneously accruing for all users affected by Queue up movements.• All of this is configurable per location or business implementing it, and per queue mode.• Machine learning (ML) is taking building a queue history with which to automatically adjust parameters that optimize the queue management process.

[0023] No existing queue system manages tire appearance of wait time accuracy, the cost of movement, the payment for movement, and the reward for being impacted — all dynamically and simultaneously within a single autonomous time-based framework. That simultaneous self-regulation is the heart of tire invention. These concepts will be described in detail, then summarized again with reference to the Figures.

[0024] Queue Position & Time Estimation:

[0025] The system may calculate estimated processing times dynamically based on queue length and item complexity and historical processing times. Adjustments may occur in real time as queue conditions change. The system allows for any number offixed settings or real-time adjustments by an administrator based on configurable processing parameters. Processing parameters are system settings adjustable by an administrator including, but not limited to: base time per item (e.g., 60 seconds); overhead buffer percentage (e g., 10%); maximum pool time cap; drift correction threshold; reserve time cap; minimum element time; queue mode (FIFO, Super QUP, Hybrid. Chaos); and Force QUP enable / disable settings. Queue modes are explained further below in connection with Figure 1.

[0026] Queue Upgrade (QUP) System:

[0027] QUP (Queue-UP) is defined as a controlled queue movement operation in which a user advances forward one or more positions within the queue. A QUP operation is preferably executed using available pool time as currency. The system validates each QUP request against predefined constraints including pool time availability, bypass history, and processing order blocking rules before setting the price and executing the movement. Users may perform multiple QUPs within a single queue session subject to available pool time and system-enforced fairness rules.

[0028] Users may utilize a QUP system to advance their position within predefined limits or constraints. Constraints are rules governing QUP eligibility, including but not limited to: a prohibition on moving past a user already bypassed by the same requesting user in tire current session (bypass history enforcement); a prohibition on moving past orders currently in processing status by a bartender or sendee provider; geofence proximity requirements; a maximum number of positions or movement limit per QUP operation; and available pool time thresholds. The system thus ensures fairness, e.g., by preventing repeated advancements over the same individual, or extreme advances. When unused processing time becomes available, QUP moves may leverage this time before affecting other users' wait times or without affecting other users’ wait times. QUP moves may be paid for electronically with the local currency, or with accumulated reward points. Users negatively impacted by QUP movements may receive compensation in the form of reward points. The parameters of the system are set to insure that the QUP cost is sufficient to cover tire rewards to affected users and enough profit to tire system owner to keep it operational. It shouldbe noted that ledger balances may be accruing for affected users simultaneously. All of this is configurable per location and per queue mode.

[0029] Timestamp Tracking of Queue Event Data for Performance Analysis:

[0030] Timestamped records associated with each queue entry including: the time the order entered the queue (an entry timestamp); the time processing began (processing start timestamp); any pause and resume events during processing; the time the order was marked complete (completion timestamp); and any QUP or downward movement operations performed on that entry. Each queue entry may thus be associated with at least three key timestamps: an Estimated Start Time: (the projected time for processing commencement); a Pickup Acknowledgment Time (when the user confinns pickup or receipt of the items ordered); and a Completion Timestamp (when processing is finalized). Such logged timestamps may enable real-time queue optimization and historical performance analysis.

[0031] One application of the timestamp analysis is the ability for the system to redistribute unused processing time. When an order is completed faster than its estimated processing time, the difference between the estimated and actual duration is calculated. A portion of this saved time is added to the system's reserve pool and becomes available for future QUP operations, effectively converting efficiency gains into queue movement currency without impacting other users' displayed wait times.

[0032] Drift correction is actively preventing the pool from growing unrealistically large during low-QUP periods, thus keeping displayed times accurate. Some of the adjustable processing parameters mentioned above are used to manage the pool and drift, including maximum pool time cap, drift correction threshold, reserve time cap, minimum element time, and the like.

[0033] Force QUP fallback is redistributing increased wait times proportionally to tire users in tire queue when the time pool is insufficient or even exhausted altogether. Time is distributed in proportion to a user's VoT ranking, based on position in line, number and type of items, etc., with VoT scoring taking into account each item.

[0034] Machine Learning-Based Optimization:

[0035] The system may continuously analyze queue data to refine estimated wait times. Predictions may improve over time through historical pattern recognition. The analysis may utilize machine learning algorithms, artificial intelligence, or tire like.

[0036] The Reward System:

[0037] Users who experience extended wait times due to others utilizing QUP may receive reward points which may be accumulated and used within the system to purchase QUP moves or other benefits or physical items offered by the owner. In some embodiments, the reward points may transferred out of the system to be converted or redeemed for a form of cry ptocurrency, such as QUP Coin, as compensation. The converted values may be: held as an asset that fluctuates in value; staked to contribute to the ecosystem and maintain its value; traded for real currency or goods within other platforms. This mechanism of “cashing in?’ may ensure equitable redistribution of value and incentivize participation in the system.

[0038] The external cryptocurrency, such as QUP Coin, may be a Solana-based cryptocurrency token external to the QUP platform, representing the redeemable form of a user's accumulated internal ledger reward balance. The QUP Coin itself is not held, managed, or exchanged within the application. The application maintains only an internal ledger balance reflecting a user's earned reward points. Upon satisfying configurable eligibility and redemption rules, a user may coimect an external Phantom wallet and receive an airdrop of QUP Coin equivalent to the liquidity value of their ledger point balance, executed outside of the application. QUP Coin may subsequently be retained as a digital asset, staked within external ecosystem platforms to participate in value maintenance, or exchanged for real currency through external exchange mechanisms entirely separate from this platform.

[0039] API Control & Administrative Features:

[0040] The system may provide an API allowing third-party applications to manage queue settings. Administrators may override estimated processing times to accommodate operational needs. Third-party software systems that integrate with the queue management system via an API, include but are not limited to: point-of-salesystems; mobile ordering applications; bartender-facing workflow applications; venue management platforms; and payment processors.

[0041] FIG. 1 illustrates a simplified Queue Flowchart according to an embodiment of the inventive system. Each block represents a customer or user, number in their order of priority in the Queue. The upward arrow on the right indicates Queue User 9 paying a fee proportional to the VoT ratings of the eight Users ahead in the queue and advancing to the first position. The arrow on the left indicates Queue User 10 paying a fee proportional to the VoT ratings of the nine Users ahead in the queue and advancing to the first position ahead of User 9. The results could play out in a couple different ways. If the time pool was low, both moves may negatively affect the other users, and the two QUP fees may be then apportioned in turn among the skipped Users. User 9 may approximately break even, while User 10 ends up in the owing and the other Users all end up ahead in their point ledgers. If the time pool was sufficiently high, both moves may be accommodated without affecting the other users wait times. A third scenario is that tire first move has no effect on wait times, but tire second move does.

[0042] Figure 2 illustrates a simplified timestamp logging process according to an embodiment of the invention. Each order entry into the queue is associated with a series of timestamps that are recorded and stored automatically by the system throughout the lifecycle of that order. These timestamps serve as the foundation for real-time queue analytics, performance measurement, pool time calculations, and pickup accountability.

[0043] The process begins at the moment a user submits an order and joins the queue.The system records an Entry Timestamp 21 — the precise date and time the order entered the queue. This establishes the user's original position in time and sen es as the baseline for all subsequent wait time calculations. At entry the system may also calculate an estimated start time and / or an estimated processing time.

[0044] When a sendee provider begins processing tire order, the system records a Processing Start Timestamp 23. This marks the transition of the order from "waiting"status to "processing" status. Upon order completion, the system records a Completion Timestamp 27. A pickup acknowledgement 25 may also be logged.

[0045] The difference between the Processing Start Timestamp 23 and the Completion Timestamp 27 represents the actual processing duration. This actual duration is compared against the estimated processing time assigned to the order at entry. The result of this comparison drives two distinct pool time behaviors:

[0046] If the actual duration is less than the estimated duration, the difference is calculated as a time efficiency gain and a configurable portion of that gain is contributed to the system's reserve pool, making it available for future QUP (Queue- UP) operations by other users in the queue.

[0047] If the actual duration is greater than the estimated duration, tire system automatically draw s from the available pool time to absorb the overrun. This is a critical feature of the system — the pool time buffer is not solely for enabling forward movement by users, but equally sen es as a protective reserve that absorbs sendee slowdowns without visibly impacting the displayed wait times of other users in the queue. The customer may never see their estimated wait time increase simply because a prior order ran long, because the pool absorbs that variance transparently. Only in the event that the pool time has been fully consumed and the order is still not complete w ill the wait times of other users in the queue be visibly affected. This condition — pool exhaustion during an active processing overrun — is recorded by the system as a distinct event. The frequency, duration, and context of these events are logged for analytics purposes, enabling the system to adjust baseline time estimates and overhead buffer percentages over time to account for real-world service behavior. These performance statistics are also made available to location owners and administrators through reporting interfaces, providing visibility into sendee provider performance, process bottlenecks, and opportunities for operational improvement.

[0048] A Pickup Acknowledgment Timestamp 25 is recorded when the user confirms receipt of their completed order by pressing the PiQUP (pickup acknowledgment) button within the application. This acknow ledgment is not optional — it is a requiredaction by every user in the queue to confirm they have received their item . The PiQUP timestamp captures not only that the order was received, but precisely how long elapsed between order completion and customer pickup. This pickup duration data is stored and used for queue analytics, machine learning model refinement, and as a basis for incentivizing timely pickup behavior through QUP Coin ledger rewards or notifications. In the event a customer does not acknowledge pickup themselves, the service provider may record the PiQUP acknowledgment on their side of the system, noting that the item was handed out, ensuring the timestamp is captured regardless.

[0049] All timestamps — entry, processing start, pause and resume events, completion, and PiQUP acknowledgment — are stored in memory accessible to the owner’s device in association with the order's unique identifier and are used for: real-time remaining time calculations displayed to users, historical performance analysis and machine learning model training, pool time contribution and absorption calculations, pool exhaustion event tracking and analytics, Value-of-Time (VoT) score calculations for affected users, pickup behavior analytics and incentive calculations, and administrative reporting and queue optimization including owner-facing performance dashboards.

[0050] Figure 3 illustrates a machine-leaming-driven queue prediction model according to an embodiment of the invention. The system incorporates a machine learning engine that continuously refines estimated processing times based on historical performance data. The goal of this model is to produce increasingly accurate peritem time estimates that reflect real-world conditions at each specific service location, rather than relying on static administrator-configured base times alone.

[0051] The model ingests historical queue data 31 collected from the timestamp logging system described in Figure 2. For each completed order, the following variables are captured and stored as training data: the item name or identifier, the quantity of each item, the identity of the sendee provider w ho processed the order, tire time of day. the day of the week, the time of year, the queue length at tire time of processing, any special instructions associated w ith items, the actual processingduration recorded for that order, whether a pool exhaustion event occurred during processing, and the PiQUP pickup duration — the time elapsed between order completion and customer acknowledgment of receipt.

[0052] Using this data, the machine learning engine 33 builds and continuously updates per-item baseline time models. These baselines represent the learned average processing time for a specific item under specific conditions — for example, a particular drink made by a particular service provider during a Friday evening rush hour may have a different learned baseline than the same drink made on a Tuesday afternoon. The system supports per-location, per-item, per-service-provider. and per- time-period model granularity, configurable based on the volume of available training data.

[0053] When a new order enters tire queue 21, the prediction model queries the relevant learned baselines for each item in the order and aggregates them to produce a total estimated processing time for that order. A configurable buffer percentage is applied to each item and / or to this total estimate, creating the pool time contribution for that order. This pool of buffers sen es a dual purpose: it is the source of time that enables QUP (Queue-UP) forward movement operations, and it is the reserve that absorbs processing overruns to protect the displayed wait times of other users in the queue. Critically, the pool's protection of displayed wait times is absolute up to the point of hill pool exhaustion. Only if the pool is fully consumed while a processing overrun is still ongoing will other users experience a visible change to their displayed wait times. The system records each such pool exhaustion event and feeds this data back into tire machine learning model, allowing the buffer percentage to be automatically recalibrated over time to minimize the frequency of exhaustion events under real operating conditions. This is indicated as real-time queue adjustments 35 in FIG. 3, resulting in predicted wait times 37 and ultimately, queue optimization 39.

[0054] Figure 4 illustrates the process of Reward Distribution and Cry ptocurrency redemption according to an embodiment of the invention. When a QUP or Force QUP operation occurs, the payment is pure profit (block 45). Some goes to the owner customer, some to tire QUP system owner, some to cryptocurrency for future use.(Block 47). Some pays out rewards to affected users (block 41) which may be used within the system or redeemed for cryptocurrcncy in an outside system (block 43). SLA in block 49 means in this system a configurable maximum allowable drift between displayed wait times and actual real time — defined by an overhead setting. Example: 'if the queue drifts more than 10% beyond real time, act.

[0055] The ledger system calculates a Value-of-Time (VoT) score for each affected user on a scale such as a 1-100 scale. This score is determined by: (1) the number and complexity of items in the affected user's order, (2) the user's position in the queue, (3) the time of day (rush hour multipliers apply), (4) any special instructions associated with items, and (5) the duration of the time impact imposed by the QUP movement.

[0056] Each affected user's VoT score is recorded and stored as a ledger balance within the platform. The platform itself is not an exchange and does not hold, transfer, or manage actual cryptocurrency. Reward points exist solely as an internal ledger balance associated with the user's account within the application. No actual cryptocurrcncy is held, transferred, or managed within tire application itself.

[0057] Upon meeting a configurable set of eligibility rules governing usage thresholds, account standing, and redemption criteria, a user may elect to convert their accumulated ledger balance into actual cryptocurrency, such as QUP Coin — a Solana-based cryptocurrcncy token. At the point of conversion, the user connects an external Phantom wallet, and tire liquidity value equivalent of their ledger balance is airdropped directly to their wallet outside of the application. Once the airdrop is executed, the corresponding ledger balance is reduced accordingly. The platform facilitates the redemption event but does not operate as a cryptocurrency exchange, custodian, or wallet at any point in the process.

[0058] If the user who performed the QUP subsequently voluntarily moves back down in the queue, the VoT scores and associated time penalties are reversed, and any pending ledger balance accruals for affected users are recalculated accordingly.

[0059] Figure 5 illustrates a detailed Queue Flowchart according to an embodiment of the inventive system. The system begins when a user or customer enters the queue(block 100). Upon entry, the system dynamically calculates an estimated processing time (block 102) based on: (1) the number and type of items in tire order, (2) current queue length, (3) historical processing data for tire items based on machine learning (“ML”), and (4) a configurable buffer percentage applied to each item. This buffer creates what the system refers to as "pool time" — a shared reservoir of time available for queue movement operations. Efficiencies in processing can further add to the pool time. The system also assigns a queue position and timestamp (block 104), checks the drift level to see if the overhead threshold (or excess drift threshold) is exceeded (block 106). If so, adjustments are made to the queue, adjusting times from back to front, and QUP pricing is set (block 110)

[0060] When a user initiates a QUP (Queue-UP) operation (block 112), the system checks whether sufficient pool time exists to absorb the forward movement (block 104). If pool time is available, the user advances one or more positions without impacting tire visible wait times of other users (block 118 and 122). If pool time is insufficient (block 116), the system may either deny the movement (block 114) or, if administratively enabled, execute a Force QUP (block 120) — redistributing a proportional time penalty to affected users based on their item counts. Users impacted by a Force QUP may receive rewards or points proportional to the time impact and a Value-of-Time (VoT) score calculated per item. Ledger balances are adjusted (block 124) and if necessary, a drift correction applied (block 126).

[0061] The system continuously monitors the gap between estimated and actual processing times. When orders complete faster than estimated, the saved time flows into a reserve pool or the buffer. When the pool time drifts too far from realistic queue conditions (i.e., accumulates excess buffer with no QUP activity ), a Drift Correction is triggered — gradually trimming assigned times from the back of the queue forward until pool time realigns with actual queue work. Each users wait time is updated. This protects the customer experience by keeping displayed wait times accurate.

[0062] Queue modes available include: FIFO (standard first-in, first-out) (Block 108), Super QUP (pool-based priority movement), Hybrid (pool-preferred with Force QUP fallback), and Chaos (unrestricted movement).

[0063] Users can be required to remain within a configurable geofence of the service location to participate in queue operations.

[0064] Figure 6 illustrates a detailed timestamp logging process according to an embodiment of the invention. Each order entry into the queue is associated with a series of timestamps that are recorded and stored automatically by the system throughout the lifecycle of that order. These timestamps sen e as the foundation for real-time queue analytics, performance measurement, pool time calculations, and pickup accountability.

[0065] The process begins at the moment a user submits an order and joins the queue.The system records an Entry Timestamp 202 — the precise date and time the order entered the queue. This establishes the user's original position in time and serves as the baseline for all subsequent wait time calculations. At entry the system may also calculate an estimated start time and / or an estimated processing time.

[0066] When a service provider begins processing the order, the system records a Processing Start Timestamp 204. This marks the transition of the order from "waiting" status to "processing" status. If the service provider pauses processing for any reason, the system records a Pause Timestamp 208, and upon resumption records a Resume Timestamp. The cumulative duration of all pause intervals is tracked separately as total paused time, w hich is excluded from elapsed processing time calculations to maintain accuracy.

[0067] Upon order completion, the system records a Completion Timestamp 210. The difference between the Processing Start Timestamp 204 and the Completion Timestamp 210, net of any paused time 208, represents the actual processing duration. This actual duration is compared against the estimated processing time assigned to the order at entry 212. The result of this comparison drives two distinct pool time behaviors:

[0068] If the actual duration is less than the estimated duration 216, the difference is calculated as a time efficiency gain and a configurable portion of that gain is contributed to the system's reserve pool or buffer, making it available for future QUP (Queue-UP) operations by other users in tire queue.

[0069] If the actual duration is greater than the estimated duration 214, the system automatically draws from the available pool time to absorb the overrun. This is a critical feature of the system — the pool time buffer is not solely for enabling forward movement by users, but equally serves as a protective reserve that absorbs service slowdowns without visibly impacting the displayed wait times of other users in the queue. The customer may never see their estimated wait time increase simply because a prior order ran long, because the pool absorbs that variance transparently. Only in the event that the pool time has been fully consumed and the order is still not complete will the wait times of other users in the queue be visibly affected. This condition — pool exhaustion during an active processing overrun — is recorded by the system as a distinct event. The frequency, duration, and context of these events are logged for analytics purposes, enabling the system to adjust baseline time estimates and overhead buffer percentages over time to account for real-world service behavior. These performance statistics are also made available to location owners and administrators through reporting interfaces, providing visibility into service provider performance, process bottlenecks, and opportunities for operational improvement.

[0070] A Pickup Acknowledgment Timestamp also is recorded when the user confirms receipt of their completed order by pressing the PiQUP (pickup acknowledgment) button within the application. This acknowledgment is not optional — it is a required action by every user in the queue to confirm they have received their item . The PiQUP timestamp captures not only that the order was received, but precisely how long elapsed between order completion and customer pickup. This pickup duration data is stored and used for queue analytics, machine learning model refinement, and as a basis for incentivizing timely pickup behavior through QUP Coin ledger rewards or notifications. In the event a customer does not acknowledge pickup themselves, the service provider may record the PiQUP acknowledgment on their side of thesystem, noting that the item was handed out, ensuring the timestamp is captured regardless. Drift is again checked 220 and corrections applied if needed.

[0071] All timestamps — entry, processing start, pause and resume events, completion, and PiQUP acknowledgment — are stored 222 in association with the order's unique identifier and are used for: real-time remaining time calculations displayed to users, historical performance analysis and machine learning model training, pool time contribution and absorption calculations, pool exhaustion event tracking and analytics, Value-of-Time (VoT) score calculations for affected users, pickup behavior analytics and incentive calculations, and administrative reporting and queue optimization including owner-facing performance dashboards.

[0072] FIG. 7 illustrates a more detailed machine-leaming-driven queue prediction model according to an embodiment of the invention. The system incorporates a machine learning engine that continuously refines estimated processing times based on historical performance data. The goal of this model is to produce increasingly accurate per-item time estimates that reflect real-world conditions at each specific service location, rather than relying on static administrator-configured base times alone.

[0073] Input Variables the Model Learns From (Ref. 302): The ML model is trained on a rich set of variables captured per item and per order: item type and complexity category’, individual operator / server ID, physical location ID, time of day, time of year (seasonality), day of week, and historical QUP frequency at that location. Each variable independently affects processing time. A Monday morning rush differs from a Friday evening. One bartender runs 20% faster than another. Seasonal specials take longer. The model learns all of these patterns simultaneously. Early in a location's life, the model starts with seeded category-level baselines and graduates to precise location-specific and operator-specific estimates as data accumulates over weeks and months.

[0074] Confidence Gating & Live Deployment (Ref. 306-312): The model outputs a point estimate and a confidence interval. Only when confidence exceeds a configurable threshold is the updated estimate pushed live to the queue. If confidenceis below threshold, the system falls back to the last known good estimate or a rulebased baseline for that item category — ensuring a poorly -trained early model cannot destabilize the live queue. Once deployed, updated estimates flow to all downstream queue items in real time. A more accurate estimate for item type X updates every pending X in the queue immediately, tightening pool dynamics across the board.

[0075] Continuous Retraining & the Adoption Flywheel (Ref. 314-318): Every completed item generates a training signal: A_pred = actual time - predicted time. This is logged per item, per operator, and per location. When enough new data accumulates — or when prediction error consistently exceeds a configurable threshold — the model retrains automatically using the latest data. The retrained model is validated against held-out recent data before being deployed. This prevents regressions where a new model performs worse than tire existing one on recent queue patterns. Over time, tighter predictions enable admins to reduce the buffer % — less padding needed means the pool grows more slowly but displayed wait times arc more accurate. This is the intended steady-state: high-confidence estimates, minimal buffer, precise pool, accurate UX. Future versions may support operator-level personalization models: if a specific operator consistently completes items 15% faster than the location average, their personal model adjusts estimates for their shift automatically, providing even greater pool precision.

[0076] Figure 8 illustrates die ledger process 410. Within the application, there is zero actual cryptocurrency. The platform is not a crypto exchange and never touches a blockchain. Reward balances are a pure internal ledger of value — functionally identical to a points or credits system. Users can opt in to a mode where their ledger balance is expressed in terms of the liquidity value (not market price) of QUP Coin. This is a valuation peg only — no coins are held in the app. Example: User has a ledger balance worth $0.01. The operator puts 10% of every QUP fee into the QUP Coin liquidity pool from their own profits. As more users adopt the app and more QUPs are purchased, the liquidity grows — and that same balance might be worth $0.10 tomorrow. The ledger number did not change; the value it represents did. This creates a powerful network effect: more users — > more QUPs — > more liquidity — > higher ledger value for everyone — > incentive to recruit more users.

[0077] VoT (Value of Time) rewards are ONLY issued when a user's actual displayed wait time is genuinely impacted by a QUP movement (404-406). Pool-absorbed QUP: downstream users' displayed wait times do NOT change no VoT reward issued. They were not impacted. This is tire preferred path — free movement, no reward cost. Force QUP Fallback: pool is insufficient — wait time IS redistributed proportionally to downstream users —>■ they ARE impacted — > VoT fires per item in each affected user's order — > ledger balances accrue. This distinction is essential for the economics: pool absorption allows frequent QUPs at low cost to the reward system. Force fallback is the safety valve that ensures impacted users are always compensated when it does happen.

[0078] PerQUP is a configurable mechanism that distributes a portion of each QUP purchase price as ledger value to the users positioned directly behind the QUP purchaser. Example: User pays $30 for a QUP. 9 users are behind them. Operator configures PerQUP at $0.50 / pcrson. $4.50 total distributes as $0.50 in ledger credits to each of those 9 users. The remaining $25.50 is operator revenue or routed to the liquidity pool. All PerQUP parameters — amount per person, toggle on / off, cap per QUP event — are fully configurable per location by the administrator 424.

[0079] If a user wants to realize the value of their ledger balance, they attach an external crypto wallet to their account 416. This step is entirely optional and happens outside the application. The platform then sends the liquidity value (not market value) of QUP Coin directly to that external wallet. The app itself never holds, moves, or exchanges actual cryptocurrency — it records a ledger balance and coordinates an outbound external transfer. This architecture is intentional: because no crypto exchange activity occurs within the platform, the application does not require a cryptocurrency exchange license or related regulatory registration in any jurisdiction.

[0080] When a Force QUP operation occurs, the system calculates a Value-of-Time (VoT) score for each affected user on a scale such as a 1-100 scale. This score is determined by: (1) the number and complexity of items in tire affected user's order, (2) the user's position in the queue, (3) the time of day (rush hour multipliers apply),(4) any special instructions associated with items, and (5) the duration of the time impact imposed by the QUP movement.

[0081] Each affected user's VoT score is recorded and stored as a ledger balance within the platform. The platform itself is not an exchange and does not hold, transfer, or manage actual cryptocurrency. Reward points exist solely as an internal ledger balance associated with the user's account within the application. No actual cryptocurrency is held, transferred, or managed within tire application itself.

[0082] Upon meeting a configurable set of eligibility rules governing usage thresholds, account standing, and redemption criteria, a user may elect to convert their accumulated ledger balance into actual cryptocurrency, such as QUP Coin — a Solana-based cryptocurrency token. At the point of conversion, the user connects an external Phantom wallet, and the liquidity value equivalent of their ledger balance is airdropped directly to their wallet outside of the application. Once the airdrop is executed, the corresponding ledger balance is reduced accordingly. The platform facilitates the redemption event but does not operate as a cryptocurrency exchange, custodian, or wallet at any point in the process.

[0083] If the user who performed the QUP subsequently voluntarily moves back down in tire queue, the VoT scores and associated time penalties are reversed, and any pending ledger balance accruals for affected users are recalculated accordingly.

[0084] Figure 9 illustrates the overall architecture of an embodiment of the inventive system. Every component is downstream of tire Queue Engine 504. It is the sole authority for queue state, position management, pool balance, SLA drift monitoring, and all QUP rule enforcement. Rules enforced by the engine include: SLA drift thresholds, bypass history (cannot skip the same person twice in one session), pool availability checks, force fallback logic, drift correction. VoT scoring, and ledger accrual triggers. All behaviors are configurable per location and per queue mode via the Admin / Config Layer (Ref. 514). The same engine can power a coffee bar queue and a hospital appointment system with completely different parameter sets — no code changes.

[0085] All external clients — mobile apps, web browsers, third-party POS systems — communicate exclusively through the API Gateway 502. No direct database access is allowed from external sources. The gateway handles authentication, rate limiting, and real-time admin override commands. Admins can adjust estimated processing times, toggle QUP pricing, or change SLA thresholds live without restarting or disrupting the queue. The API-first design allows healthcare, event management, food service, and logistics platforms to integrate the same queue engine without modification — simply by connecting to the documented API endpoints.

[0086] A dedicated Timestamp Service 506 handles all event logging independently of the Queue Engine, ensuring high-volume logging never introduces latency into core queue operations. Every queue event — entry, processing start, any pause / resume, completion — is recorded with precision. This feeds both the real-time drift correction mechanism and the batch ML training pipeline. The timestamp data store is also the source for all analytics reporting, audit trails, and historical performance review accessible to administrators.

[0087] The ML engine 508 runs completely asynchronously — it never blocks queue operations. It reads from the timestamp analytics store in batch, retrains on a configurable schedule, and pushes validated estimates back to the Queue Engine. New locations start with category-level seeded estimates and transition to precise location-specific learned models as data accumulates. Confidence scoring gates whether a new model is deployed live or held for further training. This prevents early-stage models from destabilizing queue estimates before sufficient data has been collected.

[0088] The Reward Ledger Module 510-518 maintains internal balances only — it has zero connection to any blockchain during normal operation. No crypto is held, moved, or referenced by the app itself. Only when a user initiates a voluntary redemption does the system coordinate with an external payment processor (Ref. 516) for fiat-side transactions, or communicate with the user's personal external wallet for QUP Coin value transfer (Ref. 518). The connection to Solana (Ref. 518) is strictly one-directional and user-initiated: the app pushes an outbound transfer to a user-provided wallet address. The app receives nothing back and holds no funds at any point.

[0089] Future enhancements may include external factor integration (e.g., traffic conditions, order complexity, real-time demand fluctuations).

[0090] Existing queue management patents, such as US6529786B1 and US20140089075A1, provide foundational queue systems but lack:• Dynamic QUP -based priority movement with fairness safeguards.• Al-driven queue time prediction based on historical data analysis.• Timestamp tracking for queue efficiency analytics and real-time optimization. • Configurable queue time reallocation mechanisms to maximize operational efficiency.• A cryptocurrency-integrated compensation system for affected queue participants.

[0091] This invention introduces but is not limited to, an intelligent, adaptable queue management approach with innovations not currently covered by existing patents.

[0092] The Autonomous Queue Management System may enhance, queue efficiency through Al-driven optimizations, real-time processing estimates, QUP -based movement, timestamp tracking, and cryptocurrency integration. By dynamically adjusting queue conditions based on real-time and historical data, and introducing a fair compensation system, the platform may ensure efficiency, fairness, and financial incentives for all users.

[0093] In summary’, the invention relates to the following:

[0094] A queue management system that dynamically? determines estimated wait times based on real-time queue conditions and configurable processing parameters.

[0095] A priority movement mechanism that determines a cost of movement, accepts pay ment for movement, and compensates for the negative impacts of movement.

[0096] A priority movement mechanism utilizing reward points to allow controlled queue adjustments within predefined constraints.

[0097] A timestamp tracking framework that records and utilizes queue event data for analytics and operational optimizations.

[0098] A real-time queue time reallocation system that efficiently redistributes unused processing time.

[0099] An API-based interface that enables external applications to integrate queue management functionalities.

[0100] An Al-driven system that continuously refines estimated queue processing times through historical data analysis.

[0101] A configurable administrative module that allows manual queue adjustments while preserving default system intelligence.

[0102] A point-based reward system that compensates users impacted by queue movements with points, a currency such as QUP Coin.

[0103] A redemption mechanism that allows users to stake, hold, or trade points outside the app for a cryptocurrency such as QUP Coin, or for real-world value.

[0104] A method for managing a queue comprising:receiving at an owner device input from a user device when the user enters the queue and logging an entry time;calculating an estimated processing time that includes a predetennined buffer time; adding the buffer time to a time pool;logging a completion time and calculating the actual processing time; if the estimated processing time is less than the actual processing time deducting the difference from the time pool; and if the estimated processing time is greater than the actual processing time adding the difference to the time pool;

[0105] The method of claim 11 further comprising:offering tire user a movement forward in the queue for a payment based on the number of positions to be advanced;upon the user accepting the offer, calculating an effect of the movement on the others in the queue and deducting tire cumulative effects from the time pool; and if the time pool is not exhausted, not adjusting the others individual waiting times, but if the timepool is exhausted, adding time proportionately to the others individual waiting times and paying reward points to the others as compensation.

[0106] The method of claim 12 wherein the payment is a system of reward points

[0107] The method of claim 13 further comprising recalculating and redisplaying all estimated processing times in the queue if the pool time exceeds a predetermined maximum threshold or falls below a predetermined minimum threshold.

[0108] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the scope of the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of tire process, machine, manufacture, composition of matter, means, methods, and steps described in tire specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps. The invention disclosed herein may suitably be practiced in the absence of any element that is not specifically disclosed herein.

Claims

CLAIMS1. A computer-implemented method for managing a queue, the method comprising:receiving, by a queue management system, a request from a user device to enter a queue, and recording an entry timestamp;calculating, by the queue management system, an estimated processing time for the user based on item type and a configurable buffer percentage;initializing, by the queue management system, a time pool and accumulating surplus time units into the time pool when an actual processing time for any queue entry is less than the corresponding estimated processing time;receiving, from the user device, a request to advance the user's position in the queue via a Queue Upgrade (QUP) transaction;determining, by the queue management system, whether the time pool contains sufficient surplus time to absorb the positional advancement;if the time pool is sufficient, advancing the user's position by skipping the user past at least one complete downstream queue entry without modifying the displayed estimated wait times of other users in the queue; andif the time pool is insufficient, advancing the user's position and redistributing the remaining wait time proportionally among affected queue users, and issuing reward ledger credits to the affected users based on a calculated Value of Time (VoT) score.

2. The method of claim 1, further comprising:monitoring a drift value representing divergence between cumulative estimated processing times and cumulative actual processing times; andREPLACEMENT SHEET (Rule 26)when the drift value exceeds a configurable overhead threshold, performing a drift correction operation that adjusts the time pool balance from back-to-front across the queue to prevent over-inflation of the pool.

3. The method of claim 1, further comprising:logging, by a timestamp service, a queue-entry event, a processing-start event, any pause and resume events, and a completion event for each queue entry;computing a delta time value as the difference between the buffered allotted time and the actual processing time; andwriting an analytics record comprising the delta time, pool balance, and VoT scores to a persistent data store.

4. The method of claim 1, wherein calculating the estimated processing time comprises: inputting item-type data, operator identifier, physical location identifier, time-of-day, and historical queue frequency into a trained machine learning model;receiving from the model a point estimate and confidence interval for the processing time; andif the model confidence falls below a threshold, substituting a rule-based fallback estimate.

5. The method of claim 4, further comprising:capturing a deviation between the predicted processing time and the actual processing time per item, per operator, and per location; andretraining the machine learning model when accumulated deviations meet a configurable retraining threshold.REPLACEMENT SHEET (Rule 26)6. The method of claim 1, wherein the VoT score is computed as a function of the QUP price, the number of positions passed, and the estimated wait time delta for each affected queue user, and wherein ledger balances for all affected users accrue simultaneously in an internal reward ledger.

7. The method of claim 6, further comprising:enabling a user to redeem an accumulated internal ledger balance by attaching an external wallet to receive a liquidity value; orapplying the accumulated balance as a credit toward future QUP transactions within the platform; orholding the balance in the internal ledger as the balance grows with platform liquidity.

8. The method of claim 1, wherein all queue parameters including buffer percentage per item type, QUP pricing rate, overhead threshold, and reward distribution settings are configurable on a per-location and per-queue-mode basis through an administrative configuration layer.

9. A queue management system comprising:one or more processors; andone or more non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the system to:receive a queue entry request from a user device and record an entry timestamp; calculate an estimated processing time for the user's queue entry using a configurable buffer percentage;REPLACEMENT SHEET (Rule 26)maintain a time pool and accumulate surplus time units into the time pool as queue entries complete in less than their estimated processing time;receive a Queue Upgrade (QUP) request from the user device and determine whether the time pool contains sufficient time to absorb the corresponding positional advancement;upon determination that the time pool is sufficient, advance the user's position past at least one complete downstream queue entry without altering the displayed wait times of other users; andupon determination that the time pool is insufficient, advance the user's position, redistribute remaining wait time proportionally to affected users, and issue Value of Time (VoT)-based reward credits to those users via an internal reward ledger.

10. The system of claim 9, wherein the instructions further cause the system to:monitor a drift value representing divergence between cumulative estimated and actual processing times; andwhen the drift value exceeds a configurable overhead threshold, execute a drift correction operation adjusting the time pool balance from back-to-front across the queue.

11. The system of claim 9, further comprising a timestamp service configured to:log queue-entry, processing-start, pause, resume, and completion events for each queue entry; andcompute a delta time value as the difference between the buffered allotted time and the actual processing time for each queue entry.

12. The system of claim 9, further comprising a machine learning prediction module configured to:REPLACEMENT SHEET (Rule 26)accept as input at least item type, operator identifier, location identifier, and time-of-day features;output a predicted processing time and confidence interval using a gradient boosted regression or neural network model; andrevert to a rule-based fallback estimate when model confidence falls below a configurable threshold.

13. The system of claim 9, further comprising a reward ledger module configured to:maintain internal ledger balances for each queue user reflecting accrued VoT-based rewards;distribute per-QUP credits to affected users on a configurable per-user basis; and facilitate outbound transmission of liquidity value to a user's external wallet upon user request.

14. The system of claim 9, further comprising a configuration and administration layer configurable on a per-location and per-queue-mode basis and comprising settings for buffer percentage per item type, QUP price rate of increase, overhead percentage threshold, and reward distribution parameters.

15. The system of claim 9, further comprising an API gateway configured to authenticate external applications and receive administrative override commands to control queue parameters programmatically.

16. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause a queue management system to:REPLACEMENT SHEET (Rule 26)record an entry timestamp and calculate an estimated processing time including a configurable buffer percentage when a user enters a queue;accumulate surplus time units into a time pool when any queue entry completes in less than its estimated processing time;receive a Queue Upgrade (QUP) request from a user to advance the user's position in the queue;determine whether the time pool contains sufficient surplus time to absorb the positional advancement;if the time pool is sufficient, advance the user's position past at least one complete downstream queue entry without modifying the displayed wait times of other users; and if the time pool is insufficient, advance the user's position, redistribute the time deficit proportionally among affected users, and issue Value of Time (VoT)-based reward credits to affected users via an internal reward ledger.

17. The one or more computer-readable media of claim 16, wherein the instructions further cause the system to:continuously monitor a drift value reflecting divergence between cumulative estimated and actual processing times; andwhen the drift value exceeds a configurable overhead threshold, apply a drift correction adjusting the time pool balance from the back of the queue toward the front.

18. The one or more computer-readable media of claim 16, wherein the instructions further cause the system to:log event timestamps for queue entry, processing start, any pauses and resumes, and processing completion; andREPLACEMENT SHEET (Rule 26)compute a per-entry delta time as the difference between the buffered allotted time and the actual processing time and write analytics records to a persistent data store.

19. The one or more computer-readable media of claim 16, wherein the instructions further cause the system to:input queue features including item type, operator identifier, physical location identifier, and time-of-day into a trained machine learning model;receive a predicted processing time and confidence interval from the model; and substitute a rule-based fallback estimate when the model confidence falls below a configurable threshold.

20. The one or more computer-readable media of claim 16, wherein the instructions further cause the system to:calculate a VoT score for each affected user as a function of QUP price, positions passed, and estimated wait time delta;accrue reward ledger balances simultaneously for all affected users; andupon user request, transmit a liquidity value corresponding to the accrued balance to the user's external wallet or apply the balance as credit toward future QUP transactions within the platform.REPLACEMENT SHEET (Rule 26)

Images