SYSTEM AND METHOD FOR ENHANCED FOODSERVICE MANAGEMENT

A system and method for an enhanced foodservice management system configured to receive a food order, determine a desired “delivery” time for the received food order, and manage the preparation of the food order based on the determined delivery time in order to enhance customer satisfaction with the product they receive and to improve both front-of-house and back-of-house staff's communication and production in fulfilling food orders. The system comprising a food order manager configured to supervise the scheduling and preparation of a plurality of food orders, a table manager configured to conduct table and waitlist management, a payment facilitation server configured to store and manage financial account information and provide user and/or sub-user authorization functionality, and one or more database(s) configured to store a plurality of information associated with customer information, business information, food information, and table history information, delivery information, and various other types of information.

BACKGROUND

Field of the Art

The disclosure relates to the field of payment systems, and more particularly to the field of third-party and self-regulated online payment services and integration with restaurants and retailers.

Discussion of the State of the Art

The advent of online payments and the ease of setting up online payment accounts, and the ease of transferring funds online between banking and other financial institutions, has benefited society in many ways, allowing for easy transfer of funds between individuals online and easy payment for goods without ever having actual, physical dollar bills or other physical currency involved. It is possible for family members to transfer funds to the accounts of other family members quite easily, and for parents to support their children with funds such as when they are in university or when they have an allowance on their own debit card or with an online account. This, however, comes with many risks, of the child, or other individual including an independent user of online finances and banking, to misuse their funds, and to purchase unhealthy, dangerous, or expensive and unneeded goods, due to a lack of self-control and the ease with which one can transfer funds and make purchases with online banking and even online shopping.

There exists no easy way for parents to control what their child can spend money on or to help guide them to healthier lifestyles, and likewise it is common for people who attempt to self-regulate their diets and lifestyles in accordance with personal goals, doctor recommendations, or dietician and nutritionist recommendations, to fall short of their goals and purchase unhealthy or unneeded goods. No system of keeping track of dietary or budgeting or lifestyle constraints currently integrates with point-of-sale systems in a similar way that online financing and banking already does, either, resulting in an extremely easy method to acquire goods detrimental to one's health or lifestyle or budget, but no easy way to control such purchases if one lacks the (sometimes immense) self-control to prevent such purchases in the first place. This is made even harder for individuals with actual disabilities or deficiencies which make responsible purchasing more difficult, such as those suffering from depression or complex dietary restrictions which they struggle to meet.

SUMMARY

Accordingly, the inventor has conceived and reduced to practice, a system and method for an enhanced foodservice management system configured to receive a food order, determine a desired “delivery” time for the received food order, and manage the preparation of the food order based on the determined delivery time in order to enhance customer satisfaction with the product they receive and to improve both front-of-house and back-of-house staff's communication and production in fulfilling food orders. The system comprising a food order manager configured to supervise the scheduling and preparation of a plurality of food orders, a table manager configured to conduct table and waitlist management, a payment facilitation server configured to store and manage financial account information and provide user and/or sub-user authorization functionality, and one or more database(s) configured to store a plurality of information associated with customer information, business information, food information, and table history information, delivery information, and various other types of information.

According to a preferred embodiment, a system for enhanced foodservice management is disclosed, comprising: a food order manager comprising a first plurality of programming instructions stored in a memory of, and operating on a processor of, a computing device, wherein the first plurality of programming instructions, when operating on the processor, cause the computing device to: receive an order, the order comprising at least one food item, a desired delivery time, and user account data for a registered user; retrieve stored item preparation time for the at least one item in the received order; generate estimated order preparation time based on the retrieved item preparation time; send estimated order preparation time to a table manager; assign preparation of the order based on the desired delivery time and the estimated order preparation time; and the table manager comprising a second plurality of programming instructions stored in a memory of, and operating on a processor of, a computing device, wherein the second plurality of programming instructions, when operating on the processor, cause the computing device to: receive the estimated order preparation time; receive a seating request; retrieve a table history, the table history comprising: an historical record of table turn-time, comprising a length of time that a table was unavailable for seating; customer data for the table during the turn-time; and order data for the table during the turn-time; and estimate a predicted table turn-time based on the table history and the estimated order preparation time; and estimate a predicted seating time based on the predicted table turn-time and the seating request; and a payment facilitation server comprising a third plurality of programming instructions stored in a memory of, and operating on a processor of, the computing device, wherein the third plurality of programming instructions, when operating on the processor, cause the computing device to: receive user account data for a registered user from a user device via a network; provide zero-step authorization wherein a subordinate user is automatically authorized to perform a transaction at a specific restaurant or retail location using funds associated with the registered user; permit the transaction using the stored funds corresponding to the registered user to process only if the subordinate user is authorized via the zero-step authentication; and transmit a notification over the network to the registered user based on the attempted transaction.

According to another preferred embodiment, a method for enhanced foodservice management is disclosed, comprising the steps of: receiving an order, the order comprising at least one food item, a desired delivery time, and user account data for a registered user; retrieving stored item preparation time for the at least one item in the received order; generating estimated order preparation time based on the retrieved item preparation time; sending estimated order preparation time to a table manager; assigning preparation of the order based on the desired delivery time and the estimated order preparation time; receiving the estimated order preparation time; receiving a seating request; retrieving a table history, the table history comprising: an historical record of table turn-time, comprising a length of time that a table was unavailable for seating; customer data for the table during the turn-time; and order data for the table during the turn-time; estimating a predicted table turn-time based on the table history and the estimated order preparation time; estimating a predicted seating time based on the predicted table turn-time and the seating request; receiving user account data for a registered user from a user device via a network; providing zero-step authorization wherein a subordinate user is automatically authorized to perform a transaction at a specific restaurant or retail location using funds associated with the registered user; permitting the transaction using the stored funds corresponding to the registered user to process only if the subordinate user is authorized via the zero-step authentication; and transmitting a notification over the network to the registered user based on the attempted transaction.

According to an aspect of an embodiment, a payment facilitation device comprising a fourth plurality of programming instructions stored in a memory of, and operating on a processor of, the payment facilitation device, wherein the fourth plurality of programming instructions, when operating on the processor of the payment facilitation device, cause the payment facilitation device to: detect a wireless mobile device registered to the subordinate user; establish a wireless connection with the wireless mobile device; obtain a device identifier for the wireless mobile device; send the device identifier to the payment facilitation server; receive customer information for the wireless mobile device from the payment facilitation server; display a photograph of the user; transmit transaction details to a mobile device of the registered user for approval; receive authentication of the transaction details from the registered user mobile device; and send the transaction details to the payment facilitation server for processing of the transaction.

According to an aspect of an embodiment, wherein the zero-step authorization comprises the steps of: comparing of the restaurant or retail location against any available stored merchant authorizations for the subordinate user to determine whether the subordinate user is authorized to perform the transaction at the restaurant or retail location; and comparing any stored merchant authorizations against the registered user corresponding to the funds used in the transaction to determine whether the merchant authorization was provided by the registered user.

According to an aspect of an embodiment, the performed transaction is a food order for delivery or take-out.

According to an aspect of an embodiment, the seating request comprises a dining party size and one or more accommodations.

According to an aspect of an embodiment, the registered user and any specified subordinate users provide biometric information for the purpose of authentication with the system.

According to an aspect of an embodiment, the zero-step authorization uses the biometric data for authentication.

According to an aspect of an embodiment, he merchant authorization is based on patient dietary restrictions.

According to an aspect of an embodiment, the registered user is a guardian and the subordinate user is a dependent.

According to an aspect of an embodiment, the notification is transmitted via any one or combination of email, SMS messaging, or messages seen upon logging into a web application.

DETAILED DESCRIPTION

The inventor has conceived, and reduced to practice, A system and method for an enhanced foodservice management system configured to receive a food order, determine a desired “delivery” time for the received food order, and manage the preparation of the food order based on the determined delivery time in order to enhance customer satisfaction with the product they receive and to improve both front-of-house and back-of-house staff's communication and production in fulfilling food orders. The system comprising a food order manager configured to supervise the scheduling and preparation of a plurality of food orders, a table manager configured to conduct table and waitlist management, a payment facilitation server configured to store and manage financial account information and provide user and/or sub-user authorization functionality, and one or more database(s) configured to store a plurality of information associated with customer information, business information, food information, and table history information, delivery information, and various other types of information.

Because the customer does not have to focus on his or her mobile device, the customer is free to interact naturally with the business environment and with employees of the business. For example, the customer is free to look around to experience the store's ambiance, which will tend to create a positive impression on the customer, and increase the likelihood that the customer will wish to return. Further, the customer is free to look at and speak with the business' employees, which facilitates personal interactions and relationships, making the customer feel more welcome and also increasing the likelihood that the customer will wish to return. These natural interactions are hindered by the handling and use of mobile phones, where the customer's attention is drawn away from the business environment and its employees in order to focus on the details of making or approving the transaction using his or her mobile device.

Definitions

“Business establishment” or “place of business” as used herein mean the location of any business entity with which customers may transact business. Typically, this will be a physical location where customers may enter the location and transact business directly with employees of the business, but may also be a business without a physical location such as an online or telephone order retailer. Many examples herein use a restaurant as the business establishment, but the invention is not limited to use in restaurants, and is applicable to any business establishment.

The term “network” as used herein means any communication connection between two or more computing devices, whether such connection is made directly (e.g., from one device containing a Bluetooth radio to another device containing a Bluetooth radio) or through an intermediary device such as a router, where a number of devices connected to the router may all communicate with one another.

Conceptual Architecture

FIG. 1is a block diagram illustrating an exemplary system architecture100for a zero-step authentication system. The primary components of the system are a payment facilitation device103, a unified communications device or telephony exchange system (UC system)101, and a payment facilitation server200. Components or services that may connect to or be accessed by the system include wireless customer mobile devices102, and payment processors109. The payment facilitation device103is a computing device located at a business establishment that is connected (wired or wirelessly) to a UC system101. The payment facilitation device103may be wired, or wireless, or both, depending on the implementation of a given embodiment. While a payment facilitation device103and UC system101are specified in this embodiment, it is not required that they be precisely in this configuration, and other configurations are possible, including a non-SIP computing device connected to a network without a UC system101. The payment facilitation device103comprises a screen (not shown) and applications for a customer information entry portal104and a customer identification confirmation application105. The payment facilitation device103may be a mobile computing device like a mobile phone or tablet computer or may be a desktop or tabletop computing device.

The customer information entry portal104is an application on the payment facilitation device103that allows an employee of the business to enter customer details such as name, telephone number, device identifier, bank, debit, or credit card details, payment preferences, and, if necessary, customer account refill limits and customer account refill amounts. The device identifier may be any information that allows the system to identify the customer mobile device102, including, but not limited to, a mobile access control (MAC) address (e.g., a MAC address for the device's WiFi radio, a MAC address for the device's Bluetooth radio, etc.), the device's102serial number, the device's mobile equipment identifier (MEID) or international mobile equipment identity (IMEI) number, the integrated circuit card identifier (ICCID) of the subscriber identity module (SIM) card inserted into the customer mobile device102, and the device's102secure element identification (SEID) number.

The customer identification and confirmation application105is an application that provides security in financial transactions by allowing the employee of the business to visually confirm the identity of the customer making a transaction. For example, the payment facilitation device at a particular business location may be connected to multiple customer devices simultaneously. The customer identification and confirmation application105may display a photo of the user (customer) of each such connected customer device, and the employee may select the device of the customer making the transaction by clicking on the customer's photo as displayed by the customer identification and confirmation application105on the payment facilitation device103.

The UC system101is a device or service (e.g., online service) that integrates different methods of communication (e.g., phone calls, video calls, short message service (SMS), instant messaging (chat), email) and allows for all of those different methods of communication to be accessed through a computing device such as a mobile phone or tablet computer. A UC system101is the modern, and much more flexible and powerful, form of a private branch exchange (PBX) telephone equipment system that allowed businesses to connect multiple internal telephones to a single incoming telephone line. In this example, the UC system101acts as the interface between the payment facilitation device103, the customer mobile devices102, and the payment facilitation server200.

A customer mobile device102may be connected to the system via any wireless network connection, for example through the Internet106, a mobile (cellular) network107, or through a local wireless network108such as WiFI, Bluetooth, etc. In the case of remote connections such as those made through the Internet106or mobile service107, the location of a customer mobile device102and its location relative to the payment facilitation device103or other customer mobile devices102may be established through use of the device's satellite positioning system hardware (e.g., GPS, GLONASS, Galileo), by identifying the location of an intermediary device to which the device is connected (e.g., a WiFi router, etc. In the case of local connections, which typically use short range wireless transmissions, it may not be necessary to determine the location of the mobile customer device102because the short range of wireless communications establishes that the payment facilitation device103or other mobile customer devices are nearby. For example, when using a Bluetooth Class 2 connection to connect to other devices, it will be apparent that the other devices are nearby because Bluetooth Class 2 has an effective range on the order of 10 meters.

In a typical scenario, the first time a customer enters a business establishment with a customer mobile device102, an employee of the business establishment will enter the customer's information using the customer information entry portal104and register the customer mobile device102using the customer mobile device's102identification. When a customer mobile device102enters a business establishment, the payment facilitation device103and customer mobile device102will automatically detect each other and establish a network connection. The payment facilitation device103will recognize the customer mobile device102using the customer mobile device's identifier. As the customer makes an order, the business's employee will confirm the identity of the customer using the customer identification confirmation application105. The payment facilitation device connects to the payment facilitation server200, either directly or through the UC system101, forwards the customer information and order information to the payment facilitation server200. The payment facilitation server200, checks the customer's account and either deducts an appropriate amount from the customer's prepaid account or sends the payment details to a payment processor109for processing. Once the payment is processed, the payment facilitation server200sends a confirmation of the payment either to the payment facilitation device103, the customer mobile device102, or both. In a scenario where the customer is in a remote location from the business establishment (e.g., a phone order or online order), the process is much the same except that the first time customer information entry and mobile device registration occurs remotely, and the employee does not visually identify the customer (although other methods of identifying the customer may apply, such as personal identification number (PIN) codes, voice print identification, telephone number identification, or customer mobile device102identifiers).

FIG. 2is a block diagram illustrating an exemplary architecture for an aspect of zero-step authentication system, the payment facilitation server200. The payment facilitation server200manages customer information and payments from multiple customers. In this example, the payment facilitation server comprises a customer information database201, a customer identification engine202, a payment processing manager209, and one or more applications for managing bill splitting, fund transfers, and account information. Note that, in some embodiments, the bill splitting and fund transfer applications may be applications on the customer mobile device102instead of on the payment facilitation server200. As the payment facilitation server receives customer information and device registrations, it stores them in a customer information database. Such customer information may comprise customer details such as name, telephone number, device identifier, bank, debit, or credit card details, payment preferences, and, if necessary, customer account refill limits and customer account refill amounts. The device identifier may be any information that allows the system to identify the customer mobile device102, including, but not limited to, a mobile access control (MAC) address (e.g., a MAC address for the device's WiFi radio, a MAC address for the device's Bluetooth radio, etc.), the device's102serial number, the device's mobile equipment identifier (MEID) or international mobile equipment identity (IMEI) number, the integrated circuit card identifier (ICCID) of the subscriber identity module (SIM) card inserted into the customer mobile device102, and the device's102secure element identification (SEID) number.

The customer identification engine202provides additional security by confirming the identity of the customer before processing payments. In this example, the customer identification engine202has three separate identification methods, a voiceprint identifier203, a telephone number identifier204, and a device ID identifier205. The voiceprint identifier203can provide confirmations of customer identities either by matching voice samples of specific words and phrases provided by the customer during account creation and device registration or, in a more sophisticated version, may match the customer's voice to any spoken words and phrases using machine learning algorithms. The telephone number identifier204receives caller identification (caller ID) information from the UC system101, and verifies that the phone number from which the order is being made matches the phone number in the customer account information. The device ID identifier205receives a device identifier from the UC system101and matches it to the device identifier in the customer database201to confirm that the device is registered. In some embodiments, other methods of identifying the customer may be used, for example, PIN codes. In some embodiments, two or more of these identifiers may be used together to confirm the customer's identity.

As customer information and order information is received, the payment facilitation server200checks the customer's account using the customer account management application208and either deducts and appropriate amount from the customer's prepaid account or sends the payment details to the payment processing manager209, which forwards the payment request to a payment processor109for processing. Once the payment is processed, the payment facilitation server200sends a confirmation of the payment either to the payment facilitation device103, the customer mobile device102, or both.

The bill splitting application206receives a bill that is to be shared by two or more customers (e.g., a restaurant dining bill), the device identifier of two or more customer mobile devices102, and provides an interface for those customers to allocate items on the bill between the customers. Once each of the customers involved approves the allocation, the bill splitting application forwards each customer's portion of the bill to the payment processing manager209The fund transfer application207operates in a similar manner for fund transfers between customers. Customers involved in the fund transfer specify amounts to be transferred to other customers, and once approved by all customers involved in the fund transfer, the fund transfer application forwards the approved fund transfers to the payment processing manager209for execution.

FIG. 3is a flow diagram illustrating an exemplary flow of payments300in an embodiment. When a customer303authorizes a transaction (which authorization may be pre-approved) through his or her customer mobile device102, the payment authorization is sent to the business302at the business' payment facilitation device103. The payment facilitation device103of the business302sends a payment request to the payment facilitation server200. The payment facilitation server200checks the customer's pre-paid account304to determine whether pre-paid funds are available. If such funds are available, a deduction is made from the customer pre-paid account304in the amount of the authorized payment, and a confirmation is confirmed by the payment facilitation server200. If sufficient funds are not available in the customer pre-paid account, the account is either refilled or a direct payment request is made. In either case, the payment facilitation server200sends a payment request to a payment processor109, which are financial intermediaries like Visa and Mastercard, who process transactions on behalf of financial institutions301(i.e., banks). The payment processor109sends the payment request to a financial institution301at which the customer303has an account. The financial institution301receives the payment request, and sends a payment to the payment processor109, typically along with a transaction fee. The payment processor109receives the payment and transaction fee, and forwards the payment to the payment facilitation server along with a portion of the transaction fee. The payment facilitation server200forwards the payment to the business302, which forwards a confirmation of payment303to the customer, completing the transaction.

FIG. 15is a system diagram of a system for third-party food and dining and retail purchase ordering control, according to an embodiment. A computer or computers1510exist, which may be separate and unconnected devices such as computers running in different buildings on different networks, such as a home computer, and a computer at a doctor's office. These computers may have at least an operating system and network adapter, and network connection, as well as associated hardware that allows such a computer to operate, such as volatile memory, a power source, and other common components for a computer. A mobile device or collection of mobile devices1520also may exist, including mobile phones, personal digital assistants or similar, and tablets, which may be able to communicate over a network, and may be owned and operated separately, rather than together on the same network or by the same user. The computer or computers1510and mobile device or devices1520all may communicate over the Internet1530, with common protocols such as Hyper Text Transfer Protocol (“HTTP”) and Transmission Control Protocol (“TCP”), to a web application1540using one of their supported protocols. A web application may be accessed through a website using HTTP communications, may be used through TCP communications with a specific application to operate as an interface between the computer and the application, and may use any of a variety of possible encryption or security features such as HTTP Secure or RSA encryption to protect user data. A datastore1550may exist either on the same server or servers as web application1540, or on a network connection and accessed by web application1540. A point-of-sale or “POS” system for a restaurant, store, or other vendor1560is also present, connected over the internet1530and communicating with a web application1540. The POS1560may communicate over the Internet1530with web application1540with common protocols such as Hyper Text Transfer Protocol (“HTTP”) or Transmission Control Protocol (“TCP”), using one of the supported protocols. Web application1540may be accessed through a website using HTTP communications, may be used through TCP communications with a specific application to operate as an interface between the computer and the application, and may use any of a variety of possible encryption or security features such as HTTP Secure or RSA encryption to protect user data.

FIG. 16is a system diagram of a web application used for third-party food and dining and retail purchase ordering control, according to an embodiment. The web application1540encompasses or includes several services and interfaces for operation, including an authentication service1610, bank interface1620, sub-user interface1630, POS interface1640, admin interface1650, notification service1660, scheduling engine1670, and suggestion engine1680. An authentication service1610may operate by unencrypting received data from another source such as a computer or mobile device communicating over HTTP or TCP protocols, or potentially some other protocol, and communicate with a datastore to determine if a received user authentication request is valid. For instance, user authentication requests may comprise encrypted username and password combinations that must then be checked against what is stored, or biometric information such as retinal scans, facial scans, voice data, or other biometrics. Authentication data is a one-to-many check in most cases, wherein user data is submitted and then compared to any entries in the datastore to locate a match, and if none are found, return a false identification result. If any matches are found, such as a matching username and password or matching biometrics to what is stored for a stored user, the requesting user and device may be logged into the application, and be presented with an interface to access the application further, such as a sub-user interface1630or administrator interface1650. A bank interface1620is a non-graphical interface for financial institutions, which allows depositing of funds such as with debit card, bank account number and routing number, PAYPAL™ account information, or other financial data, through a secure channel and protocol such as HTTPS protocol. Sub-user interface1630and administrator interface1650may both be graphical user interfaces (“GUI”) to display to specific types of users. A parent that is using the web application to deposit funds and control what their dependent may order with the deposited funds, for instance, would register with the application as an administrator, and then specify their dependent or dependents as sub-users that may log in with specific criteria that is either set by the parent or set by the dependent. A sub-user may register for an independent account as an administrator, but will not have access to the funds deposited by their caretaker or parent, thus defeating the purpose of utilizing the application for themselves, as they would only be able to deposit funds for their own account, rather than use the funds deposited by their caretaker for their use in authorized transactions. A POS interface1640is an interface, similarly, for communications from a point-of-sale system at a retailer or restaurant, that may communicate with the web application to determine if a specified user (authenticated with the authentication service) is able to purchase the specified goods for the specified price. If they have not enough funds, or are not permitted to purchase the specified goods from the specified vendor, they may be rejected, and the transaction cancelled. Otherwise, the funds may be withdrawn from the account, and transferred to the POS system.

Administrator interface1650may provide a graphical interface to specify notifications, scheduling, and suggestions, with their respective services in the application1660,1670,1680, wherein the notifications comprise at least an option to have notifications sent to a third party including the owner of the administrator account for any attempts at withdrawing funds for purchases from a sub-user, or by the administrator themselves, such as with email notifications, SMS notifications, or notifying an account with the web application such that upon logging in, they see the specified notification. An example of such a notification may be an email sent to a parent, “2020-05-24 JOHN DOE attempted to purchase ‘MACARONI AND CHEESE’ from vendor ‘WAL-MART OF LOS ANGELES’ for $8.00,” or something similar to a doctor, if an account has been set up to notify a doctor of purchases made, in keeping with dietary restrictions placed on the account. Scheduling may be set up with a scheduling engine1670such that specific purchases, and specific vendors or classes of vendors, may only be purchased or purchased from, on a specific schedule, such as only allowing alcohol to be purchased once every month, or only allowing foods from restaurants to be purchased once a week, allowing an administrator to control certain aspects of budgeting and lifestyle choices made with the deposited funds for sub-users. The suggestion engine1680may be used within the app to provide suggestions of foods, recipes, local restaurants or grocery stores, that may interest a user or sub-user based on specified interests and preferences, such as preferences for dairy foods, spicy foods, or specific types of restaurants such as Mexican restaurants within 10 miles. Sub-users may set their own suggestions preferences if permitted by the administrator, and their actions with the deposited funds from the administrator are restricted based on the scheduling engine, restriction settings from the administrator, and notifications may be sent out upon attempting to use the deposited funds, based on the settings specified by the administrator, if any, using for instance, email notifications, SMS notifications, or notifications seen on log-in of an account.

FIG. 21is a block diagram representation of a business establishment2100including an embodiment of a food order management system2102. Examples of business establishments2100include, but are not limited to, a restaurant, a food delivery service, and a combination restaurant/food delivery service. In an embodiment, the business establishment2100includes a food preparation area2104, a food order pick-up area2106, a food packaging area2108, a delivery order pick-up area2110, and a dine-in seating area2112. While the food preparation area2104, the food order pick-up area2106, the food packaging area2108, the delivery order pick-up area2110, and the dine-in seating area2112are shown as being in different areas within the business establishment2100, one or more of the described areas may be integrated into a single area or may occupy overlapping areas in the business establishment2100. Different embodiments of business establishments2100may include one or more of the food preparation area2104, the food order pick-up area2106, the food packaging area2108, the delivery order pick-up area2110, and the dine-in seating area2112. The business establishment2100may include additional areas that facilitate the operation of the business establishment2100.

The business establishment2100includes a menu2114with a listing of a plurality of different food items that are available for order at the business establishment2100. A customer of the business establishment2100is provided with the option of selecting one or more of the food items from the menu2114to place a food order. In an embodiment, the food order management system2102is configured to receive food orders entered manually by business establishment personnel via a food order management system input device. In an embodiment, the food order management system2102is configured to receive food orders electronically via a food order management system network interface. In an embodiment, the food order management system2102is configured to received food orders entered manually by business establishment personnel via a food order management system input device and electronically via a food order management system network interface.

Food items in a food order are prepared in the food preparation area2104and the completed food orders are placed in the food order pick-up area2106. Upon the receipt of a food order from a dine-in customer, the food order management system2102coordinates the preparation of the food items in the food order in the food preparation area2104and generates a predicted food order ready time. Different food items in the food order may have different food item preparation times. The predicted food order ready time specifies when the prepared food order is expected to be placed in the food order pick-up area2106. In an embodiment, the food order management system2102updates the predicted food order ready time based on the actual food item preparation time taken by food preparation personnel to prepare each of the food items in the food order in the food preparation area2104. Providing a predicted food order ready time at the time a food order is received may enable a waiter/waitress to inform a dine-in customer of when they can expect to receive the food items in their food order.

When a food order is received for delivery, the food items in the food order are prepared in the food order preparation area2104and the completed food orders are placed in the food order pick-up area2106. Food packaging personnel pick up the complete food orders from the food order pick-up area2106for packaging in the food packaging area2108. The packaged food orders are placed in the delivery order pick-up area2110. Delivery personnel pick up the packaged food from the delivery order pick-up area1210for delivery to a food order delivery destination.

Upon the receipt of a food order for delivery, the food order management system2102coordinates the preparation of the food items in the food order in the food preparation area2104, generates a predicted food order ready time, coordinates the packaging of the food items in the food order, generates a predicted packaged food order ready time, coordinates the delivery of the food order to the food order delivery destination, and generates a predicted food order delivery time. Different food items in the food order may have different food item preparation times and/or different food item packaging times.

The predicted food order ready time specifies when the prepared food order is expected to be placed in the food order pick-up area2106for pick-up. The predicted food order ready time provides food packaging personnel with notice regarding when the food order will be available to be picked up from the food order pick-up area2106for packaging in the food packaging area2108. The predicted packaged food order ready time specifies when the packaged food order is expected to be placed in the delivery order pick-up area2110for pick-up by delivery personnel. The predicted food order delivery time specifies when the food order is expected to be delivered to the food order delivery destination. The food order management system2102generates the predicted food order delivery time based on delivery route specific data associated with the delivery route.

In an embodiment, the food order management system2102updates the predicted food order ready time based on the actual food item preparation time taken by food preparation personnel to prepare each of the food items the food order in the food preparation area2104. In an embodiment, the food order management system2102updates the predicted packaged food order ready time based on one or more of the actual food item preparation time taken by food preparation personnel to prepare each of the food items the food order in the food preparation area2104and the actual food item packaging time taken by food packaging personnel to package each of the food items in the food order in the food packaging area2108. In an embodiment, the food order management system2102updates the predicted food order delivery time based on one or more of the actual food item preparation time taken by food preparation personnel to prepare each of the food items the food order in the food preparation area2104, the actual food item packaging time taken by food packaging personnel to package each of the food items in the food order in the food packaging area2108, and changes in delivery route specific data associated with the delivery route associated with delivering the food order to the food order delivery destination.

FIG. 24is a block diagram showing an exemplary system architecture of a system2400for dynamic reservation and waitlist management using precision table turn-time analysis. Although other configurations are possible and not all components may be required, the system in this embodiment comprises a table turn-time analyzer2410, a reservation manager2420, a waitlist manager2430, one or more databases2440, and a web crawler2460. The table turn-time analyzer2410retrieves relevant data such as food order management system data2412, restaurant history data2441and customer history data2442from a database2440, and makes predictions for table-by-table turn times based on current and historical data. The restaurant history data2441comprises data regarding historical table turn-times, and may include data that supplement or augment the historical table turn-times such as differences in turn-times based on a variety of factors such as time of day, day of the week, type(s) of food ordered at a given table, food preparation times, the restaurant staff on duty and their experience levels, customer mix, special event information, and other information that may explain or add precision to the historical table turn-times. The customer history data2442comprises data about repeat customers of the restaurant. The customer history data2442may be acquired in a number of ways. For example, it may be entered manually by restaurant staff who know the customer well (e.g., for “regulars” whose habits the restaurant staff know well), or may be entered when a reservation or seating is made after querying the customer, or may be captured from a customer mobile device b running an application designed to interact with the system. Customer mobile devices2450running an application programmed to connect to, and interact with, the system may supply the system with additional relevant data such as reservation context data2451, group dynamics data2452, and customer location data2453. Reservation context data2451comprises information that suggests a context in which the reservation is being made such as for a particular purpose like a business meeting or a romantic date, for a special event like a wedding or celebration of a sports event win. The context of a reservation may provide important information regarding the length of time that the customer or customers will remain at the restaurant, and therefore may affect table turn-time calculations. Reservation context data2451may be obtained by querying the customer at the time the reservation is made, either in person, on the phone, or through submission of a reservation form online, or by inference from other data such as customer history data (e.g., if customer history data of two customers indicates that they often have business meetings together on Mondays). Reservation context data may further give rise to group dynamics data2452. Group dynamics data2452comprises information related to two or more customers which may further impact the length of stay at the restaurant. For example, a group of single sports fans at a sports bar may stay to watch the entire length of a game, whereas a group of sports fans with kids may not be able to stay for the entire game. Customer location data2453comprises information about the customer's location relative to the restaurant, and may be used by the waitlist manager to prioritize or re-organize waitlist slots. Customer location data2453may be obtained visually (e.g., by restaurant staff) or electronically, for example, by sending a text query to a customer mobile device2450or by having the customer mobile device2450send location information to the system (for example, satellite-based global positioning data).

FIG. 28is a block diagram illustrating an exemplary architecture for an enhanced foodservice management system2800(also referred to hereafter as “system”), according to an embodiment. According to the embodiment, system2800can be configured to receive a food order, determine a desired “delivery” time for the received food order, and manage the preparation of the food order based on the determined delivery time in order to enhance customer satisfaction with the product they receive and to improve both front-of-house and back-of-house staff's communication and production in fulfilling food orders. According to the embodiment, system2800may comprise a food order manager2810configured to supervise the scheduling and preparation of a plurality of food orders, a table manager2820configured to conduct table and waitlist management, a payment facilitation server2830configured to store and manage financial account information and provide user and/or sub-user authorization functionality, and one or more database(s)2840configured to store a plurality of information including, but not limited to, customer information, business (e.g., enterprise, merchant, etc.) information, food information, and table history information, delivery information, and various other types of information. Also present in this embodiment is a business establishment2850similar to business establishment2100(referring toFIG. 21) which may include a payment facilitation device2860, a business computer2851, and one or more business stations2852which may be similar to areas2104-2110. According to an embodiment, payment facilitation device2860may be a specifically configured aspect of payment facilitation device103, referring toFIG. 1.

Business computer may be any suitable computing device such as smart phones, desktop or laptop computers, tablets, or point-of-sale devices, and computing device may connect to a plurality of components such as sensors and scanners configured to obtain user biometric data, routers and switches configured to obtain device identifiers from registered user devices, audio and video input and output devices, a display, a keyboard and/or mouse, and various other peripheral components that may be connected both wirelessly or directly to business computer2851.

According to an embodiment, enhanced foodservice management system2800may be located on premise at a business establishment2850and connected locally to payment facilitation device2860, business computer2851, and business stations2852. According to a different embodiment, enhanced foodservice management system2800may be a cloud-based system wherein system components food order manager2810, table manager2820, databases2840, and payment facilitation server2830may be located and operated in a location remote from business establishment2850and system2800communicates with business establishment2850via an appropriate network connection (not shown) such as, for example, the Internet. According to an aspect of a cloud-based enhanced foodservice management system2800, the system components food order manager2810, table manager2820, databases2840, and payment facilitation server2830may co-located on a single computing device. According to an aspect of a cloud-based enhanced foodservice management system2800, the system components food order manager2810, table manager2820, databases2840, and payment facilitation server2830may be distributed across one or more computing devices.

According to the embodiment, food order manager2810can receive a food order from various sources, a few non-limiting examples shown in this figure include a customer mobile phone2871which can include a software application associated with enhanced foodservice management system2800that allows customers to create an account and order food, among other uses, from a plurality of participating restaurants, a webapp2872which may be accessed via the Internet using any suitable computing device such as, for example, a personal computer, laptop, smart phone, tablet, smart wearable device, and the like, and various3′dparty food order and delivery services2873such as GRUBHUB™, DOORDASH™, etc. The received food order may comprise at least one food item. Food order manager2810may retrieve stored food item preparation time data for at least one food item in the food order from database2840and generate an estimated order preparation time based on the retrieved item preparation time. Food order manager2810can further retrieve, receive, or otherwise obtain a desired delivery time associated with the received food order. Food order manager2810can then assign preparation of the food order based on the desired delivery time and the estimated order preparation time.

According to an embodiment, “delivery” may be an order pickup by a customer, a traditional delivery via a restaurant employee or 3rdparty food delivery service, and/or an order for delivery to a seated table by a server. In a restaurant, the desired “delivery” time would simply be “immediately”. By treating dine-in orders as delivery orders with a fixed delivery time, system2800works seamlessly with in-house seating and dining, as well as take-out and delivery services. A desired delivery time may be specified by the customer as they are placing their order. This may be conducted via a mobile device application, a webapp, or via telephone.

According to an embodiment, food order manager2810may be configured to receive customer permitted device data such as, for example, device location data and/or a device identifier. Food order manager2810may use device location data as an input along with at least one of external data (e.g., map data, traffic data, weather data, social media data, public/private databases, etc.), customer data, delivery data, and estimated food order preparation data to predict an estimated delivery time for take-out orders. In some embodiments, food order manager2810may interact with an en-route food delivery service2811configured to send food order requests comprising at least a food item and an estimated customer arrival time. In a situation where a customer is using a 3rdparty food delivery service2873to order food, the estimated customer arrival time received from en-route food delivery service2811may refer to the 3rdparty delivery driver instead of the customer. Similarly, en-route food delivery service can be used to estimate the return (e.g., arrival) of a business's (e.g., restaurant, etc.) delivery driver and then this estimate can be sent to food order manager2810to be used as an input when predicting estimated delivery times for food orders, specifically food delivery orders performed by restaurant employees. For more detailed information on the en-route food delivery service2811please refer to U.S. application Ser. No. 16/796,505 included herein by reference.

According to the embodiment, table manager2820can receive a seating request. According to an embodiment, a seating request may comprise a quantity of people in dining party and any specified accommodations (e.g., handicap access, table near a window, booth or table, child seating, smoking or non-smoking, etc.). A seating request may be generated by a host or hostess when a customer arrives to the restaurant and requests to be seated or placed on a waitlist/reservation list. A seating request may be generated when a customer virtually “checks-in” to a restaurant using a software application operating on his or her mobile device. The virtual check-in may generate a seating request that is transmitted via a network (e.g., Internet, mobile network, Bluetooth, NFC, etc.) to enhanced foodservice management system2800where it may be received by table manager2820. Responsive to receiving the seating request, table manager2820retrieves a table history from database2840, the table history may comprise: an historical record of table turn-time data, comprising at least the length of time that the table was unavailable for seating; customer data for the table during the turn-time; and order data for the table during the turn time. Table turn-time analyzer2823may be a specifically configured embodiment that provides similar functionality and capability as table-turn time analyzer2410(referring toFIG. 24). Table turn-time analyzer2823estimates a predicted turn-time based on the retrieved table history. Table turn-time analyzer2823may automatically determine a predicted turn-time for each table in the restaurant when a seating request is received. Table manager2820produces an estimated seating time based on the predicted table turn-time and the seating request. A waitlist manager2822and reservation manager2821may be updated based on the estimated seating time and/or the predicted turn-times. Any one of, or some combination of, reservation manager2821, waitlist manager2822, and table turn-time analyzer2823may be separate services and/or modules that can be integrated with and managed by table manager2820to provide enhanced foodservice management functions, and which may be hosted locally on the same computing device as enhanced foodservice management system2800or may be located on separate computing devices connected via an appropriate communication network to facilitate bi-lateral data exchange.

According to an embodiment, table history may comprise an historical record of turn-times associated with a given table. This historical record may comprise information about the length of time that the table was unavailable, the length of time that it was available, average table turn-times, peak and off-peak table-turn times, and various other turn-time metrics which may be calculated, estimated, inferred, derived, or otherwise obtained using any and all available data either stored in database2840or otherwise accessible by enhanced foodservice management system2800. Table history can further comprise customer data for the customers seated at a given table during the turn-time of interest. Customer data that can be retrieved for each member of the dining party may comprise historical customer turn-time data (e.g., how long a customer takes to complete their dining experience), historical food order information, linked device identifier, payment authorizations, and any other information that may be stored in a customer account/profile. Table history can further comprise order data for the table during the turn-time of interest. Order data may comprise one or more food items. Order data may further comprise estimated order preparation time which can be used by table turn-time analyzer2823as a factor to estimate a predicted table turn-time. Table manager2820may also use table reservation data received, retrieved, or otherwise obtained from reservation manager2821when determining an estimated seating time.

According to the embodiment, payment facilitation server2830may be a specifically configured aspect of payment facilitation server200(referring toFIG. 2) which manages customer financial accounts, including master and subordinate account management, and provides functionality for account authorizations including zero-step authorization capabilities using customer biometric data. Payment facilitation server2830can receive user account data from a registered user from a user device2871via a network connection (e.g., WAN, LAN, Internet, cell network, WiFi, etc.), and in some instances the data received may be encrypted. This user information may be stored in database2840. Additionally, payment facilitation server2830may interface with financial services and institutions in order to execute financial account functions such as depositing and withdrawing money into customer configured accounts, processing such funds transfers, and receiving authorization from the registered user to permit a merchant transaction and then send a notification about the attempted transaction to the registered user. This process is described above (FIG. 2) in more detail. Furthermore, payment facilitation server2830can associate a subordinate user with a registered user (sometimes referred to as a master account). Subordinate users may be allowed to use stored funds in accounts configured and controlled by the registered user. According to an embodiment, when a merchant authorization is received from a registered user, payment facilitation server2830may send an authorization confirmation message to food order manager2810and/or table manager2820each of which may use the authorization confirmation message to perform or initiate certain functions.

In the embodiment, system2800may allow for zero-step authentication foodservice via payment facilitation server2830which can be configured to receive device identifiers liked to a mobile device2871of a registered user and perform authentication by comparing the linked device identifier with stored device identifiers. Alternatively, or additionally, customers (i.e., registered users, subordinates users) may provide biometric information for the purpose of authentication within the payment facilitation server2830. Enhanced food management system2800can provide zero-step authentication using biometric data for authentication. Biometric data may include, but is not limited to, behavioral and physiological characteristic data such as fingerprints, voice/speech data, facial image data, eye data, gait data, and the like.

DETAILED DESCRIPTION OF EXEMPLARY ASPECTS

FIG. 4is a diagram illustrating an exemplary business/customer interaction400and showing an exemplary screenshot. In this example, a customer401(who already has an account and registered device402at a business establishment) makes an order. The customer's device402and the payment facilitation device103detect each other and establish a connection when the customer401enters the business establishment. The customer's photograph403is displayed on the business' payment facilitation device103, along with the customer's information404and order details405. An employee of the business clicks on the customer photograph403to confirm the identity of the customer401. Once confirmed, the customer device402automatically approves payment and receives confirmation of the payment without the customer having the handle the device402. The customer device402may remain in the customer's pocket, purse, backpack, etc., and does not have to be removed to complete the transaction.

FIG. 5is a diagram illustrating an exemplary bill splitting feature500and showing an exemplary screenshot. In this example, three customers, Bob501, Sally503, and Joe505, each with their respective mobile devices502,504, and506, have a meal together at a restaurant and want to split the bill among themselves. Each customer's mobile device has a bill splitting application installed on it, which shows a copy of the bill and the customers who dined together. For example, Bob's501mobile device502shows the bill information507for the group on the left-hand side of his screen, and a window for himself508, a window for Sally509, and window for Joe510on the right side. The mobile devices504,506of Sally503and Joe505show similar screens. The windows508,509,510, each show a photo (or other representation) of the customer, a space for allocating items from the bill, and a total of the items allocated to that customer. As each customer, on his or her respective mobile device502,504,506, allocates food and drink items from the bill information507by clicking on them and dragging them to the window of a person on the right, the allocation of those food and drink items appears in the window of the person to whom the item has been allocated, as indicated by the arrows. For example, the risotto Milanese and white wine have been allocated to Bob (either by Bob or by one of the other two customers), a total due from Bob of $26 is shown, and this information is updated on all three mobile devices502,504,506. Once all three customers501,503,505approve the allocation, each person's mobile device502,504,506processes the payment for the amount allocated to that customer. In some embodiments, unallocated items may be automatically split among the customers in the group.

FIG. 6is a flow diagram showing the steps of an exemplary method for registration of a customer's mobile device and order placement. When a customer calls a restaurant a first time to place an order601, the customer's telephone number is captured using UC telephony equipment, and additional customer information is gathered and entered into database by an employee of the business602. The customer then makes his or her order and the order is completed603. Each time the customer makes a subsequent call to same business to place an order604, the customer's telephone number is captured using UC telephone equipment, and the customer's information is retrieved from a customer database using a customer identification application605. The customer than makes his or her order and the order is completed606without the customer having to provide his or her information. The same procedure is used when a customer physically enters a business establishment, except that the registration is performed in person.

FIG. 7is a flow diagram showing the steps of an exemplary method for zero-step authentication and completion of a transaction. When a customer enters a business establishment701, the customer's wireless device and business payment facilitation device detect each other and automatically establish connection702. The business payment facilitation device retrieves the customer device identifier (ID) and uses the customer device ID to retrieve customer information from customer information database located on a payment facilitation server703. The business payment facilitation device displays customer's photo and information to a restaurant employee, who confirms customer's identity by clicking on the photo of the customer704. The customer then places an order705. When the order is placed, the business payment facilitation device sends payment details to payment facilitation server, which either deducts amount from customer's pre-paid account balance or sends charge to payment processors706. Optionally, an additional security step may be inserted wherein the customer's wireless device receives and displays a request for confirmation of the order from the business CIP device and the customer clicks on the displayed request to confirm the order707. Finally, the customer's order is completed708.

FIG. 8is a flow diagram showing the steps of an exemplary method for establishment of an account and pre-authorization of payments. First, a customer establishes an account using his or her customer mobile device and provides payment details (e.g., credit card, debit card, bank details for ACH, etc.)801. The customer then sets an automatic account payment limit, a refill limit, and a refill amount802. For example, the customer may set a payment limit for each transaction at $50, a refill limit (i.e., minimum account balance below which the account will be automatically refilled) of $10, and a refill amount of $100. The customer may choose to have such payments sent automatically without handling his or her mobile device (zero-step authentication)803or may choose to authorize each payment individually using his or her mobile device804. A customer account management application funds the account in the amount of the refill amount using payment details805. Thus, in this example, the customer has pre-authorized payments of up to $50 per transaction, and pre-authorized the system to automatically refill his account from the customer's financial institution (or credit card) in the amount of $100 whenever the account balance falls below $10. When the customer places an order, the customer account management application checks account balance, deducts an amount equal to the amount for the order (after confirmation, if required), and refills account balance using payment information if the account balance falls below the refill limit806.

FIG. 9is a flow diagram showing the steps of an exemplary method for bill splitting among customers. Each customer mobile device runs an application that shows nearby customer devices also using the payment system901. Customers dining together form a group by selecting one another (or accepting a group formation created by one or more of them)902. Each customer's device displays a copy of the itemized bill on one side of the screen, and a photo (or other representational image) of each other customer in the group on the other side of the screen903. One or more of the customers in the group assigns payment by clicking and dragging items from the itemized bill to the photo (or image) of the customer responsible for paying for that item904. When the group is finished assigning payments, each customer approves his/her proposed payment assignments, with unassigned items being distributed equally among the customers in the group905. After all customers in the group have approved their payment assignments, the payment system processes payments from each customer's account according to the approved payment assignments906.

FIG. 10is a flow diagram showing the steps of an exemplary method for funds transfer among customers. Each customer mobile device runs an application that shows nearby customer devices also using the payment system1001. Customers wishing to exchange funds form a group by selecting one another (or accepting a group formation created by one or more of them)1002. Each customer's device displays a photo (or other representational image) of each other customer in the group1003. One or more of the customers in the group proposes a fund transfer by clicking and dragging from one customer to another, creating an arrow between that pair of customers in the group indicating a direction of transfer, and enters an amount of funds to be transferred1004. When the group is finished proposing fund transfers, each customer approves his/her proposed fund transfer(s)1005. After all customers in the group have approved their proposed transfers, the payment system processes payments from each customer's account according to the approved fund transfers1006.

FIG. 17is a method diagram illustrating the function of a system for third-party food and dining and retail purchase ordering control, according to an embodiment. Upon first attempting to use the system and the application therein, a new administrator may connect to the application or web service, through either a web browser such as GOOGLE CHROME™, MICROSOFT EDGE™, SAFARI™, or other web browsers, or it may be connected to and accessed with a specific application1710such as a mobile application on a phone, or a desktop application on a personal computer including laptops and some forms of tablet computers. Upon connecting to the web application, the new admin must establish authentication standards for their new account, such as either or a combination of login information, a pairing with a mobile device, or biometrics1720. Login information may comprise at least a username and password combination, while biometrics may be voice patterns discerned through a microphone recording, facial scanning through the submission of a photo of the user's face, fingerprint scanning, retinal scanning, or other forms of biometrics if desired, or pairing of a specific mobile device which may be recognized upon attempting to pay with the device at an establishment. Login information may then be encrypted and stored in a datastore, for later use. An administrator may then set up sub-users such as dependents, set up bank account or other financial institution connections such as PAYPAL™, and personal account settings1730. These settings may include contact information, username and password changing, notification settings, scheduling settings, sub-user settings, and more, which may be specified using a graphical user interface with, for instance, drop-down menus, text menus, and other elements common for GUI's to allow users to specify settings and preferences. The admin then may deposit money from their preferred financial institution or service, such as a bank account, debit or credit card, PAYPAL™, or other financial institutions or services1740. The admin may set up sub-services in the web application, for instance dietary restrictions, restrictions on groceries or establishments to purchase or purchase from, notifications and who to send notifications to, and may also seed the suggestion engine1750with examples of their interests, classes of objects, foods, restaurants, and styles that interest them, and more. A suggestion engine may be seeded with examples of restaurant, food, or grocery store types or categories, examples of specific establishments or recipes, and then the application may be used to suggest similar establishments or recipes to users when queried. Sub-user data may then be added by the administrator, and subsequently saved to the datastore for identification, in a similar manner to the administrator's own login information1760. This login information for a sub-user such as a dependent, or a doctor's patient, may include a username and password, or biometric information for authentication, or a combination of both. Biometrics that may be utilized include but may not be limited to facial recognition, retinal scanning, and vocal patterns1760. As part of the account setup, administrators may also deposit funds from their connected financial institutions, to be used either by themselves or by any sub-users they have set up in their account. A potential sub-user is then able to go to qualifying establishments and use any deposited funds from the administrator to purchase permitted goods and services, or access suggested services including home recipes, with notifications of actions being sent according to notification engine1770. Purchasing such goods from businesses may be done with zero-step authentication at the premises, such as passively matching their face upon entry into the business or their vocal patterns in a similar manner once they speak to a host or cashier, or they may log in with a swipe of an ID card, or a username and password, or some other method. Upon any attempts at using the deposited funds by a sub-user or even by the administrator as the case may be, notifications may be sent to the admin or to any other specified parties, if applicable1780. For instance, an email notification may be sent to a doctor that the administrator is purchasing certain foods, to alert the doctor of any dietary changes for the patient. Parents may also receive notifications this way about their children purchasing anything in this way, even if the attempt at purchasing is unsuccessful.

FIG. 18is a message flow diagram illustrating the use of a system for third-party food and dining and retail purchase ordering control, according to an embodiment. Devices exchanging messages and data include an admin device1805, which may be a mobile device including a phone or tablet, or a personal computer such as a laptop or desktop, a web application1540operating on a server accessible over the Internet, a POS system1560at a restaurant or store which may communicate over the internet with the web application1540, a third party device1810such as a mobile device or personal computer which may be used by a third party for the purpose of receiving notifications such as emails, SMS messages, or logging into the web application1540to view notifications manually, and a datastore1550that may store data for a web application1540such as user authentication and user settings. A datastore1550may be a SQL database, a non-SQL based database, or other data storing and querying solutions. An admin device1805must send a registration and authentication1815message to the web application1540. An authentication message may be encrypted and then decrypted using matching software and encryption techniques at the endpoint, and may be sent over one of several protocols and methodologies, including using secure API calls in an application, using encrypted POST-GET methods using HTTP, sending data packets directly to an awaiting socket on the destination server, or another method. Then the web application sends the data to a datastore1550for storage1820. Such a datastore may be a SQL database such as MYSQL™ it may be a non-SQL database such as MONGODB™, it may be managed or unmanaged, or it may even be a non-database datastore, such as a data file or some other method of storing data. A point-of-sale system1560then may receive data on a customer attempting to make a purchase, and sends the customer ID, login information, mobile device ID, or biometrics to the web application1540for identification and authentication1825. The customer ID, login information, or biometrics are then queried in the datastore1550by the web application1540,1830. Such an attempt at identifying a user is a one-to-multiple check where a single identifying piece of data, or a few identifying pieces of data taken in concert, are compared to multiple records to locate the matching records of interest, which in this case are likely to be a user and their matching permissions and restrictions and funding. These requests may be sent over a variety of protocols over a variety of networks, including HTTP with POST-GET methods, API calls, communicating over a local or wide area network, communicating over the Internet, or other common networking solutions for communicating with a datastore for authenticating users. The datastore1550responds with the customer data, if any, to the web application1540,1835, in the case of a successful or unsuccessful authentication. An unsuccessful authentication request in this context may refer to a lack of matching data in the datastore compared to the received identifying information, whether due to a lack of such a user in the datastore, a mismatched piece of information supplied by the user, corruption in the data stream either going to or from the datastore or web application, unavailability of the datastore or data in question, and other common sources of issues with authenticating users. In this context, the web application's response in the event of an unsuccessful authentication may or may not discriminate between various reasons with the authentication failed. A failed authentication may also be the result of a lack of funds compared to what the POS has requested, indicating that even though the user may have been identified, they cannot complete the purchase as requested. The web application1540responds to the POS system1560,1840, with the successful or unsuccessful user authentication and funds, indicating whether or not the user may complete the transaction or not. Upon transaction success or failure1840, the web application may notify a third party1845if applicable, and notify the administrator or administrators, if applicable1850. Notifications may be accomplished through a variety of means and networks, including the Internet, phone networks such as a PSTN, SMS messaging, setting a notification flag for the user to read when they next log into the web application, or other notification methods common in the art for web applications to communicate with users.

FIG. 19is a method diagram illustrating the use of a system for third-party food, dining, and retail purchase ordering control, being used for a parent to monitor and control what a child or other dependent may order with deposited funds. A parent or caretaker such as a legal guardian may register an account with a web application, setting up their personal settings and verification criteria such as biometrics, a username and password, pairing a mobile device to then use at the point of sale for identification, or other identification criteria1910. A parent or other caretaker then may specify dependents and dependent accounts, such as children, which may be verified with biometrics, zero-step authentication, traditional logging in with a username and password, or other methods1920. Such user verification may be encrypted or unencrypted during various portions of the transmission to the web application from the time the user provides the data, and may be sent using TCP protocol, HTTP protocol, UDP protocol, HTTPS protocol, or others. The parent or other admin then may specify what the dependents or other sub-users are allowed to purchase with funds in the account, such as limiting their diet or their budget1930, before depositing funds into the account1940. The sub-user or sub-users may enter establishments matched by the requirements set by parent, and order approved items1950, and use the deposited funds for approved items at approved establishments are deducted from app account, without the sub-user personally paying1960, and allowing the parent or other admin to be notified if they set up notification options in the application1970during the initial setup of their settings and preferences1910.

FIG. 20is a method diagram illustrating the use of a system for third-party food, dining, and retail purchase ordering control, being used for a patient to monitor and control what they eat with self-reporting or reporting to a doctor or other third-party, potentially with a doctor dictating the dietary restrictions on the patient account. A patient may register an account with a web application, setting up their personal settings and verification criteria such as biometrics, a username and password, pairing a mobile device to then use at the point of sale for identification, or other identification criteria2010. Such user verification may be encrypted or unencrypted during various portions of the transmission to the web application from the time the user provides the data, and may be sent using TCP protocol, HTTP protocol, UDP protocol, HTTPS protocol, or others. The patient may specify a third party to notify, such as a doctor, dietician or friend who may be dieting with them or helping them keep track of their diet, to notify of their purchases with the application2020. The patient may specify what they are allowed to purchase and where they are allowed to shop or eat, in keeping with a dietary restriction2030, in the same manner of restrictions as in previous methods where an administrator prevents a sub-user from accessing funds for unauthorized purchases. It is possible for the patient to be an administrator and self-regulate their account, or to be a sub-user with a doctor or dietician as the administrator who regulates the account, with the user paying for the deposits into the account, and the administrator regulating what they can then use the deposited money for after the patient deposits funds into the account2040. The patient or dieter may then enter establishments matched by the requirements, and order approved items2050if the funds in the account at least match the minimum required for the purchase, at which point the funds for the approved items at approved establishments are deducted from app account2060. The doctor or diet-buddy or other third-party individual or individuals may be notified as specified by the customer's settings in the application2070, either from the user's settings, or from the administrator settings if the two are not identical, as in the case of the doctor being the administrator and the patient being a sub-user.

Referring toFIG. 22, a flow diagram representation of an example of a method2200of managing preparation of food items in a food order using an embodiment of a food order management system2102is shown. At2202, a food order including one or more food items is received at the food order management system2102. The food order management system2102identifies the food items in the food order at2204and retrieves the estimated food item preparation time for each of the food items in the food order from the food item database. The estimated food item preparation time for a food item is an estimate of the amount of time that it takes food preparation personnel in the food preparation area2104to prepare the food item.

The food order management system2102generates an estimated food order preparation time based on the retrieved estimated food item preparation times for the food items in the food order at2206. The food order management system2102assigns the food order to the earliest available food preparation time in the food preparation area2104at2208and generates a predicted food order ready time for the food order at2210. The predicted food order ready time is based on the assigned food preparation time and the estimated food order preparation time. The predicted food order ready time is the time when the completed food order is expected to be placed in the food order pick-up area2106.

The food order management system2102issues a command to display the food order including the food items in the food order, the estimated food item preparation time for each of the food items in the food order, the estimated food order preparation time, and the predicted food order ready time on a food preparation display and to display the food order including the food items in the food order and the predicted food order ready time on a food order pick-up display at2212.

The food order management system2102tracks the actual food item preparation times for each of the food items in the food order in the food preparation area2104as each food item is being prepared at2214. The food order management system2102adjusts the estimated food order preparation time and the predicted food order ready time for the food order to reflect any differences between the estimated food item preparation times and the actual food item preparation times for the food items in the food order at2216. The food order management system2102updates the estimated food item preparation times for each of the food items in the food order in the food item database based on the actual food item preparation times for the food items at2218.

FIG. 23Ais a flow diagram representation of an example of a method2300of managing delivery of a food order illustrating the flow from receipt to generation of an estimated delivery time. At2302, a food order including one or more food items is received at the food order management system2102. The food order management system2102identifies the food order as being designated for delivery and retrieves the estimated food item packaging time for each of the food items in the food order from the food item database at2304. The estimated food item packaging time for a food item is an estimate of the amount of time that it takes food packaging personnel in the food packaging area2108to package the food item.

The food order management system2102generates an estimated food order packaging time based on the retrieved estimated food item packaging times for the food items in the food order at2306. The food order management system2102assigns the food order to the earliest available food packaging time in the food packaging area2108at2308and generates a predicted packaged food order ready time for the food order at2310. The predicted packaged food order ready time is based on the assigned food packaging time and the estimated food order packaging time. The predicted packaged food order ready time is the time when the packaged food order is expected to be placed in the delivery order area2110.

The food order management system2102identifies a delivery route for the food order based on the food order delivery destination at2312and assigns an earliest available delivery time for the delivery of the food order to the food order delivery destination at2314. The food order management system2102receives delivery route specific data based on the identified delivery route and the received delivery route specific data at2316and generates a predicted food order delivery time at2318. The predicted food order delivery time is the time that the food order is expected to be delivered to the food order delivery destination and is based on the predicted packaged food order ready time, the delivery route, the assigned delivery time, and the expected delivery route specific data.

FIG. 23Bis a flow diagram representation of an example of a method of managing delivery of a food order illustrating the flow from displaying a food order through updating an estimated food packaging time with a food item database. The food order management system2102issues a command to display the food order including the food items in the food order, the estimated food item preparation time for each of the food items in the food order, the estimated food order preparation time, and the predicted food order ready time on a food preparation display, to display the food order including the food items in the food order and the predicted food order ready time on a food order pick-up display, to display the food order including the food items in the food order, the estimated food item packaging time for each of the food items in the food order, the estimated food order packaging time, and the predicted packaged food order ready time on a food packaging display, and to display the food order including the food items, the predicted packaged food order ready time, the assigned delivery time, and the predicted food order delivery time on a delivery order display at2320.

The food order management system2102tracks the actual food preparation times for each of the food items in the food order in the food preparation area2104as each food item is prepared, the actual food packaging times for each of the food items in the food order in the food packaging area2108as each food item is packaged and any changes in the delivery route specific data at2322. The food order management system2102adjusts the estimated food order packaging time, the predicted packaged food order ready time, and the predicted food order delivery time for the food order to reflect any changes in the delivery route specific data, differences between the estimated food item preparation times and the actual food item preparation times and/or differences between the estimated food item packaging times and the actual food item packaging times associated with the packaging of the food items at2324. The food order preparation system2102updates the estimated food item packaging times for each of the food items in food item database based on the actual food item packaging time for the food item at2326.

FIG. 25is a flow diagram showing an exemplary algorithm for implementation of a dynamic table turn-time analyzer2500. In this exemplary algorithm, the process is initiated when a group is seated at a table2505. Restaurant history data2441, customer history data2442, and reservation context data2451are retrieved and analyzed, and a preliminary table turn-time estimate for that table is created2510. For example, if the restaurant history indicates that groups of five persons dining at a particular time of the week are typically business professionals having a quick lunch, it may be expected that the table turn-time for a group of five seated during that time will take 40 minutes. The reservation context data indicates that the group is at the restaurant for a birthday celebration, which would suggest an additional 30 minutes. However, there is customer history for three of the customers that indicates that those three customers rarely stay beyond an hour, suggesting a reduction in table-turn time of 5 minutes, for a preliminary table turn-time estimate of 65 minutes.

The preliminary table turn-time estimate will suggest a particular group dynamic, but it is possible that actual group dynamics are different than expected. Group dynamics may be analyzed2520to determine whether they are as expected or predicted given the data retrieved at the previous step. Group dynamics may be obtained, for example, by comparing customer profiles obtained from each customer's mobile device2450or stored in each customer's customer history data2462, or from manual inputs by restaurant staff. As one example, a comparison of the customer profiles for all of the customers at the table may indicate that, while they are there for a business meeting, they all have a strong interest in golf, which may lead them to stay at the table to discuss golf after the business meeting is concluded, leading to an automated table turn-time adjustment2535. As another example, the table's server may notice that all of the members of the group are wearing shirts with logos of the local sports team, and that they've noticed that their team is playing a game being shown on the bar's television which may cause them to stay longer than expected. If the group dynamics are not as expected or predicted at an earlier stage2530, the table's server may make a manual table turn-time adjustment2535to indicate the change in expected group dynamics, and the table turn-time may be updated, accordingly2540.

Once the customers have ordered2550, their orders may be checked2560against the customer history data2462that was used to create the preliminary table turn-time estimate2510. If the orders do not correspond to the customer history data2462, an adjustment may be made for special or unusual orders2565. At this point, restaurant dynamics are checked2570to determine any known or predicted factors that may affect the table turn-time. Inputs may include data such as current prep time data2541and kitchen staff data2542from the food order management system2102, and server or wait staff data2543indicating the experience and efficiency of the staff Final updates are made to the estimated table turn-time2580, and restaurant and customer histories are updated in response2590.

FIG. 26is a flow diagram showing an exemplary algorithm for implementation of a dynamic reservation manager2600. In this exemplary algorithm, the process is initiated by the receipt of a reservation request2605from a customer. The reservation request2605may be received directly by the system, as in the case of online reservations by the customer, or may be entered by restaurant staff after having communicated with the customer (e.g., by phone, in person, etc.). Restaurant history data2441and customer history data2442are retrieved, and using these data, a table turn time estimate is created for the reservation2610. For example, a solo dining reservation may be made by a customer whose customer history data2442indicates that the customer tends to linger at the table after eating, which would lead to an estimate of a one hour table turn-time. The reservation is made for 6 pm on a Saturday, a time that is particularly busy for the restaurant, adding 30 minutes to the estimate. However, the restaurant history also indicates that the restaurant staff on duty on Saturdays is particularly experienced, leading to a 10 minute reduction in the estimate. Thus, in this example, the table turn-time estimate for the reservation2610would be 80 minutes.

The reservation is then analyzed to determine whether the reservation contains any special requests2620, such as a request for seating at a table in front of the window or other special services the restaurant may offer, such as candle-lit dinners. If the reservation contains special requests, the reservation is tagged with any applicable special conditions2630, such as a minimum order for that reservation or premium pricing like a surcharge for tables next to a window. The special request is then assigned priority2640such that the reservation is given priority over reservations that do not have a special request, and table assignments may be adjusted, accordingly. Table-by-table reservations data2421are then retrieved, and the existing reservations shown in the data are checked to determine table availability for the requested reservation2650. If reservations are available, but there are restrictions on the availability2660, the reservation is tagged with restrictions2670. As an example of a restriction on availability, a table may be available, but only for a time that is shorter than the standard table turn-time for that restaurant. The customer is then notified of any special conditions and restrictions associated with the requested reservation, if any, and the customer's approval of the special conditions and restrictions may optionally be required2680. For example, it may be the case that a reservation contains a special request for a table by the window. A surcharge is applicable for reservation of window tables. A window table is available, but only for a 45 minute period. The customer is notified of the surcharge and availability restriction and the customer's approval of the availability restriction may be required. The notification may be by any means reasonably available in the situation, for example in person, by phone, by text message, or automatically through a website or an application running on the customer's mobile device2450. At this point, the requested reservation is allocated to a particular table for a particular time period2690, and a number of updates are made to data, including updating the restaurant and customer histories2691, updating the estimated table turn-times2692, updating the table-by-table reservation data2693, and updating the predicted schedule for subsequent time periods2694, for example, subsequent days, weeks, or months.

FIG. 27is a flow diagram showing an exemplary algorithm for implementation of a dynamic waitlist manager2700. In this exemplary algorithm, the process is initiated by a request from a customer to be placed on the waitlist (alternatively, wait list) for a table2705. This request may be placed by the customer while at the restaurant or remotely (e.g., by telephone, or through an application running on the customer's mobile device2450, while the customer is en route to the restaurant. A determination is made as to whether the customer is at the restaurant when the reservation is made2710. If the customer is at not the restaurant, the customer's location data2453and traffic data2461are gathered, and the customer's arrival time at the restaurant is estimated2715. If the customer is at the restaurant or the customer's arrival time has been estimated2715, waitlist data2431and table turn-time data2411are retrieved and based on an analysis of the data, the customer is assigned a spot (or slot) on the waitlist2720and notified of the expected wait time2725. A customer on the waitlist may either have placed the request from a remote location, or may wander about or change locations while waiting for a table. For example, if the restaurant is located at a mall or other shopping location, a customer on the waitlist may spend his or her expected wait time shopping. When the customer's table is ready, the customer's status is determined2730. If the customer is at the restaurant, he or she will be seated2770, removed from the waitlist, and updates will occur to restaurant and customer history data2780and estimated table turn-times and reservation data2790. A customer who is not at the restaurant when the table is ready, but who is moving toward the restaurant will be assumed to be returning to the restaurant. That customer's location data2453and traffic data2461may again be retrieved to adjust his or her estimated arrival time2715, and may be re-assigned a later spot on the waitlist2720. A customer who is not at the restaurant when the table is ready and who is moving away from the restaurant will be assumed to be leaving and not returning to the restaurant, and a query is made of the customer's intent2740. The query may be made by any means reasonably available, such as a phone call, a text message, or through an application running on the customer's mobile device2450. If the customer responds2745and indicates that he or she is not returning or does not respond, the customer will be removed from the waitlist2750, and the restaurant and customer history data will be updated2780. The updates may include a reason for the customer's removal, and where the removal was justified (e.g., wait time longer than expected), the customer's history data may be adjusted to prioritize the customer in the waitlist on subsequent visits. Where the removal was not justified, the customer's history data may be adjusted to de-prioritize the customer in the waitlist on subsequent visits. If the customer indicates that he or she is returning, the customer's spot on the waitlist is adjusted2760, and re-assigned2720.

FIG. 29is a flow diagram illustrating an exemplary method2900for providing enhanced foodservice management, according to an embodiment. According to the embodiment, the process begins when enhanced foodservice management system2800obtains a food order2902from one of a plurality of originating sources. The food order may comprise at least one food item and a desired delivery time as specified by a customer, or inferred and/or derived from information obtained regarding a customer or group of customers. Upon receiving a food order, system2800may retrieve stored item preparation data2904from database2840for the at least one food item received with the food order. Then food order manager2810may generate an estimated order preparation time based on the retrieved item preparation time data2906. At step2908food order manager2810may retrieve, receive, or otherwise obtain the desired delivery time as received with the food order. The delivery time may customer selected, or it may be selected by a restaurant front-of-house employee (e.g., waiter or waitress) if the food order corresponds to dine-in eating or walk-in ordering for takeout, for such orders the desired delivery time may be manually or automatically set to “immediately” or some other descriptor indicating food should be prepared as soon as possible. Furthermore, a desired delivery time may be influenced by customer/delivery driver location data and other externally sourced data such as map and traffic data. Once the desired delivery time has been obtained, food order manager2810assigns preparation of the order based on the desired delivery time and the estimated order preparation time at step2910.

At step2912, a table manager2820may receive a seating request for dine-in eating at a restaurant. According to an aspect, the seating request may comprise dining party size (e.g., number of people to be seated), and a special accommodations. Special accommodations may be customer specified at the time of seating request directly by speaking with a restaurant employee (e.g., host or hostess) in person or over a phone when making a reservation, or special accommodations may be customer specified via a mobile device application when submitting a seating and/or reservation request. Upon receiving a seating request, table manager2820may retrieve a table history for one or more tables in the restaurant2914. A table history may comprise: an historical record of a table turn-time, comprising the length of time that the table was unavailable for seating; customer data for the table during the turn-time; and order data for the table during the turn time. In certain aspects, table history may comprise more or less data than what was mentioned above. Table manager2820estimates a predicted table turn-time based on the table history and estimated order preparation time (received from food order manager2810) at step2916. As a last step2918, table manager2820estimates a predicted seating time based on the predicted table turn-time and the seating request. Special accommodations may be flagged and assigned priority status when used as a component for determining a predicted seating time. For example, a received seating request may comprise a special accommodation indicating the dining party wants to be seated at window seat that overlooks a bay the restaurant is located at, and table manager2820can assign priority to this accommodation and can eliminate predicted table turn-times that are associated with tables that do not have a window view.

FIG. 30is a message flow diagram illustrating components of enhanced foodservice management system2800communicating with each other while responsive to a food order and/or seating request being received, according to an aspect. According to the aspect a customer mobile device2871may generate and transmit a food order3005, which may comprise at least one food item, a desired delivery time, and a device identifier, to enhanced foodservice management system2800via food order manager2810. Once a food order request3005has been received, food order manager2810then requests retrieval of item preparation time3010from database2840for each food item in the received food order. The retrieved item preparation time3015may then be used by food order manager2810to estimate a predicted order preparation time based on the retrieved food item preparation time(s) and the desired delivery time. The predicted order preparation time based on the desired delivery time3020can be sent to table manager2820which can use this information to adjust table turn-times based on predicted delivery times as well as update reservation and waitlists as necessary. Enhanced foodservice management system2800may also receive via table manager2820a seating request3025generated and transmitted by customer mobile device2871. Responsive to receiving a seating request3025table manager2820requests retrieval of a table history3030from database2840. Requested table history data3035may be obtained by table manager2820and used to estimate a predicted table turn-time based on the table history as well as estimate a predicted seating time based on the predicted table turn-time and the seating request.

Also present in this embodiment is a payment facilitation device2860which may be configured to receive a device identifier3040from customer mobile device2871. The device identifier may be received from customer mobile device2871as part of the data that is transmitted when a food order is made using a registered user's mobile device2871and submitted electronically. The device identifier may be received when a customer enters a restaurant with a registered user device2871on their person and payment facilitation device2860recognizes the registered user device2871when the two devices connect to each other via a communication network such as, for example, a restaurant's WiFi network, or an NFC beacon communicatively coupled with payment facilitation device2860, to name a few. Payment facilitation device2860then forwards the received device identifier3045to payment facilitation server2830which requests customer information3050associated with the received device identifier from database2840. Payment facilitation server2830can send the customer information3055to payment facilitation device2860which then send a notification with the transaction details3060to customer mobile device2871for customer transaction authorization/authentication. The customer may authenticate the received transaction and send this user authentication3065to payment facilitation server2830which then executes the transaction using stored user financial accounts. The user authentication can comprise a user authenticating a transaction on behalf of a registered sub-account user. For example, a teenager orders a pizza for delivery using a sub-account which was created and supervised by her mother, and when the pizza is ordered her mom would get a notification indicating the details of the food order (e.g., food items ordered, total cost, account or sub-account used for transaction, etc.) the mother can authenticate the transaction which may cause enhanced foodservice management system2800to perform the operations described above.

Hardware Architecture

In addition, in some aspects, servers32may call external services37when needed to obtain additional information, or to refer to additional data concerning a particular call. Communications with external services37may take place, for example, via one or more networks31. In various aspects, external services37may comprise web-enabled services or functionality related to or installed on the hardware device itself. For example, in one aspect where client applications24are implemented on a smartphone or other electronic device, client applications24may obtain information stored in a server system32in the cloud or on an external service37deployed on one or more of a particular enterprise's or user's premises. In addition to local storage on servers32, remote storage38may be accessible through the network(s)31.