BIDS FOR PURCHASE

BACKGROUND

[001] Embodiments of the invention described in this specification relate generally to a smart phone application to allow sophisticated (unique) paid restaurant bookings, sale of the booked position and associated refund/cancellation methods, and more particularly, to a mobile smartphone application implementation (“mobile app”) of a paid booking queue position sales system and process for making a hospitality business patron waiting queue position open to bids for purchase, with associated refund and cancellation methods and development of a virtual micro-marketplace for queue position sales, purchases, trading, swapping, and compensating, or otherwise enabling the free trade of queue positions in particular hospitality business patron waiting queues.

[002] Traditional queuing approaches involve people lining up and waiting for seating or entry into an event or location. In some cases, traditional queuing approaches work fine, especially when patrons in the queue do not have to wait very long. However, the wait times involved in queuing are often too lengthy for some patrons, especially those patrons in a hurry, under a time constraint, or otherwise unable to wait out the time for flowing through the queue. For example, some restaurants are popular enough that they routinely need to book queue positions for patrons looking to be seated at the restaurant. The queue positions are booked in the normal way by a patron telling a restaurant host his or her name, and a number of people in the patron’s party (e.g., seating a group of four at a table or just seating a single lone patron at a table or bar stool, etc.). Presently, there are conventional websites and restaurant booking applications that help patrons to book queue positions and which help restaurants and other hospitality -related businesses to manage their booking queues. However, none of the existing conventional booking sites/apps or any other applications or booking systems support features that allow a patron to purchase or sell a particular position in the line. This remains an ongoing problem for many patrons, restaurants, and other hospitality -related businesses.

[003] Therefore, what is needed is a way to enhance traditional queuing approaches with the ability of users to purchase or sell booked positions in a queue, thereby resolving the issue of having to wait for people when there are long lines in a restaurant as it allows the one (or more) people to be immediately seated. BRIEF DESCRIPTION

[004] A novel paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase are disclosed, with associated refund and cancellation methods and development of a virtual micro-marketplace for queue position sales, purchases, trading, swapping, and compensating, or otherwise enabling the free trade of queue positions in particular hospitality business patron waiting queues.

[005] In some embodiments, the paid booking queue position sales processes for making a hospitality business patron waiting queue position open to bids for purchase include (i) a paid booking queue salable position sales process for booking a salable queue position in a bookable patron waiting queue, (ii) a paid booking queue salable position sales process for making available for sale and purchasing a previously booked, salable queue position between multiple users, and (iii) a non-salable queue position bidding process for making a bid to purchase a non-salable queue position. In some embodiments, the paid booking queue position sales processes for making a hospitality business patron waiting queue position open to bids for purchase trigger transactions and compensation exchanges by way of one or more e-wallet transaction processes.

[006] In some embodiments, the paid booking queue position sales system is a networked cloud-computing system that hosts a cloud-based virtual booking queue position micro-marketplace and a paid booking queue selling, purchasing, bidding, compensating, and swapping cloud application service.

[007] The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this specification. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, Detailed Description, and Drawings is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, Detailed Description, and Drawings, but rather are to be defined by the appended claims, because the claimed subject matter can be embodied in other specific forms without departing from the spirit of the subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[008] Having described the invention in general terms, reference is now made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:

[009] Figure 1 conceptually illustrates a paid booking queue salable position sales process for booking, by a first user, a salable queue position in a bookable patron waiting queue in some embodiments.

[0010] Figure 2 conceptually illustrates the paid booking queue salable position sales process of Figure 1 for purchasing, by a second user, the salable queue position booked by the first user, and making, by the second user, the salable queue position purchased by the second user available for sale to a third user in some embodiments.

[0011] Figure 3 conceptually illustrates an e-wallet transaction process in some embodiments for compensating the first user, the second user, and a restaurant for the sale of the salable queue position from the first user to the second user and from the second user to the third user, in connection with the paid booking queue salable position sales process of Figures 1-2.

[0012] Figure 4 conceptually illustrates a non-salable queue position bidding process in some embodiments for making a bid, by a third user, to purchase a non-salable queue position held by a second user who purchased the queue position as a salable queue position from a first user who booked the salable queue position from a restaurant.

[0013] Figure 5 conceptually illustrates an e-wallet compensation movement process in some embodiments for compensating the second user and the restaurant for the sale of the non-salable queue position to the third user at the accepted bid price, in connection with the non- salable queue position bidding process of Figure 4.

[0014] Figure 6 conceptually illustrates a network architecture of a paid booking queue position sales system that hosts a cloud-based virtual booking queue position micro marketplace and a paid booking queue selling, purchasing, bidding, compensating, and swapping cloud application service in some embodiments.

[0015] Figure 7 conceptually illustrates an electronic system with which some embodiments of the invention are implemented.

DETAILED DESCRIPTION

[0016] In the following detailed description of the invention, numerous details, examples, and embodiments of the invention are described. However, it will be clear and apparent to one skilled in the art that the invention is not limited to the embodiments set forth and that the invention can be adapted for any of several applications.

[0017] Some embodiments include a paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase, with associated refund and cancellation methods and development of a virtual micro marketplace for queue position sales, purchases, trading, swapping, and compensating, or otherwise enabling the free trade of queue positions in particular hospitality business patron waiting queues.

[0018] In some embodiments, the paid booking queue position sales processes for making a hospitality business patron waiting queue position open to bids for purchase include (i) a paid booking queue salable position sales process for booking a salable queue position in a bookable patron waiting queue, (ii) a paid booking queue salable position sales process for making available for sale and purchasing a previously booked, salable queue position between multiple users, and (iii) a non-salable queue position bidding process for making a bid to purchase a non-salable queue position. In some embodiments, the paid booking queue position sales processes for making a hospitality business patron waiting queue position open to bids for purchase trigger transactions and compensation exchanges by way of one or more e-wallet transaction processes.

[0019] In some embodiments, the paid booking queue position sales system is a networked cloud-computing system that hosts a cloud-based virtual booking queue position micro-marketplace and a paid booking queue selling, purchasing, bidding, compensating, and swapping cloud application service.

[0020] Embodiments of the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase described in this specification solve the ongoing issues and problems of conventional queuing practices in the hospitality industry by way of a smartphone mobile app implementation of a paid booking queue position sales process for making a queue position (such as in a restaurant waiting for a free table) open to bids for purchase, with associated refund and cancellation methods and development of a virtual micro-marketplace for queue position sales/purchases/trading/compensation, and otherwise enabling the free trade of queue positions in particular queues. In this way, patrons (or “users”) can just interact with the mobile app running on their iOS or Android smartphone (or tablet mobile device) to electronically jump to the front of the line (or nearer to the front of the line) through a simple purchase or bidding/acceptance payment process without any human interaction.

[0021] Embodiments of the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase described in this specification differ from and improve upon currently existing booking queue approaches used by restaurants and other hospitality-related businesses. Examples of other hospitality-related businesses that may employ conventional patron queuing practices include, without limitation, technical support queues at commercial electronics businesses, vehicle repair and maintenance queues services by mechanics or auto servicing businesses, government documentation and licensing queues at government and government-servicing organizations, etc. In particular, there are websites and restaurant booking applications, but none of them allow such flexibility for users to purchase or bid on a position in order to move around within the line (or queue itself). While many users may wish to move ahead in the queue, and thereby reduce their waiting time, some users may wish to strategically swap positions for a fee, or purchase a later position in the queue when already holding a book position in the queue that is much nearer to the front. This flexibility in queue movement and management is all handled by backend queue management and, in some embodiments, a virtual cloud-based micro-marketplace in which queue sales, trades, swaps, purchases, bids, and follow-up compensation transactions are managed in an open, user-driven manner (via mobile app interactions of users).

[0022] In addition, some embodiments improve upon the currently existing booking systems which do not adequately account for growing needs of users to be seated from the increasing number of people in the restaurant line especially in busy restaurants / evenings. In contrast, the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase of the present disclosure provides features and functions that easily allow for users to be to able to buy positions ahead of their current position or at the front of the queue and/or sell their position in the queue, or swap positions as desired. Furthermore, the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase maintains traditional queue functionality in that it also allows queuing to proceed conventionally, when users do not engage with buying, selling, swapping, or otherwise exchanging or obtaining preferred positions that are nearer to the front of the queue. [0023] In some embodiments, there are several key aspects that differentiate between variations of the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase (and also differentiate from the conventional queuing approaches). One such differentiation is that the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase supports both manual sales and automatic sales of queue positions. Specifically, this differentiation is based on the ability for salable positions to be automatically sold or manually accepted by the user and/or the restaurant (or other such hospitality-related business). Technically, there is a distinction in that manual sale allows the owner of the position to control the sale, while automatic sale removes the power of the owner of the position to control the sale. This distinction is useful for different reasons — on the one hand, it is useful for the owners of positions, and on the other hand, it is a useful distinction for restaurants which may obtain benefits from position sales (e.g., a transaction fee or courtesy charge for an automatic sale, etc.).

[0024] Another such differentiation is that a bid (which may include a swap option too) is possible in lieu of a straight purchase of an available queue position. The bidding is supported by a backend virtual cloud-based micro-marketplace in which registered users can make bids of queue positions that have been booked (or allocated) to specific other users already, or may make bids pre -booking stage, such as bidding directly to a restautant for a particular paid booking queue position, at a specific date and/or time. Accordingly, the ability for people to bid with money (or other e-funds) and also to swap their own position out with the holder of the position is also supported. In some embodiments, the swapping of queue positions only works when both the swap-requesting user and the swap-considering user have previously booked a queue position. The swapping feature may also be an added incentive for people who still want to have dinner at a restaurant but who do not mind waiting longer if they benefit financially from selling their current booked queue position to a highest bidder and then getting a new updated queue position at the end of the queue, or swapping their current booked queue position to a user with a booked queue position that is much father away from the front of the line (and resulting in the inevitable outcome of having to wait to eat later).

[0025] Yet another point of differentiation is provided by way of a timing control aspect. A restaurant (or other hospitality -related business) may want to control whether or not a booked position (previously booked by a user) can be changed (e.g., purchased by another user, swapped with another user, made open to bidding from other users, etc.) during a final time period before an estimated seating time associated with the pre -booked queue position. For example, the final time period can be configured through an Administration interface (e.g., web app or mobile app that connects to a backend queue administration and configuration management server/service) to prevent position changes within the last fifteen minutes before seating, the last thirty minutes before seating, the last sixty minutes before seating, or any other set time duration prior to the estimated seating time. By enabling this configurable setting, restaurants and other hospitality -related businesses have more control over their own operations with respect to seating clientele at their restaurant or otherwise engaging with clientele for business activities. Therefore, if the scenario happens where it is too late to make a change, then the status of the booked position can be configured to be frozen.

[0026] The paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase of the present disclosure may be comprised of the following elements. This list of possible constituent elements is intended to be exemplary only and it is not intended that this list be used to limit the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase of the present application to just these elements. Persons having ordinary skill in the art relevant to the present disclosure may understand there to be equivalent elements that may be substituted within the present disclosure without changing the essential function or operation of the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase.

[0027] 1. A mobile smartphone application (“mobile app”) that is designed as software supported by at least two mobile device platforms including (i) iOS supporting mobile devices and (ii) Android supporting mobile devices.

[0028] 2. A user interface (“patron UI”) of the mobile app.

[0029] 3. A restaurant interface (“restaurant UI”) of the mobile app (which can be substituted as any hospitality-related business interface, such as a technical support UI, a car maintenance business UI, a DMV agency UI, etc.).

[0030] 4. An administration website, web app, or mobile app UI to manage the overall hopitality-related business handling of queuing sales, purchases, bidding, swapping, time constraints, compensation options, etc., and which provides a reporting interface for administrators to generate reports along a variety of selectable matrix options in order to review overview reports on the status of queuing activity. The patron UI and restaurant UI of the mobile app are also available via web browser as a web app in some embodiments. In this way, the features available through the mobile app are extended to other device types and platforms beyond those which support iOS and Android operating systems (e.g., desktop and laptop computers connecting via web browser to the web app).

[0031] The various elements of the paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase of the present disclosure may be related in the following exemplary fashion. It is not intended to limit the scope or nature of the relationships between the various elements and the following examples are presented as illustrative examples only. Each of the (2) patron UI and the (3) restaurant UI are designed for use as graphical user interfaces (GUI) with underlying code that is written from one or more application programming interfaces (APIs) that carry out the logical instructions at runtime for each of the ( 1 ) two software applications created in (i) iOS and (ii) Android. The (4) administration website is provided to manage the overall business and reporting by designated administrators. The patron UI and restaurant UI are partitioned from any administration interface or website access, thereby ensuring that only administrators designated by each respective restaurant or other hospitality -related business can make queue management, configuration, and queue purchase/sale transaction settings in the backend system.

[0032] The paid booking queue position sales system and processes for making a hospitality business patron waiting queue position open to bids for purchase of the present disclosure generally works by user interaction with the patron UI of the mobile app. When a position is booked, it can be booked as a free booking or a paid booking. Then after booking, the booked queue position can be made available for sale. If a queue position booking is made available for sale, then the booked position can be sold between two users. On the other hand, when a booked position is blocked or made not available for sale, other users can still make bids for the position. That is, the booked position can be bid on and if (bid) accepted then the position is able to be purchased by another user in the line (queue). This unique feature for bidding on blocked (not available for sale) queue positions ensures that even positions not available for sale can be potentially purchased with the right bid (incentive). The bid incentive could be a monetary value or a monetary value together with the ability to swap the queue position with the bidding offer party. [0033] By way of example, Figure 1 conceptually illustrates a paid booking queue salable position sales process 100 for booking, by a first user, a salable queue position in a bookable patron waiting queue. A continuation of the paid booking queue salable position sales process 100 for booking, by a first user, a salable queue position in a bookable patron waiting queue is demonstrated in Figure 2, which conceptually illustrates the paid booking queue salable position sales process 100 for purchasing, by a second user, the salable queue position booked by the first user, and making, by the second user, the salable queue position purchased by the second user available for sale to a third user.

[0034] As shown in Figure 1, the paid booking queue salable position sales process 100 for booking, by a first user, a salable queue position in a bookable patron waiting queue starts when the first user is interacting with the patron UI of the mobile app. In particular, the first user may engage the patron UI to search for a restaurant (at 110). For example, the first user may input a name of a restaurant at which the first user would like to eat. In addition to accepting a restaurant name is input, a search field in the patron UI may be configured to accept an address of a restaurant, a current map location of a user, a zip code in which the restaurant may be located, etc. The mobile app would perform a search of the restaurant name (or address, zip code, or other search field input) and, if a qualifying match of a restaurant is identified by the query, the patron UI may then visually output a restaurant detail screen (at 120). The restaurant detail screen of some embodiments shows vital restaurant information which a user may be interested in, such as the restaurant address, the restaurant rating, user experiences/comments from other users who have dined at the restaurant, hours of operation, etc. Next, the paid booking queue salable position sales process 100 determines (at 130) whether the first user intends to make a booking for the present day. For example, after showing the restaurant detail, the first user may select a button or another UI control element in the patron UI to make a booking at the restaurant. When such a selection is made by the first user, the mobile app may retrieve booking details about a present daily queue for the restaurant from a backend queue management database that maintains live updates of queue positions and availability for the booking queue of the restaurant. In some embodiments, the backend queue management database is connected to a live queue marketplace database that manages an overall virtual cloud-based micro-marketplace for queue positions sales, purchases, swaps, bids, time constraints, salable status, transaction payment information, and other settings or information. [0035] In some embodiments, when the first user wants to book for today, the paid booking queue salable position sales process 100 then determines (at 170) whether to book a paid position at the minimum price set of the user/restaurant, the details of which are described further below. On the other hand, when the first user does not intend to book a queue position at the restaurant for today, the paid booking queue salable position sales process 100 of some embodiments proceeds to the next step of allowing the first user to make a booking for a future date (at 140). In allowing the first user to make a booking for the future date (at 140), the paid booking queue salable position sales process 100 of some embodiments determines (at 150) whether to book a future paid position or not. For example, the future booking may be a booking that costs no money (e.g., a traditional reservation at a restaurant), or by way of the features of the embodiments described in the present disclosure, the booking may be a paid booking reservation where the user pays money to book a position in the queue for a future date (e.g., paying money to book the first position in the queue for a reservation at 7:00 pm tomorrow).

[0036] In some embodiments, when the booking for the future date is not a paid future booking, the paid booking queue salable position sales process 100 simply books a free position in the queue (at 160) at a certain date and time (which may reflect the choice of date and time of the first user or which may be different from the first user’s choice of date and time, depending on availability to make a free booking at the requested date and time). On the other hand, when the booking for the future date is a paid future booking, then then paid booking queue salable position sales process 100 continues to the next step of determining (at 170) whether to book a paid position at the minimum price set of the user/restaurant.

[0037] In some embodiments, booking a paid position in the queue for today or a future date requires a minimum payment amount. In some embodiments, the minimum payment amount for the paid queue booking is set by the restaurant (or other hospitality -related business). For example, the restaurant may require the first user to deposit five dollars to lock in the paid queue booking/position. When no minimum payment amount is required to book a paid queue position, the paid booking queue salable position sales process 100 simply books a free position in the queue (at 160) at a certain date and time (as noted above). On the other hand, when the minimum price to book the paid position is set by the user/restaurant, then the paid booking queue salable position sales process 100 transitions to a step for completing a payment transaction by e-wallet, credit card, online app payment, bank charge (debit), etc. (at 180). In some embodiments, if there is an administration charge, then the paid booking queue salable position sales process 100 proceeds to charge the administrative amount (at 190). Administration charges may include a percentage of every paid booking or a flat fee for each paid booking. On the other hand, when no administrative amount is required, the paid queue position gets booked for the first user.

[0038] While the first user holds the paid queue position, the queue position may be of interest to other users. This is shown by reference to Figure 2, in which the paid booking queue salable position sales process 100 determines (at 210) whether a request by a second user is made to purchase the paid queue position held currently by the first user. For example, the second user may wish to purchase the paid queue position for the same price the first user paid the restaurant, or may offer to pay a premium (excess) amount to purchase the paid queue position from the first user. When the amount the second user wishes to pay to purchase the paid queue position from the first user is not sufficient for the first user to sell the paid queue position, the paid booking queue salable position sales process 100 of some embodiments cancels the purchase request from the second user (at 220) and the first user continues to hold, maintain, use, or fulfill the paid queue position (at 230). In this situation, the transaction is not started or completed due to second user not going forward with the purchase.

[0039] On the other hand, when the amount the second user wishes to pay to purchase the paid queue position from the first user is sufficient for the first user to sell the paid queue position, then the paid booking queue salable position sales process 100 of some embodiments determines (at 240) whether the position was sold by the first user/restaurant to the second user by acceptance of the price offered by the second user. In some embodiments, when the price offered by the second user was not accepted by the first user/restaurant to sell the paid queue position, then the first user holds onto, maintains, uses, or fulfills the paid queue position (at 250) and the transaction is not completed due to first user/restaurant objecting to price offer. However, when the price offered by the second user was accepted by the first user/restaurant to sell the paid queue position, then the second user takes control of the paid queue position and the paid booking queue salable position sales process 100 determines (at 260) whether to make the paid queue position salable by action of the second user.

[0040] When the second user does not take action to make the paid queue position salable, then the paid booking queue salable position sales process 100 continues to the next step at which the second user holds, uses, or fulfills the paid queue position (at 270). On the other hand, when the second user takes action to make the paid queue position salable, then the paid booking queue salable position sales process 100 proceeds to open the paid queue position up to purchase by other users. In this example, a third user may purchase the paid queue position from the second user for a price that would need to be accepted by the second user (as either a minimum price set before making the position salable or by acceptance of a price amount bid by the third user for the second user to accept). Thus, the paid booking queue salable position sales process 100 proceeds to the next step at which the paid queue position held by the second user has been made salable by the second user and the paid queue position is purchased by the third user (at 280) from the second user. Then the paid booking queue salable position sales process 100 continues to the last step at which the third user holds, uses, or fulfills the paid queue position (at 290) he or she just purchased from the second user.

[0041] Although the example process demonstrated above by reference to Figures 1 and 2 describes the three different users, a person of ordinary skill in the relevant art would appreciate that the actions of offering for sale and purchasing positions in the queue can continue between more than three users, or may simply end after a second user purchases the position from the first user, or (in still other cases) may end after the first user locks in the paid queue position, happily dining at the restaurant at the date and time booked initially by the first user. Also, after each determination step of Figure 2 (i.e., after steps 210, 240, and 260), the backend system may carry out transaction processing for the purchases/exchanges of the paid queue position, and may also block the paid queue position (or alternatively leave the paid queue position open as salable) depending on the configuration options set by the restaurant (or rather, by the designated administration user associated with the restaurant).

[0042] In terms of carrying out the backend transaction processing, Figure 3 conceptually illustrates an e-wallet transaction process 300 for compensating the first user, the second user, and a restaurant for the sale of the salable queue position from the first user to the second user and from the second user to the third user, in connection with the paid booking queue salable position sales process of Figures 1 and 2. As shown in this figure, the e-wallet transaction process 300 includes an e-wallet of the first user 310, an e-wallet of the second user 320, an e-wallet of the third user 330, and an e-wallet of the restaurant 340 (which may or may not include administrative-only charges, or full charges, according the configuration options set by the restaurant). As shown, the money sent from the second user to the first user is automatically transmitted into the e-wallet of the first user 310 and the e-wallet of the restaurant 340, while the money sent from the third user to the second user is automatically transmitted into the e-wallet of the second user 320 and the e-wallet of the restaurant 340.

[0043] In some embodiments, it is possible to bid for paid queue positions that are not for sale by the associated user or the restaurant. These non-salable positions can be bid for and sold if the associated user or restaurant owning the position chooses to sell it. Furthermore, within each bid for a non-salable paid queue position is a related option to offer to swap queue positions. For example, if a bidding user already has a paid queue position that is near the end of the queue, he or she may offer to swap positions with another user with a relatively closer queue position, but who may be waiting for another person to arrive, or who may be willing to wait in the queue longer for a swapped position and an additional add-on incentive, such as payment for swapping. This, of course, can make the bid more appealing for the owner of the position as it allows him or her to receive funds and potentially an opportunity to take another position in the line and also still have dinner in the restaurant (both the swap and the funds acting as separate but conjoined incentives that may sweeten the prospective exchange more than a pure swap alone, or a pure bid/acceptance sale alone). Additionally, for any user this can be especially useful when trying to make a decision on multiple bid offers.

[0044] By way of example, Figure 4 conceptually illustrates a non-salable queue position bidding process 400 for making a bid, by a third user, to purchase a non-salable queue position held by a second user who purchased the queue position as a salable queue position from a first user who booked the salable queue position from a restaurant. As shown in this example, the non-salable queue position bidding process 400 starts when the third user bids for a non-salable/blocked queue position. This might be the case for the paid queue position held by the second user after purchase from the first user, and when the backend system is configured to automatically make the paid queue position non-salable or blocked after the second user purchases the paid queue position from the first user, as demonstrated above by reference to Figures 1 and 2.

[0045] Going off this example from Figures 1 and 2 then, the non-salable queue position bidding process 400 of some embodiments receives the bid amount from the third user to purchase the paid queue position from the second user. For example, the third user may bid ten dollars to obtain the rights to the paid queue position from the second user, since the bidding is the only option after the paid queue position is reset to be non-salable or blocked. As noted above, a non-salable or blocked setting for a queue position by the backend system does not eliminate the owner of the position (in this case, the second user) from accepting bids to transfer the rights to the position to another user. Thus, after the bid amount from the third user is received, the non-salable queue position bidding process 400 of some embodiments determines (at 420) whether the bid amount was accepted by the paid queue position holder (i.e., the second user). In some embodiments, the bidding is a feature that is made available as a live add-on to the salable queue positions by restaurants the deploy and configure a live virtual cloud-based micro marketplace for sales, purchases, bidding, swapping, and other transactions related to queue positions. Further details of the virtual cloud-based micro-marketplace are described below, by reference to Figure 6.

[0046] In some embodiments, when the second user accepts the bid of the third user, the non-salable queue position bidding process 400 advances forward to a step for completing a transaction for the bid amount (at 460), which is paid by the third user via e-wallet, credit card, online app transaction, or bank (debit) charge. On the other hand, when the second user does not accept the bid amount of the third user, the non-salable queue position bidding process 400 checks for additional, follow-up bid amounts from the third user. Thus, when the third user does make an increased bid amount offer (at 430), the non-salable queue position bidding process 400 of some embodiments determines (at 440) whether the new bid amount is accepted by the second user and is within the agreed time-constrained period (if set by the restaurant). When the new bid amount is not accepted by the second user or the new bid amount is received in a time -constraint period before seating is scheduled (or “bidding/transaction lock out period”), then the second user simply maintains his or her position in the queue (at 450). If the second user maintains the same position in the queue due to rejection of the higher bid amount offered by the third user, then the non-salable queue position bidding process 400 rechecks for any subsequent, follow-up higher bid amounts offered by the third user, such that if and when the third user does indeed make a higher bid amount (at 430), the non-salable queue position bidding process 400 returns to determine (at 440) whether the higher bid amount is accepted by the second user (and compulsively checks to determine if any bidding/transaction lock out period has been triggered by fact of the time being too close to the scheduled seating time).

[0047] If and when the second user does actually accept new, higher bid amount offered by the third user, the non-salable queue position bidding process 400 of some embodiments proceeds to the step for completing a transaction for the higher, accepted bid amount (at 460), which is paid by the third user via e-wallet, credit card, online app transaction, or bank (debit) charge, as noted above. In connection with completing the transaction for the bid amount (or the higher, accepted bid amount), the non-salable queue position bidding process 400 of some embodiments completes operations for an administrative charge (at 470) when required by the restaurant, and proceeds to the next step at which the paid queue position if officially purchased by the third user (at 480) based on the accepted bid amount by the second user, even after the paid queue position was blocked as a non-salable position. After the purchase is completed, the third user fulfills the position in the queue (or takes over) for the paid queue position (at 490). Then the non-salable queue position bidding process 400 ends.

[0048] For the backend transaction processing, Figure 5 conceptually illustrates an e- wallet compensation movement process 500 for compensating the second user and the restaurant for the sale of the non-salable queue position to the third user at the accepted bid price, in connection with the non-salable queue position bidding process of Figure 4. The e-wallet compensation movement process 500 is similar to the e-wallet transaction process 300 described above by reference to Figure 3. However, as shown in Figure 5, the e-wallet compensation movement process 500 includes an e-wallet of the second user 510 (which may be the same e- wallet of the second user 320 demonstrated in Figure 3), an e-wallet of the third user 520 (which may be the same e-wallet of the third user 330 demonstrated in Figure 3), and an e-wallet of the restaurant 530 (which may be the same e-wallet of the restaurant 340 as shown in Figure 3). As shown, the money sent from the third user to the second user is automatically transmitted into the e-wallet of the second user 510 and the e-wallet of the restaurant 530, which may or may not include administrative-only charges, or full charges, according the configuration options set by the restaurant.

[0049] Now turning to an example of the paid booking queue position sales system, Figure 6 conceptually illustrates a network architecture of a paid booking queue position sales system 600 that hosts a cloud-based virtual booking queue position micro-marketplace and a paid booking queue selling, purchasing, bidding, compensating, and swapping cloud application service. As shown in this figure, the paid booking queue position sales system 600 includes a first patron mobile device 610, a second patron tablet mobile device 620, an administrator computer 630, a restaurant host mobile device 640, a wireless communication point 622 (e.g., a cell tower for cellular data communication), a gateway 624, a registration and login server 650, a registered user database 660, a set of private paid booking queue position sales/exchange servers 670 (LOB servers for a particular restaurant, such the that the paid booking queue position sales system 600 may include many more separate restaurant private cloud connections, each with their own set of private paid booking queue position sales/exchange servers 670 and connected databases), a restaurant queue management database 680, and a live virtual micro-marketplace database 690.

[0050] In some embodiments, the paid booking queue position sales system 600 accesses third party cloud services. In some embodiments, the paid booking queue position sales system 600 accesses third party payment services via one or more cloud-based third party e- wallet 675. In some embodiments, the paid booking queue position sales system 600 accesses third party financial system services via one or more cloud-based third party credit card and banking payment processors 685. In some embodiments, the paid booking queue position sales system 600 accesses third party online services via one or more cloud-based third party online app-based payment processors 695.

[0051] Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium or machine readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[0052] In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs. [0053] Figure 7 conceptually illustrates an electronic system 700 with which some embodiments of the invention are implemented. The electronic system 700 may be a computer, phone, PDA, or any other sort of electronic device. Such an electronic system includes various types of computer readable media and interfaces for various other types of computer readable media. Electronic system 700 includes a bus 705, processing unit(s) 710, a system memory 715, a read-only 720, a permanent storage device 725, input devices 730, output devices 735, and a network 740.

[0054] The bus 705 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 700. For instance, the bus 705 communicatively connects the processing unit(s) 710 with the read-only 720, the system memory 715, and the permanent storage device 725.

[0055] From these various memory units, the processing unit(s) 710 retrieves instructions to execute and data to process in order to execute the processes of the invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments.

[0056] The read-only-memory (ROM) 720 stores static data and instructions that are needed by the processing unit(s) 710 and other modules of the electronic system. The permanent storage device 725, on the other hand, is a read-and-write memory device. This device is a non volatile memory unit that stores instructions and data even when the electronic system 700 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 725.

[0057] Other embodiments use a removable storage device (such as a floppy disk or a flash drive) as the permanent storage device 725. Fike the permanent storage device 725, the system memory 715 is a read-and-write memory device. However, unlike storage device 725, the system memory 715 is a volatile read-and-write memory, such as a random access memory. The system memory 715 stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention’s processes are stored in the system memory 715, the permanent storage device 725, and/or the read-only 720. For example, the various memory units include instructions for processing appearance alterations of displayable characters in accordance with some embodiments. From these various memory units, the processing unit(s) 710 retrieves instructions to execute and data to process in order to execute the processes of some embodiments. [0058] The bus 705 also connects to the input and output devices 730 and 735. The input devices enable the user to communicate information and select commands to the electronic system. The input devices 730 include alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output devices 735 display images generated by the electronic system 700. The output devices 735 include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some embodiments include devices such as a touchscreen that functions as both input and output devices.

[0059] Finally, as shown in Figure 7, bus 705 also couples electronic system 700 to a network 740 through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network (“LAN”), a wide area network (“WAN”), or an intranet), or a network of networks (such as the Internet). Any or all components of electronic system 700 may be used in conjunction with the invention.

[0060] These functions described above can be implemented in digital electronic circuitry, in computer software, firmware or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be packaged or included in mobile devices. The processes may be performed by one or more programmable processors and by one or more set of programmable logic circuitry. General and special purpose computing and storage devices can be interconnected through communication networks.

[0061] Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine -readable storage media). Some examples of such computer- readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD- ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

[0062] While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. For instance, Figures 1-5 conceptually illustrate processes. The specific operations of these processes may not be performed in the exact order shown and described. Specific operations may not be performed in one continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process could be implemented using several sub processes, or as part of a larger macro process. Thus, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.