+

WO2018136006A1 - Procédé pour faciliter la gestion d'un établissement, et système et dispositif associés - Google Patents

Procédé pour faciliter la gestion d'un établissement, et système et dispositif associés Download PDF

Info

Publication number
WO2018136006A1
WO2018136006A1 PCT/SG2018/050031 SG2018050031W WO2018136006A1 WO 2018136006 A1 WO2018136006 A1 WO 2018136006A1 SG 2018050031 W SG2018050031 W SG 2018050031W WO 2018136006 A1 WO2018136006 A1 WO 2018136006A1
Authority
WO
WIPO (PCT)
Prior art keywords
customer
mobile communication
communication device
order
join
Prior art date
Application number
PCT/SG2018/050031
Other languages
English (en)
Inventor
Chuian Feng LUI
Quan Fu LUI
Chee Kean TAN
Chun Hung Justin YAP
Original Assignee
Dining Butler Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dining Butler Limited filed Critical Dining Butler Limited
Publication of WO2018136006A1 publication Critical patent/WO2018136006A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Definitions

  • the present invention generally relates to a computer-implemented method for facilitating management at an establishment and a system thereof, as well as a computer-implemented method for facilitating table management at an establishment and a mobile communication device thereof, and more particularly, with respect to an establishment in the business of providing food and/or drink to customers.
  • whether a table is available for the customer may be decided by the restaurant staff personally going inside the restaurant and inspecting whether any table is available, or communicating with another restaurant staff inside the restaurant via communication devices (e.g., via walkie-talkie devices) to provide a feedback on whether any table is available. If a table is available, the restaurant staff may then guide the customer into the restaurant and to the available table. Otherwise, the customer may be asked to wait until a table is available.
  • various problems exist with the above-mentioned conventional technique of table allocation For example, it is required for a customer to engage with a restaurant staff in order to find out whether a table at the restaurant is available.
  • the table may also be unnecessarily unoccupied for a certain period of time, resulting in inefficiencies in table occupancy and a loss in potential revenue for the restaurant.
  • the waiting customer may not be promptly updated by the restaurant staff, such as due to a lack of adequate manpower (e.g., the restaurant staff is still busy attending to one or more previous customers, such as showing them to their table and attending to their request).
  • a lack of adequate manpower e.g., the restaurant staff is still busy attending to one or more previous customers, such as showing them to their table and attending to their request.
  • such a conventional technique is still bottlenecked by the capacity and ability of the restaurant staff responsible for handling table allocation.
  • such a computer tablet generally simply provide the ability for the customer(s) occupying the table to order one or more items at the restaurant, but does not provide any payment capability. Therefore, it is usually required for one or more customers occupying the table to ask for the bill to make a full payment for all of the items ordered at the table or the one or more customers have to personally proceed to the restaurant cashier to make the full payment. As a result, customer experience with the restaurant may also be negatively affected, especially if the customer has to wait for an undesirable long period of time before being presented with the bill for payment or while queuing at the restaurant cashier to make the full payment.
  • a computer-implemented method for facilitating management of an establishment comprising a plurality of tables, the method comprising:
  • a table management module at a server associated with the establishment, a first table request from a first mobile communication device associated with a first customer at a first time instance to join a first table of the plurality of tables and a second table request from a second mobile communication device associated with a second customer at a second time instance to join the first table, the second time instance being after the first time instance;
  • the table management module assigning, by the table management module, the first customer as a first controller of the first table if the first customer is determined to be allowed to join the first table; determining, by the table management module in response to the second table request, whether the second customer is allowed to join the first table based on the table occupancy database and if the first customer is detected to have joined the first table, said determining whether the second customer is allowed to join the first table is further based on a first customer authorization response from the first mobile communication device associated with the first customer, the first customer authorization response being in response to a first customer authorization request from the table management module to the first mobile communication device seeking authorization from the first customer on whether to allow the second customer to join the first table; and assigning, by the table management module, the second customer as a second controller of the first table if the second customer is determined to be allowed to join the first table.
  • a system for facilitating management of an establishment comprising a plurality of tables, the system comprising:
  • At least one processor communicatively coupled to the memory and configured to: receive a first table request from a first mobile communication device associated with a first customer at a first time instance to join a first table of the plurality of tables and a second table request from a second mobile communication device associated with a second customer at a second time instance to join the first table, the second time instance being after the first time instance;
  • a computer program product embodied in one or more non-transitory computer-readable storage mediums, comprising instructions executable by at least one processor to perform a method for facilitating management of an establishment comprising a plurality of tables, the method comprising:
  • the table management module assigning, by the table management module, the second customer as a second controller of the first table if the second customer is determined to be allowed to join the first table.
  • a computer-implemented method for facilitating table management at an establishment comprising a plurality of tables comprising:
  • a server authorization response indicating whether the first customer is allowed to join the first table
  • the server authorization response being determined by the server based on a table occupancy database associated with the plurality of tables stored at the server and if one or more other customers are detected to have joined the first table, the server authorization response is determined further based on a customer authorization response from one of the one or more other customers;
  • a mobile communication device comprising:
  • At least one processor communicatively coupled to the memory and configured: send a first table request to a server associated with an establishment comprising a plurality of tables at a first time instance to join a first table of the plurality of tables in response to a first table selection input on the mobile communication device, the mobile communication device being associated with the first customer;
  • a server authorization response indicating whether the first customer is allowed to join the first table
  • the server authorization response being determined by the server based on a table occupancy database associated with the plurality of tables stored at the server and if one or more other customers are detected to have joined the first table, the server authorization response is determined further based on a customer authorization response from one of the one or more other customers;
  • a computer program product embodied in one or more non-transitory computer-readable storage mediums, comprising instructions executable by at least one processor to perform a method for facilitating table management at an establishment comprising a plurality of tables, the method comprising:
  • a server authorization response indicating whether the first customer is allowed to join the first table
  • the server authorization response being determined by the server based on a table occupancy database associated with the plurality of tables stored at the server and if one or more other customers are detected to have joined the first table, the server authorization response is determined further based on a customer authorization response from one of the one or more other customers;
  • FIG. 1 depicts a schematic flow diagram of a method for facilitating management of an establishment comprising a plurality of tables according to various embodiments of the present invention
  • FIG. 2A depicts a schematic block diagram of a system (e.g., server) for facilitating management of an establishment comprising a plurality of tables according to various embodiments of the present invention
  • FIG. 2B depicts a schematic block diagram of another system (e.g., server) for facilitating management of an establishment comprising a plurality of tables according to various embodiments of the present invention
  • FIG. 3 depicts a schematic flow diagram of a method for facilitating table management at an establishment comprising a plurality of tables
  • FIG. 4 depicts a schematic block diagram of a system (e.g., mobile communication device) for facilitating management of an establishment comprising a plurlaity of tables according to various embodiments of the present invention
  • FIG. 5 depicts a schematic block diagram of another system (e.g., mobile communication device) for facilitating management of an establishment comprising a plurlaity of tables according to various embodiments of the present invention
  • FIG. 6 depicts a schematic drawing of an example computer system in which the system as shown in FIGs. 2 A and 2B may be implemented;
  • FIG. 7 depicts a schematic drawing of an example mobile communication device in which the system as shown in FIGs. 4 and 5 may be implemented
  • FIG. 8 depicts a schematic drawing illustrating an overview of a system comprising a server and one or more mobile communication devices according to various embodiments of the present invention
  • FIG. 9 depicts an exemplary schematic overview of a restaurant according to various example embodiments of the present invention.
  • FIG. 10 depicts a flow diagram illustrating various aspects of a method for facilitating management of a restaurant relating to table management according to an example embodiment of the present invention
  • FIGs 11A to 11G show exemplary screenshots on the three mobile devices associated with three different customers/users, respectively, for an exemplary scenario relating to the above-mentioned aspect described with reference to FIG. 10;
  • FIG. 12 depicts a flow diagram illustrating an aspect of a method for facilitating management of a restaurant relating to an order update according to an example embodiment of the present invention
  • FIGs. 13A and 13B show exemplary screenshots on the three mobile devices associated with the three different customers, respectively, for an exemplary scenario relating to the above-mentioned aspect described with reference to FIG. 12;
  • FIG. 14 depicts a flow diagram illustrating an aspect of a method for facilitating management of a restaurant relating to a log in process according to an example embodiment of the present invention
  • FIGs. 15A and 15B show exemplary screenshots on the three mobile devices associated with the three different customers, respectively, for an exemplary scenario relating to the above-mentioned aspect described with reference to FIG. 14;
  • FIG. 16 depicts a flow diagram illustrating an aspect of a method for facilitating management of a restaurant relating to a log out process according to an example embodiment of the present invention
  • FIG. 17 shows exemplary screenshots on the three mobile devices associated with three different customers, respectively, for an exemplary scenario relating to the above- mentioned aspect described with reference to FIG. 16;
  • FIG. 18 depicts a flow diagram illustrating an aspect of a method for facilitating management of a restaurant relating to a table status checking process according to an example embodiment of the present invention
  • FIG. 19 depicts a flow diagram illustrating an aspect of a method for facilitating management of a restaurant relating to an order update process according to an example embodiment of the present invention
  • FIGs. 20A and 20B show exemplary screenshots on three mobile devices associated with the three different customers, respectively, for an exemplary scenario relating to the above-mentioned aspect described with reference to FIG. 19;
  • FIGs. 21 A and 21B show exemplary screenshots on two mobile devices associated with two different customers, respectively, for another exemplary scenario relating to the above-mentioned aspect described with reference to FIG. 19
  • FIG. 22 depicts a flow diagram illustrating an aspect of a method for facilitating management of a restaurant relating to the processing of a confirmed order (e.g., paid or submitted) according to an example embodiment of the present invention
  • FIGs. 23A to 23F show exemplary screenshots on three mobile devices associated with the three different customers, respectively, for exemplary scenarios relating to the above-mentioned aspect described with reference to FIG. 22;
  • FIG. 24A shows an example kitchen screen being displayed for three orders made by the three customers
  • FIG. 24B shows an example waiter screen based on the same three orders as FIG.
  • FIG. 25A depicts three screenshots on the mobile devices associated with the three customers, respectively, at a first time instance when items of their orders are indicated as ready;
  • FIG. 25B depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., a second time instance after the first time instance) after receiving notification that items of their orders are ready;
  • a subsequent time instance e.g., a second time instance after the first time instance
  • FIGs. 26A and 26B depict an exemplary screenshot on an exemplary POS system according to various example embodiments of the present invention
  • FIG. 27 depicts exemplary receipts that may be generated for three orders by the three customers according to various example embodiments of the present invention.
  • Various embodiments of the present invention provide a method (computer- implemented method) for facilitating management of an establishment comprising a plurality of tables, and a system thereof.
  • Various embodiments of the present invention also provide a computer-implemented method for facilitating table management at an establish comprising a plurality of tables, and a mobile communication device (which may be interchangeably referred to herein as a "mobile device") thereof.
  • the establishment may be an establishment in the business of providing food and/or drink to customers (e.g., patrons), such as but not limited to, a restaurant (e.g., ranging from fast food restaurants to fine dining restaurants), a pub, a club, a catering event, and so on.
  • a table described herein may refer to a single table or a predetermined group of two or more tables arranged (e.g., by the establishment management) to constitute one table.
  • a predetermined group of two or more tables may be joined together or arranged adjacent one another to form a larger table for various purposes.
  • customer experience with the restaurant may be negatively affected, especially if the customer has to wait for an undesirably long period of time before being served or being seated at table.
  • Various embodiments of the present invention seek to overcome, or at least ameliorate, one or more of the deficiencies of conventional techniques in managing an establishment, such as the conventional techniques as mentioned in the background.
  • FIG. 1 depicts a schematic flow diagram of a method 100 (computer- implemented method) for facilitating management of an establishment comprising a plurality of tables according to various embodiments of the present invention.
  • the establishment may be an establishment in the business of providing food and/or drink to customers.
  • the establishment is a restaurant, and the plurality of tables is configured for accommodating customers to dine at the restaurant.
  • the method 100 may correspond to functions/operations performed by a computer server (which may be simply referred to as a "server” herein) associated with the establishment.
  • a computer server which may be simply referred to as a "server” herein
  • a server in being associated with an establishment, may be located within or near the establishment or located remote from the establishment, as long as the server is configured to perform the method 100 with respect to the establishment and is to be able to communicate with various systems and devices located within the restaurant and vice versa, such as via any wired or wireless communication protocol known in the art.
  • a server may be realized by or implemented as one unit or a plurality of units (e.g., located at one location or at different locations), as long as the one unit or the plurality of units are configured to perform the method 100 with respect to the establishment.
  • the method 100 comprises a step 102 of receiving, by a table management module at a server associated with the establishment, a first table request from a first mobile communication device associated with a first customer at a first time instance to join a first table of the plurality of tables and a second table request from a second mobile communication device associated with a second customer at a second time instance to join the first table, the second time instance being after the first time instance; a step 104 of determining, by the table management module in response to the first table request, whether the first customer is allowed to join the first table based on at least a table occupancy database associated with the plurality of tables stored at the server; a step 106 of assigning, by the table management module, the first customer as a first controller of the first table if the first customer is determined to be allowed to join the first table; a step 108 of determining, by the table management module in response to the second table request, whether the second customer is allowed to join the first table based on the table occupancy database and if the first customer is detected
  • the first table request may be generated by the first mobile communication device in response to a first table selection input by the first customer on the first mobile communication device.
  • the first table selection input corresponds to a table of the plurality of tables at the establishment which the first customer associated with the first mobile communication device desires to join or secure.
  • the table occupany database may be a database comprising information related to each table of the plurality of tables, respectively, at the establishment.
  • the information may include a unique table identifier (e.g., a table number and/or name), a current status/state of the table and an indication or a record of each customer (one or more customers) that has joined the table (e.g., currently occupying the table), such as a list of one or more customer accounts (e.g., a unique customer account identifier, such as customer account number and/or name), corresponding to the one or more customers, linked to the table.
  • a unique table identifier e.g., a table number and/or name
  • customer account number and/or name e.g., a unique customer account identifier, such as customer account number and/or name
  • the current status of the table may include one or more of an available or open status/state indicating that the table is unoccupied and an occupied status/state indicating that the table has been joined by one or more customers (e.g., currently being occupied by one or more customers).
  • the current status may further include one or more of a busy status/state indicating that the customer(s) that joined the table has submitted their order(s), a paid status/state indicating that all order(s) by customer(s) that joined the table has been paid, and a cleared status/state indicating that the customer(s) that joined the table has left the table and/or left the establishment.
  • determining whether the first customer is allowed to join the first table based on at least the table occupancy database may include determinining that the first customer is allowed to join the first table if the status of the first table is detected/determined to be at an available status (i.e., no customer has joined the first table).
  • the table management module may be configured to store in the table occupancy database an indication or a record that the first customer has joined the first table.
  • an indication or a record of the first customer in the table occupancy database may be interpreted or classified according to various embodiments as a first controller of the first table.
  • the table management module may be configured to determine that the second customer is allowed to join the first table if the first table is detected/determined to be at an available status from the table occupancy database. Furthermore, if it is also detected/determined that the first customer has joined (e.g., based on the table occupancy database), whether the second customer is allowed to join the first table is further determined based on a first customer authorization response from the first mobile communication device associated with the first customer.
  • the first customer authorization response is in response to a first customer authorization request from the table management module to the first mobile communication device seeking authorization from the first customer on whether to allow the second customer to join the first table.
  • the table management module may be configured to store in the table occupancy database an indication or a record that the second customer has joined the first table.
  • an indication or a record of the second customer in the table occupancy database may be interpreted or classified according to various embodiments as a second controller of the first table.
  • the first and second customers are assigned as the first and second controllers of the first table, they are co-controllers of the first table (e.g., with the same authority to decide whether to allow any new customer from joining the table).
  • customer(s) may simply be referred to as customer(s) at the table.
  • various embodiments of the present invention advantageously provide a method for facilitating management of an establishment that enables customers to self-manage table allocations/assignments at the establishment.
  • the establishment being a restaurant
  • customers may no longer have to wait unnecessarily to find out whether a table is available at the restaurant and/or wait unnecessarily to be seated at a table even when a table is available.
  • the method advantageously eliminates, or at least minimize, the need for customers to engage with a restaurant staff in order to try to secure a table at a restaurant.
  • the table allocation stage may no longer be bottlenecked by the capacity and ability of the restaurant staff responsible for handling table allocation for customers.
  • customer experience with the restaurant may improve significantly.
  • the table turnover rate may also improve, thus leading to a potential increase in revenue for the restaurant.
  • a server associated with the restaurant e.g., a database (e.g., table occupancy database), and a user device (e.g., customer's mobile communication device) interact with the method 100 for facilitating management of an establishment to a material extent (e.g., for enabling customers to self-manage table allocations at a restaurant) and in such a manner as to address various specific or technical problems, such as those as described above.
  • a material extent e.g., for enabling customers to self-manage table allocations at a restaurant
  • various embodiments of the present invention advantageously assign customers that have joined a table at the restaurant as controllers (e.g., co- controllers) of the table, thus providing control to each customer on whether to accept any new customer requesting to join the same table.
  • controllers e.g., co- controllers
  • each customer at the table is provided with an opportunity to accept and/or decline a new customer to join the table, thus advantageously providing control of the table to each customer at the table.
  • a customer authorization response may be provided by any one of the customers at the table.
  • Such an approach advantageously enhances the reliability of the method 100 (e.g., less prone to errors) compared to if only one customer is assigned as a controller amongst a group of customers that have joined the table since the control of the table is decentralized amongst the group of customers.
  • a problem may arise if the mobile communication device of that one customer runs out of battery or if the customer of the mobile communication device is preoccupied with other tasks on the mobile communication device or is unaware or ignores the new customer authorization request by the new customer.
  • the method 100 further comprises a step of receiving, by the table management module, a third table request from a third mobile communication device associated with a third customer at a third time instance to join the first table, the third time instance being after the second time instance; and a step of determining, by the table management module in response to the third table request, whether the third customer is allowed to join the first table based on the table occupancy database and if the first and second customers are detected to have joined the first table, the above-mentioned of determining whether the third customer is allowed to join the first table is further based on the earliest customer authorization response from amongst the first and second mobile communication devices.
  • the third customer may be a friend of one of the customers at the table, and although all customers at the table may each receive a customer authorization request on their respective mobile communication device (that is, any one of the customers at the table may authorize the new customer to join the same table), the customer at the table who is the friend of the new customer may be the first to react and provide the customer authorization response to allow the new customer to join the same table.
  • the number of table requests is not limited to three, and fewer or more table request(s) may be received by the table management module based on the number of customers seeking the join the table. For example, each new table request received may go through the same or similar process as the third table request.
  • the method 100 further comprises controlling, by the table management module, whether to process the first table request from the first mobile communication device to determine whether the first customer is allowed to join the first table based on a location of the first mobile communication device with respect to the establishment, and/or whether to process the second table request from the second mobile communication device to determine whether the second customer is allowed to join the first table based on a location of the second mobile communication device with respect to the establishment. For example, whether to process a table request for a table at a restaurant may be based on whether the mobile communication device is determined to be sufficiently close to the restaurant.
  • such a control by the table management module may be implemented by setting a predefined parameter (e.g., a predefined distance) and determining whether the location of the mobile communication device satisfies the predefined parameter (e.g., within the predefined distance).
  • the table management module may receive a signal comprising the table request and the location data of the mobile communication device.
  • the mobile communication device may include a positioning module capable of detecting/determining its location based on GPS and/or Wi-Fi signals and generate the corresponding location data. As the location of the establishment is known, the distance between the mobile communication device and the establishment may thus be determined.
  • Another technique may be based on a time-of-flight information (TOF) of a signal (e.g., a beacon) sent by the server (e.g., including a wireless beacon transceiver) and received by the mobile communication device.
  • TOF time-of-flight information
  • the predefined parameter may be set by the establishment (e.g., a staff managing the establishment) as appropriate or as desired. In various example embodiments, the predefined parameter may be set such that only table requests from customers in the vicinity or close proximity to the restaurant will be processed.
  • the method 100 further comprises setting, by the table management module, a state/status of the first table to an available state upon the expiry of a predefined time period in which one or more customers have been allowed to join the first table and no order has been made by any one of the one or more customers.
  • a predefined time period in which one or more customers have been allowed to join the first table and no order has been made by any one of the one or more customers.
  • the state of the table may then be changed from an occupied state to an available state.
  • the predefined time period may be set by the establishment (e.g., a staff managing the establishment) as desired or as appropriate.
  • the above-mentioned assigning the first customer as a first controller of the first table comprises linking, by the table management module, an account associated with the first customer to the first table.
  • the account is a guest account created for the first customer if the first customer has not logged in or an individualized customer account created for the first customer if the first customer has logged in.
  • assigning the second or a new customer as a second or a new controller of the first table may also comprise linking an account associated with the second customer or new customer to the first table.
  • the account may also be a guest account created for the second or new customer if the second or new customer has not logged in or an individualized customer account created for the second or new customer if the second or new customer has logged in.
  • an individualized customer account may be a customer account created based on (e.g., to include) one or more particulars of the corresponding customer, such as but not limited to, one or more of name, telephone number, email address, home address, photo, and so on.
  • a guest account may be a customer account that is created without such one or more particulars of the corresponding customer.
  • the method further comprises switching, by the table management module, the account associated with the first customer being linked to the first table from the guest account to the individualized customer account in response to the first customer logging in to the individualized customer account from the guest account. More particularly, such a switching includes transferring one or more items added to an order, if any, by the first customer under the guest account to be under the individualized customer account. For example, if the individualized customer account is simply linked to the first table without the above-mentioned switching being performed, the individualized customer account may erroneously be considered as being a new customer.
  • the above-mentioned switching advantageously addresses such a problem, as well as enhancing usability (e.g., minimizing any inconvenience to the customer) as one or more items added to an order by the customer is also transferred to the logged in account (individualized customer account).
  • the method 100 further comprises a step of maintaining, at the second mobile communication device associated with the second customer by an order management module at the server, a first current list of one or more items added to a first order by the first customer via the first mobile communication device, and a step of maintaining, at the first mobile communication device associated with the first customer by the order managment module, a second current list of one or more items added to a second order by the second customer via the second mobile communication device.
  • the current list of one or more items added by a customer to their order is also supplied to each other customer that has joined the table such that each other customer may also have access (e.g., be able to view) the current list of one or more items added by the customer on their respective mobile communication device.
  • any changes by a customer on their order may also be immediately reflected to each other customer at the table.
  • this provides a number of advantages, including the ability for a customer to see what the other customers are ordering (e.g., to get ideas) and also enables the customer to selectively pay for any one or more of the orders made by the other customers at the table as desired by the customer.
  • the method 100 further comprises a step of receiving, by a payment module at the server, a first payment request from the first mobile communication device associated with the first customer to pay for at least the second order or a second payment request from the second mobile communication device associated with the second customer to pay for at least the first order, and a step of sending, by the payment module, a first payment request notification to the second mobile communication device for setting the second order on the second mobile communication device to be in a lock state to prevent the second order from being modified by the second customer in response to the first payment request, or a second payment request notification to the first mobile communication device for setting the first order on the first mobile communication device to be in a lock state to prevent the first order from being modified by the first customer in response to the second payment request.
  • the payment module may receive a payment request from a mobile communication device associated with a customer to pay for the customer's order as well as one or more other customers' orders made by other customers at the table.
  • the payment module may be configured to send a payment request notification to each mobile communication device of the one or more other customers whose orders have requested to be paid by the paying customer.
  • a payment request notification may be configured for setting the order on the respective mobile communication device to be in a lock state to prevent the order on the respective mobile communication device from being modified by the respective customer.
  • the ordering function on each respective mobile communication device may be disabled. For example, this advantageously avoids any mismatch or discrepancy between the order which a customer is in the process of paying for and the actual order.
  • the method 100 further comprises sending, by the payment module, a first payment confirmation notification to the second mobile communication device upon payment of the second order via the first mobile communication device or a second payment confirmation notification to the first mobile communication device upon payment of the first order via the second mobile communication device.
  • a payment confirmation notification would be sent to the customer (i.e., to its mobile communication device) to inform the customer that his/her order has been paid for.
  • a predetermined order and payment completion page e.g., payment thank you page
  • the method 100 further comprises a step of sending, by a kitchen module at the server, the first order and/or the second order, upon being submitted or paid, to a display device (e.g., a kitchen display device) for displaying information on the first order and/or the second order; a step of receiving, by the kitchen module, a first order ready input indicating that one or more items of the first order is ready and/or a second order ready input indicating that one or more items of the second order is ready; and a step of sending, by the kitchen module, a first order ready notification to the first mobile communication device indicating that the one or more items of the first order is ready in response to the first order ready input received and/or a second order ready notification to the second mobile communication device indicating that the one or more items of the second order is ready in response to the second order ready input received.
  • a display device e.g., a kitchen display device
  • a food preparation area (which may interchangably be referred to as a "kitchen") of a restaurant may have a display device configured to display information on one or more orders to the kitchen staff to prepare the order.
  • the kitchen staff may provide an order ready input to the kitchen module via a user interface (e.g., Graphical User Interface (GUI)), such as via a touch screen of the display device or an input device (e.g., keyboard and/or mouse).
  • GUI Graphical User Interface
  • the kitchen module may then generate and send an order ready notification to the mobile communication device to inform that the order made by the customer via the mobile communication device is ready.
  • the customer may then be aware that the item(s) ordered will be delivered soon or the customer may then proceed to retrieve the item(s) at a pickup counter if the restaurant is self-service.
  • the method 100 advantageously enables customers to self-manage table allocations at an establishment (e.g., a restaurant), as well as improving customer experience at the establishment, such as the overall dining experience at a restaurant, and improves management of the establishment, such as maximising or optimising the table occupancy rate.
  • an establishment e.g., a restaurant
  • improving customer experience at the establishment such as the overall dining experience at a restaurant
  • improves management of the establishment such as maximising or optimising the table occupancy rate.
  • FIG. 2A depicts a schematic block diagram of a system 200 for facilitating management of an establishment comprising a plurality of tables according to various embodiments of the present invention, such as corresponding to the method 100 for facilitating management of an establishment as described hereinbefore according to various embodiments of the present invention.
  • the system 200 may correspond to, or may be embodied as, a server associated with the establishment.
  • the system 200 comprises a memory 202, and at least one processor 204 communicatively coupled to the memory 202 and configured to: receive a first table request from a first mobile communication device associated with a first customer at a first time instance to join a first table of the plurality of tables and a second table request from a second mobile communication device associated with a second customer at a second time instance to join the first table, the second time instance being after the first time instance; determine, in response to the first table request, whether the first customer is allowed to join the first table based on at least a table occupancy database associated with the plurality of tables stored at the server; assign the first customer as a first controller of the first table if the first customer is determined to be allowed to join the first table; determine, in response to the second table request, whether the second customer is allowed to join the first table based on the table occupancy database and if the first customer is detected to have joined the first table, the above-mentioned determine whether the first customer is allowed to join the first table is further based on a
  • the at least one processor 204 may be configured to perform the required functions or operations through set(s) of instructions (e.g., software modules) executable by the at least one processor 204 to perform the required functions or operations. Accordingly, as shown in FIG.
  • the system 200 may further comprise a table management module or circuit 206 configured to receive a first table request from a first mobile communication device associated with a first customer at a first time instance to join a first table of the plurality of tables and a second table request from a second mobile communication device associated with a second customer at a second time instance to join the first table, the second time instance being after the first time instance; determine, in response to the first table request, whether the first customer is allowed to join the first table based on at least a table occupancy database associated with the plurality of tables stored at the server; assign the first customer as a first controller of the first table if the first customer is determined to be allowed to join the first table; determine, in response to the second table request, whether the second customer is allowed to join the first table based on the table occupancy database and if the first customer is detected to have joined the first table, the above- mentioned determine whether the first customer is allowed to join the first table is further based on a first customer authorization response from the first mobile communication device associated with the first customer, the first customer
  • the at least one processor 204 may be configured to execute computer-executable instructions (e.g., the table management module 206 and other module(s) as appropriate) to perform one or more of the required or desired functions
  • the memory (computer-readable storage medium) 202 may be communicatively coupled to the at least one processor 204 and may have stored therein one or more sets of computer-executable instructions (e.g., the table management module 206 and other module(s) as appropriate).
  • the system 200 corresponds to the method 100 as described hereinbefore with reference to FIG. 1, therefore, various functions or operations configured to be performed by the least one processor 204 may correspond to various steps of the method 100 described in hereinbefore, and thus need not be repeated with respect to the system 200 for clarity and conciseness.
  • various embodiments described herein in context of the methods are analogously valid for the respective systems or devices, and vice versa.
  • the memory 202 may further have stored therein an order management module, a payment module, and/or a kitchen module, as described herebefore with respect to the method 100 according to various embodiments of the present invention, which are executable by the at least one processor 204 to perform the corresponding functions/operations as described.
  • FIG. 2B depicts a schematic block diagram of a system 250 for facilitating management of an establishment comprising a plurality of tables according to various embodiments of the present invention, which may be the same or similar as the system 200 described with reference to FIG. 2A, except that the system 250 further comprises one or more additional modules stored in the memory 202 according to various embodiments of the present invention, such as the order management module 252, the payment module 254 and/or the kitchen module 256 as described hereinbefore according to various embodiments of the present invention.
  • FIG. 3 depicts a schematic flow diagram of a method 300 (computer- implemented method) for facilitating table management at an establishment comprising a plurality of tables.
  • the establishment may be an establishment in the business of providing food and/or drink to customers, such as a restaurant.
  • the method 300 may correspond to functions/operations performed by a mobile communication device associated with a customer (e.g., the customer's mobile communication device).
  • the method 300 may relate to the method 100 as described hereinbefore in the sense that the method 300 corresponds to the functions/operations performed at the user/customer end (e.g., by a mobile communication device associated with a customer), whereas the method 100 corresponds to functions/operations perfomed at the server/establishment end (e.g., by a server associated with the establishment). Therefore, it can be understood that various steps of the method 100 described hereinbefore according to various embodiments may also be applicable to the method 300, but from the perspective of the user/customer end.
  • the method 300 comprises a step 302 of sending, by a table management module at a first mobile communication device associated with a first customer, a first table request to a server associated with the establishment at a first time instance to join a first table of the plurality of tables in response to a first table selection input on the first mobile communication device; a step 304 of receiving, by the table management module in response to the first table request, a server authorization response indicating whether the first customer is allowed to join the first table, the server authorization response being determined by the server based on a table occupancy database associated with the plurality of tables stored at the server and if one or more other customers are detected to have joined the first table, the server authorization response is determined further based on a customer authorization response from one of the one or more other customers; a step 306 of determining, by the table management module, whether to join the first table based on the server authorization response received, a step 308 of receiving, by the table management module, a new customer authorization request from the server in response to a new table request from
  • the first table request may be generated by the first mobile communication device in response to a first table selection input by the first customer on the first mobile communication device.
  • the first table selection input corresponds to a table of the plurality of tables at the establishment which the first customer associated with the first mobile communication device desires to join or secure. In other words, by sending the first table request to the server, the first customer is requesting with the server to join the first table.
  • the server authorization response may be generated and sent by the server to the first mobile communication device based on its determination on whether the first customer is allowed to join the first table.
  • the server authorization response may be a positive response, such as "accept”, to indicate that the first customer is allowed to join the first table, otherwise, the server authorization response may be a negative response, such as "reject", to indicate that the first customer is not allowed to join the first table.
  • determining whether the first customer is allowed to join the first table may be based on a table occupany database associated with the plurality of tables stored at the server and if one or more other customers are detected (e.g., based on the table occupany database) to have joined the first table, whether the first customer is allowed to join the first table is further determined based on a customer authorization response from one of the one or more other customers at the first table.
  • the table management module may be configured to determine to join the first table if the server authorization response is a positive response, otherwise, the table management module may be configured to determine to not join the first table if the server authorization response is a negative response.
  • the table management module at the first mobile communication device associated with the first customer may receive a new customer authorization request from the server if a new table request from a new customer to join the first table is received by the server.
  • the first customer is provided with an opportunity to accept (e.g., if the new customer is a friend which the first customer is expecting) or reject (e.g., if the first customer is not expecting anyone or the new customer is unknown to the first customer) the new customer.
  • the decision of the first customer may be entered on the first mobile communication device as a customer authorization input, which may then be sent to the server as a new customer authorization response.
  • the new customer authorization response may be a positive response, such as "accept”, to indicate that the new customer is allowed to join the first table, otherwise, the new customer authorization response may be a negative response, such as "reject", to indicate that the new customer is not allowed to join the first table.
  • the method 300 for facilitating table management advantageously enables customers to self-manage table allocations/assignments at an establishment, such as a restaurant.
  • an establishment such as a restaurant
  • customers may no longer have to wait unnecessarily to find out whether a table is available at the restaurant and/or wait unnecessarily to be seated at a table even when a table is available.
  • the method advantageously eliminates, or at least minimize, the need for customers to engage with a restaurant staff in order to try to secure a table at a restaurant.
  • the table allocation stage may no longer would be bottlenecked by the capacity and ability of the restaurant staff responsible for handling table allocation for customers.
  • customer experience with the restaurant may improve significantly.
  • the table turnover rate may also improve thus leading to a potential increase in revenue for the restaurant.
  • a server associated with the establishment e.g., a database (e.g., table occupancy database), and a user device (e.g., customer's mobile communication device) interact with the method 300 for facilitating management of an establishment to a material extent (e.g., for enabling customers to self-manage table allocations at a restaurant) and in such a manner as to address various specific or technical problems, such as those as described above.
  • a material extent e.g., for enabling customers to self-manage table allocations at a restaurant
  • the method 300 further comprises maintaining, by an account management module at the first mobile communication device, an account associated with the first customer after the first customer has been allowed to join the first table.
  • the account is linked to the first table upon the first customer being allowed to join the first table, such as in the table occupancy database at the server so as to serve as an indication or a record that the first customer has been allowed to join the first table.
  • an indication or a record of the first customer in the table occupancy database may be interpreted or classified according to various embodiments as a first controller of the first table.
  • the account is a guest account created for the first customer if the first customer has not logged in or an individualized customer account created for the first customer if the first customer has logged in.
  • the method 300 may further comprise switching, by the account management module, the account associated with the first customer being linked to the first table from the guest account to the individualized customer account in response to the first customer logging in to the individualized customer account from the guest account. More particularly, such a switching includes transferring information one or more items added to an order, if any, by the first customer under the guest account to be under the individualized customer account.
  • the above-mentioned switching by the account management module may include receiving login information (e.g., account name and password) from the first customer and verifying the login information with an account database comprising account information (e.g., name and password) for each customer recorded, such as, at a server associated with the establishment.
  • the account at the first mobile communication device would then be switched to the corresponding individualized customer account, along with a transfer (e.g., moving or copying) of information on one or more items added to an order, if any, by the first customer under the guest account to be under the individualized customer account.
  • the individualized customer account for the first customer would also be linked to the first table instead of the guest account upon the first customer logging in to the individualized customer account from the guest account.
  • the method 300 further comprises a step of receiving from the server, by an order management module at the first mobile communication device, a current information on one or more items added to a second order by a second customer if the second customer is detected to have joined the first table; and a step of providng access to the current information associated with the second order received on the first mobile communication device for display.
  • the order management module of the first mobile communication device is not only configured to receive information on item(s) added to an order by the first customer associated with first mobile communication device, but is also configured to receive information on item(s) added to one or more other orders (e.g., all other orders) by one or more other customers, respectively, at the same table.
  • each order may be presented or accessible separately from each other, and may be separately selectable by the first customer (e.g., selectable tabs in a GUI) on the first mobile communication device for viewing.
  • first customer e.g., selectable tabs in a GUI
  • this provides a number of advantages, including the ability for a customer to see what the other customers are ordering (e.g., to get ideas) and also enables the customer to selectively pay for any one or more of the other orders made by the other customers at the table as desired by the customer.
  • the method 300 further comprises a step of receiving, by a payment module at the first mobile communication device, a first payment option input to pay for at least the second order by the first customer via the first mobile communication device; and sending, by the payment module, a first payment request based on the first payment option input from the first mobile communication device to the server.
  • the payment module at the mobile communication device of the customer may generate a payment request to pay for the customer's order as well as one or more other customers' orders made by corresponding one or more other customers at the table.
  • the customer is able to view the orders of one or more other orders made by corresponding one or more other customers at the table, and thus may also select one or more of such other orders for payment.
  • the payment request may then be sent to the server for further processing, such as described hereinbefore with respect to the method 100 according to various embodiments of the present invention.
  • the payment module at the server may be configured to send a payment request notification to each mobile communication device of the one or more other customers whose orders have requested to be paid for by the paying customer.
  • a payment request notification may be configured for setting the order on the respective mobile communication device to be in a lock state to prevent the order on the respective mobile communication device from being modified by the respective customer.
  • the ordering function on each respective mobile communication device may be disabled. For example, this advantageously avoids any mismatch or discrepancy between the order which a customer is in the process of paying for and the actual order.
  • the method 300 further comprises receiving, by the order management module at the first mobile communication device, a payment request notification from the server, the payment request notification being in response to a second payment request from the second mobile communication device to the server to pay for at least a first order added by the first customer on the first mobile communication device; setting, by the order management module in response to the payment request notification, the first order on the first mobile communication device to be in a lock state for preventing the first order from being modified by the first customer.
  • the method 300 further comprising setting, by the order management module, the first order to be in a free state for allowing the first order to be modified upon the expiry of a predefined time period in which the payment request notification has been received and no payment confirmation notification for the first order has been received by the first mobile communication device from the server.
  • a predefined time period may be set by the establishment (e.g., a staff of the establishment) as desired or as appropriate.
  • the method 300 further comprises a step of receiving, by the order management module, a first order ready notification from the server, the first order ready notification being in response a first order ready input received by the server indicating that one or more items of the first order is ready; and a step of presenting (e.g., displaying or invoking a sound) the first order ready notification on the first mobile communication device.
  • a food preparation area of a restaurant may have a display device configured to display information on one or more orders to the kitchen staff to prepare the order.
  • the kitchen staff may provide an order ready input to the kitchen module via a user interface (e.g., GUI), such as via a touch screen of the display device or an input device (e.g., keyboard and/or mouse).
  • a user interface e.g., GUI
  • the kitchen module may then generate and send an order ready notification to the mobile communication device via the server to inform that the order made by the customer via the mobile communication device is ready.
  • the order ready notification received may then be presented on the mobile communication device, such as by displaying a pop-up notification on the GUI or invoking a sound notification.
  • the customer may then be aware that the items ordered will be delivered soon or the customer may then proceed to retrieve the item(s) at a pickup counter if the restaurant is self- service.
  • the method 300 advantageously enables customers to self-manage table allocations at an establishment (e.g., a restaurant), as well as improving customer experience at the establishment, such as the overall dining experience at a restaurant, and improves management of the establishment, such as maximising or optimising the table occupancy rate.
  • an establishment e.g., a restaurant
  • improving customer experience at the establishment such as the overall dining experience at a restaurant
  • improves management of the establishment such as maximising or optimising the table occupancy rate.
  • FIG. 4 depicts a schematic block diagram of a system 400 for facilitating management of an establishment comprising a plurlaity of tables according to various embodiments of the present invention, such as corresponding to the method 300 for faciltating table management at an establishment comprising a plurality of tables according to various embodiments of the present invention.
  • the system 400 may correspond to, or may be embodied as, a mobile communication device associated with a customer, such as, but not limited to, smart phones, smart watches, tablet computers, and so on.
  • the mobile communication device 400 comprises a memory 402 and at least one processor 404 communicatively coupled to the memory 402 and configured: send a first table request to a server associated with an establishment comprising a plurality of tables at a first time instance to join a first table of the plurality of tables in response to a first table selection input on the mobile communication device 400, the mobile communication device 400 being associated with the first customer; and receive, in response to the first table request, a server authorization response indicating whether the first customer is allowed to join the first table, the server authorization response being determined by the server based on a table occupancy database associated with the plurality of tables stored at the server and if one or more other customers are detected to have joined the first table, the server authorization response is determined further based on a customer authorization response from one of the one or more other customers; determine whether to join the first table based on the server authorization response received; receive a new customer authorization request from the server in response to a new table request from a new customer requesting to join the first table; and provide, in response
  • the first table selection input or any other user input on the mobile communication device may be made via one or more input modules supported by the mobile communication device 400, such as but not limited to, a touch screen, a microphone, a camera, and/or one or more virtual buttons.
  • the at least one processor 404 may be configured to perform the required functions or operations through set(s) of instructions (e.g., software modules) executable by the at least one processor 404 to perform the required functions or operations. Accordingly, as shown in FIG.
  • the mobile communication device 400 may further comprise a table management module or circuit 408 configured: send a first table request to a server associated with an establishment comprising a plurality of tables at a first time instance to join a first table of the plurality of tables in response to a first table selection input on the mobile communication device 400, the mobile communication device 400 being associated with the first customer; and receive, in response to the first table request, a server authorization response indicating whether the first customer is allowed to join the first table, the server authorization response being determined by the server based on a table occupancy database associated with the plurality of tables stored at the server and if one or more other customers are detected to have joined the first table, the server authorization response is determined further based on a customer authorization response from one of the one or more other customers; determine whether to join the first table based on the server authorization response received; receive a new customer authorization request from the server in response to a new table request from a new customer requesting to join the first table; and provide, in response to the new customer authorization request, a new customer authorization response to the
  • the at least one processor 404 may be configured to execute computer-executable instructions (e.g., the table management module 408 and other module(s) as appropriate) to perform one or more of the required or desired functions
  • the memory (computer-readable storage medium) 402 may be communicatively coupled to the at least one processor 404 and may have stored therein one or more sets of computer-executable instructions (e.g., the table management module 408 and other module(s) as appropriate).
  • the memory 402 may further have stored therein an account management module, an order management module, and/or a payment module, as described herebefore with respect to the method 300 according to various embodiments of the present invention, which are executable by the at least one processor 404 to perform the corresponding functions/operations as described.
  • FIG. 5 depicts a schematic block diagram of a mobile communication device 450 for facilitating table management at an establishment comprising a plurality of tables according to various embodiments of the present invention, which may be the same or similar as the mobile communication device 400 described with reference to FIG. 4, except that the mobile communication device 450 further comprises one or more additional modules stored in the memory 402 according to various embodiments of the present invention, such as an account management module 452, an order management module 454, and/or a payment module 456 as described hereinbefore according to various embodiments of the present invention.
  • additional modules stored in the memory 402 such as an account management module 452, an order management module 454, and/or a payment module 456 as described hereinbefore according to various embodiments of the present invention.
  • a computing system, a controller, a microcontroller or any other system providing a processing capability may be provided according to various embodiments in the present disclosure.
  • Such a system may be taken to include one or more processors and one or more computer-readable storage mediums.
  • the system 200/250 described hereinbefore may be a device or a system including a processor (or controller) 204 and a computer-readable storage medium (or memory) 202 which are for example used in various processing carried out therein as described herein.
  • a memory or computer-readable storage medium used in various embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).
  • DRAM Dynamic Random Access Memory
  • PROM Programmable Read Only Memory
  • EPROM Erasable PROM
  • EEPROM Electrical Erasable PROM
  • flash memory e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).
  • a “circuit” may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof.
  • a “circuit” may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g., a microprocessor (e.g., a Complex Instruction Set Computer (CISC) processor or a Reduced Instruction Set Computer (RISC) processor).
  • a “circuit” may also be a processor executing software, e.g., any kind of computer program, e.g., a computer program using a virtual machine code, e.g., Java.
  • a “module” may be a portion of a system according to various embodiments in the present invention and may encompass a “circuit” as above, or may be understood to be any kind of a logic-implementing entity therefrom.
  • Such a system, device or apparatus may be specially constructed for the required purposes, or may comprise a general purpose computer or other device selectively activated or reconfigured by a computer program stored in the computer.
  • the algorithms presented herein are not inherently related to any particular computer or other apparatus.
  • Various general-purpose machines may be used with computer programs in accordance with the teachings herein.
  • the construction of more specialized apparatus to perform the required method steps may be appropriate.
  • the present specification also at least implicitly discloses a computer program or software/functional module, in that it would be apparent to the person skilled in the art that the individual steps of the methods described herein may be put into effect by computer code.
  • the computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein.
  • the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the spirit or scope of the invention.
  • modules described herein may be software module(s) realized by computer program(s) or set(s) of instructions executable by a computer processor to perform the required functions, or may be hardware module(s) being functional hardware unit(s) designed to perform the required functions. It will also be appreciated that a combination of hardware and software modules may be implemented.
  • a computer program/module or method described herein may be performed in parallel rather than sequentially.
  • Such a computer program may be stored on any computer readable medium.
  • the computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer.
  • the computer program when loaded and executed on such a general-purpose computer effectively results in an apparatus that implements the steps of the methods described herein.
  • a first computer program product embodied in one or more computer-readable storage mediums (non-transitory computer- readable storage medium), comprising instructions (e.g., the table management module 206, the order management module 252, the payment module 254, and/or the kitchen module 256) executable by one or more computer processors to perform a method 100 for facilitating management of an establishment as described hereinbefore with reference to FIG. 1.
  • instructions e.g., the table management module 206, the order management module 252, the payment module 254, and/or the kitchen module 256
  • various computer programs or modules described herein may be stored in a computer program product receivable by a system (e.g., a computer system or an electronic device) therein, such as the system 200/250 as shown in FIGs. 2A and 2B, for execution by at least one processor 204 of the system 200/250 to perform the required or desired functions.
  • a second computer program product embodied in one or more computer-readable storage mediums (non-transitory computer-readable storage medium), comprising instructions (e.g., the table management module 408, the account management module 452, the order management module 454, and/or the payment module 456) executable by one or more computer processors 404 to perform a method 300 for facilitating table management at an establishment as described hereinbefore with reference to FIG. 3.
  • instructions e.g., the table management module 408, the account management module 452, the order management module 454, and/or the payment module 456
  • various computer programs or modules described herein may be stored in a computer program product receivable by a mobile communication device therein, such as the mobile communication device 400/450 as shown in FIGs. 4 and 5, for execution by at least one processor 404 of the mobile communication device 400/450 to perform the required or desired functions.
  • the software or functional modules described herein may also be implemented as hardware modules. More particularly, in the hardware sense, a module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using discrete electronic components, or it can form a portion of an entire electronic circuit such as an Application Specific Integrated Circuit (ASIC). Numerous other possibilities exist. Those skilled in the art will appreciate that the software or functional module(s) described herein can also be implemented as a combination of hardware and software modules.
  • ASIC Application Specific Integrated Circuit
  • the system 200/250 may be realized by any computer system (e.g., portable or desktop computer system), such as a computer system 600 as schematically shown in FIG. 6 as an example only and without limitation.
  • Various methods/steps or functional modules e.g., the table management module 206, the order management module 252, the payment module 254, and/or the kitchen module 256
  • the computer system 600 may comprise a computer module 602, input modules, such as a keyboard 604 and a mouse 606, and a plurality of output devices such as a display 608, and a printer 610.
  • the computer module 602 may be connected to a computer network 612 via a suitable transceiver device 614, to enable access to e.g. the Internet or other network systems such as Local Area Network (LAN) or Wide Area Network (WAN).
  • the computer module 602 in the example may include a processor 618 for executing various instructions, a Random Access Memory (RAM) 620 and a Read Only Memory (ROM) 622.
  • RAM Random Access Memory
  • ROM Read Only Memory
  • the computer module 602 may also include a number of Input/Output (I/O) interfaces, for example I/O interface 624 to the display 608, and I/O interface 626 to the keyboard 604.
  • I/O interface 624 to the display 608, and I/O interface 626 to the keyboard 604.
  • the components of the computer module 602 typically communicate via an interconnected bus 628 and in a manner known to the person skilled in the relevant art.
  • the mobile communication device 400/450 may be realized by any mobile communication device (e.g., smart phones, smart watches, tablet computers, and so on), such as a mobile communication device 700 as schematically shown in FIG. 7 as an example only and without limitation.
  • Various methods/steps or functional modules e.g., the table management module 408, the account management module 452, the order management module 454, and/or the payment module 456) may be implemented as software, such as one or more computer programs being executable within the mobile communication device 700, and instructing the mobile communication device 700 (in particular, one or more processors therein) to conduct the methods/functions of various embodiments described herein.
  • the communication device 700 may comprise a processor module 702, an input module such as a keypad 704 and an output module such as a display 706.
  • the display 706 may be a touch-sensitive display, and thus may also constitute an input module being in addition to, or instead of, the keypad 704. That is, it can be appreciated by a person skilled in the art that the keypad 704 may be omitted from the communication device as desired or as appropriate.
  • the processor module 702 is coupled to a first communication unit 708 for communication with a cellular network 710.
  • the first communication unit 708 can include but is not limited to a subscriber identity module (SIM) card loading bay.
  • SIM subscriber identity module
  • the cellular network 710 can, for example, be a 3G or a 4G network.
  • the processor module 702 is further coupled to a second communication unit 712 for connection to a local area network 714.
  • the connection can enable wired/wireless communication and/or access to, e.g., the Internet or other network systems such as Local Area Network (LAN), Wireless Personal Area Network (WPAN) or Wide Area Network (WAN).
  • the second communication unit 712 can include but is not limited to a wireless network card or an Ethernet network cable port.
  • the processor module 702 in the example includes a processor 716, a Random Access Memory (RAM) 718 and a Read Only Memory (ROM) 720.
  • RAM Random Access Memory
  • ROM Read Only Memory
  • the processor module 702 also includes a number of Input/Output (I/O) interfaces, for example I/O interface 722 to the display 706, and I/O interface 724 to the keypad 704.
  • I/O Input/Output
  • the components of the processor module 702 typically communicate via an interconnected bus 726 and in a manner known to the person skilled in the relevant art.
  • Various software or application programs may be pre- installed in a memory of the mobile communication device 700 or may be transferred to a memory of the mobile communication device 700 by reading a memory card having stored therein the application programs or by downloading wirelessly from an application server (e.g., an online app store).
  • FIG. 8 depicts a schematic drawing illustrating an overview of a system 800 comprising a server 802 and one or more mobile communication devices 804, 806 according to various embodiments of the present invention.
  • the server 802 may be implemented by the system 200/250 for facilitating management of an establishment as described hereinbefore with reference to FIGs. 2A and 2B
  • the mobile communication device 804/806 may be implemented by the mobile communication device 400/450 for facilitating table management at an establishment as described hereinbefore with reference to FIGs. 4 and 5.
  • the mobile communication device 804/806 and the server 802 may communicate with each other via any wireless communication protocol known in the art, such as but not limited to, cellular network (e.g., 3G, 4G, or LTE), Wi-Fi network, Bluetooth, and so on, and thus need not be described in detail herein.
  • cellular network e.g., 3G, 4G, or LTE
  • Wi-Fi network e.g., Wi-Fi Protectet Access (WPA), Wi-Fi network, Bluetooth, and so on, and thus need not be described in detail herein.
  • Various example embodiments provide a table management system (e.g., corresponding to the "system" 200/250 described hereinbefore according to various embodiments) for use in a restaurant that enables customers (users) to manage themselves the process of acquiring and occupying a table, as well as accepting or declining new customers from joining the same table.
  • a table management system e.g., corresponding to the "system" 200/250 described hereinbefore according to various embodiments
  • various conventional restaurant management system may require a restaurant staff to update the status of the tables in a restaurant on an electronic display device.
  • various example embodiments of the present invention advantageously seeks to automate the process of table management at a restaurant, such as automatically (e.g., without requiring a restaurant staff) maintaining an up-to-date status of the tables by enabling customers themselves to manage table allocations at the restaurant, instead of relying on a restaurant staff.
  • the table management system assigns one or more customers that joined a table to be corresponding one or more controllers of the table. For example, the first customer that successfully joined a table (e.g., an unoccupied table) will be assigned as a controller of the table. The controller will then be provided with the ability to accept or decline subsequent new customers from joining the table. In various example embodiments, all customers that have successfully joined a table are each assigned as a controller (co-controller) of the table. For example, this avoids various problems associated with having just one of multiple customers at the table as the controller, for example, the single controller may be busy or may be unable to use his mobile device when required (e.g., when a new customer is seeking to join the table).
  • the first customer that successfully joined a table e.g., an unoccupied table
  • the controller will then be provided with the ability to accept or decline subsequent new customers from joining the table.
  • all customers that have successfully joined a table are each assigned as a controller (co-controller) of the table. For example, this avoid
  • a customer may initially acquire a table using a guest account, and may then decide to sign up or log in to a user account at a later stage.
  • various example embodiments of the present invention perform a switching/swapping operation to switch/swap the guest account with the user account (e.g., corresponding to the "individualized customer account” described hereinbefore according to various embodiments), as well as transferring all items ordered under the guest account into the user account.
  • this avoids a problem whereby the customer is considered a new customer after having logged in and will then have to re- acquire the table, but the table is still occupied by the guest account (belonging to the customer himself before the customer logged in) which is still the controller at the table.
  • the system is configured to free the table (i.e., change to an available state) automatically after it is occupied by one or more customers and no orders have been placed by any of the customers after a predetermined time period or threshold.
  • this advantageously addresses a problem whereby customers might join or occupy a table but then decide to leave the restaurant without ordering.
  • the restaurant may set an appropriate time period as the predetermined time period in the table management module at the system.
  • Various example embodiments of the present invention provide a technical solution to table management in restaurants without the need for a restaurant staff to intervene.
  • a customer may choose a table in a restaurant to join via his or her mobile device. If the table is detected to be empty by the system (e.g., a server) associated with the restaurant based on a table occupancy database, the customer may be accepted by the system to be allowed to join the table, and furthermore, assigned by the system to be a controller of the table. As a controller, for example, the customer is provided with the ability to add more customers (e.g., friends) to the table. In this regard, all customers that have successfully joined the table are each also a controller of the table.
  • the system e.g., a server
  • the customer may be accepted by the system to be allowed to join the table, and furthermore, assigned by the system to be a controller of the table.
  • the customer is provided with the ability to add more customers (e.g., friends) to the table.
  • all customers that have successfully joined the table are each also a controller of the table.
  • the system when a new customer requests to join the table, the system may be configured such that all customers at the table will receive the request (e.g., corresponding to the "customer authorization request" described hereinbefore according to various embodiments) and each customer has an opportunity to choose whether to accept or to decline the request.
  • the system may be configured to determine whether the new customer is allowed to join the first table based on the earliest response (e.g., corresponding to the "customer authorization response" described hereinbefore according to various embodiments) received from amongst the customers at the table.
  • the system is configured such that each customer at a table is able view all other orders (e.g., shopping carts) of all other customers at the table on their respective mobile device. Furthermore, the system may be configured to enable the customer to duplicate ordered items from one or more other orders made by other customers at the table and add such items to their order. In this regard, the system may be configured such that any changes (e.g., item add, item update, item delete) in an order made by a customer will be immediately reflected to all other customers at the table (e.g., by maintaining, at a mobile device of each customer, up-to- date orders of all other customers at the table).
  • any changes e.g., item add, item update, item delete
  • FIG. 9 depicts an exemplary schematic overview of a restaurant 902 according to various example embodiments of the present invention.
  • the restaurant 902 comprises a plurality of tables 904 and a number of systems and/or devices, including a POS (Point of Sale) system 906, a kitchen display device (or kitchen screen) 908, a waiter display device (or waiter screen) 910, and a printer 912.
  • POS Point of Sale
  • FIG. 9 also illustrates a state of the restaurant whereby two customers have joined Table 1 and three customers have joined Table 2, whereas Table 3 and Table 4 are unoccupied. Each customer has an associated mobile device (not shown in FIG. 9).
  • the state of Table 1 may be "busy”, the state of Table 2 may be "occupied”, and the state of Table 3 and Table 4 may be “free”.
  • the server 920 e.g., corresponding to the "system” 200/250 as described hereinbefore according to various embodiments
  • the server 920 associated with the restaurant 902 is able to communicate with each mobile device and with each of the above-mentioned systems and/or devices associated with the restaurant 902, such as via any wired or wireless communication protocol known in the art, such as but not limited to, cellular network, Wi-Fi network, Bluetooth, and so on, and thus need not be described in detail herein.
  • FIG. 10 depicts a flow diagram 1000 illustrating various aspects of a method for facilitating management of a restaurant relating to table management according to an example embodiment of the present invention.
  • the server 920 is configured to determine whether a new customer (i.e., the mobile device associated with the new customer) is sufficiently close to the restaurant, e.g., within a predetermined distance from the restaurant.
  • the mobile device may include a positioning module capable of detecting/determining its location based on GPS and/or Wi-Fi signals, and as the location of the restaurant is known, the distance between the mobile device and the restaurant may thus be determined.
  • the server 920 may use the detected location (e.g., longitude and latitude coordinates) of the mobile device to determine whether the mobile device (and thus the associated customer) is sufficiently near to the restaurant. For example, if the mobile device is determined to be within the predetermined distance from the restaurant, the server may be configured to process the table request from the customer for a table at the restaurant. Otherwise, if the mobile device is determined to be further than the predetermined distance from the restaurant, the system may be configured to disregard the table request (i.e., not process the table request) and send a notification (e.g., a distance error message) informing the customer that he/she is sufficiently close to the restaurant in order to make a table request.
  • a notification e.g., a distance error message
  • the server 920 is configured to determine whether the new customer is allowed to join the table requested. For example, if the state of the table is available, the server 920 may determine to allow the new customer to join the table, and assign the new customer as a controller of the table. On the other hand, if the state of the table is occupied or busy, the server 920 may be configured to send a request (e.g., corresponding to the "customer authorization request" as described hereinbefore according to various embodiments), such as a push notification, to each existing customer at the table. Therefore, each existing customer at the table will be provided with an opportunity to accept or decline the table request from the new customer.
  • a request e.g., corresponding to the "customer authorization request" as described hereinbefore according to various embodiments
  • the server 920 is configured to determine whether to accept or decline the table request from the new customer based on a response (e.g., corresponding to the "customer authorization response" as described hereinbefore according to various embodiments) from the existing customers.
  • a response e.g., corresponding to the "customer authorization response" as described hereinbefore according to various embodiments
  • the decision whether to accept or decline the table request may be based on the first (i.e., the earliest) response received from any of the existing customers at the table.
  • the server 920 may then notify each existing customer of the outcome on their respective mobile device.
  • FIGs. 11A to 11G show exemplary screenshots (user interfaces or GUIs) on the three mobile devices associated with three different customers/users, respectively, for an exemplary scenario while performing the method of facilitating table management at a restaurant according to an example embodiment of the present invention, such as corresponding to the method 300 as described hereinbefore according to various embodiments of the present invention.
  • various modules configured for performing one or more steps as described in relation to the method 300 or the mobile device 400/450 may be compiled together as one program/software application (or simply referred to as an "app"), which may be stored in the mobile device and executable by at least one processor of the mobile device to perform the required functions/operations.
  • 1 1A to 11G show exemplary screenshots of three mobile devices, each having the above-mentioned app stored therein and being executed by at least one processor therein to result in the respective user interface (GUI) being displayed on the respective screen and captured as shown.
  • GUI user interface
  • FIG. 1 1A depicts three screenshots on the mobile devices associated with three customers, respectively, at a time instance (e.g., a first time instance).
  • a time instance e.g., a first time instance.
  • the first customer Customer 1
  • the second customer Customer 2
  • the third customer Customer 3
  • Quanfu Dell
  • Logit Logit
  • Customer 1 has not yet initiated the app and thus the corresponding screenshot is shown blank, Customer 2 has just arrived at the restaurant and has initiated the app, and Customer 3 is already at a stage whereby he is at the restaurant and has added an item 1 110 to his order (e.g., an ordering list, which may also be referred to as a "shopping cart” or an "order cart”).
  • Customer 2 has not yet logged in to a user account (and thus is under a guest account), but Customer 3 has already logged in to his user account (e.g., corresponding to the "individualized customer account” as described hereinbefore according to various embodiments), for example, as indicated by the presence of his name "LOGIT" 1 112 on the user interface.
  • FIG. 11B depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a second time instance after the first time instance).
  • a subsequent time instance e.g., a second time instance after the first time instance.
  • Customer 1 has still not yet initiated the app and thus the corresponding screenshot is shown blank
  • Customer 2 has now added an item 1120 to his order, while still being under the guest account
  • Customer 3 has now decided to select and join Table 5.
  • the mobile device in response to a table selection input 1122 by Customer 3 on the GUI presented on his mobile device, the mobile device is configured to generate and send a table request to the server associated with the restaurant for authorization.
  • FIG. l lC depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a third time instance after the second time instance).
  • a subsequent time instance e.g., a third time instance after the second time instance.
  • Customer 1 has just initiated the app (e.g., he just arrived at the restaurant or is nearby)
  • Customer 2 has now decided to select and join Table 5, at which Customer 3 is already occupying
  • Customer 3 has successfully joined Table 5 since he has been determined to be allowed by the server to join the table as the table was unoccupied at the time.
  • Customer 3 has also now been assigned by the server as a controller of Table 5.
  • the mobile device is configured to generate and send a table request to the server associated with the restaurant for authorization.
  • FIG. 11D depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a fourth time instance after the third time instance).
  • a subsequent time instance e.g., a fourth time instance after the third time instance.
  • Customer 1 has logged in to his user account and has added two items 1142 to his order under his user account.
  • FIG. 11D depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a fourth time instance after the third time instance).
  • Customer 1 has logged in to his user account and has added two items 1142 to his order under his user account.
  • FIG. 11D depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a fourth time instance after the third time instance).
  • Customer 1 has logged in to his user account and has added two items 1142 to his order under his user account.
  • FIG. 11D depicts three screenshots on the same three mobile devices, respectively, at
  • the table request from Customer 2 (still under his guest account) for Table 5 has been sent to the server since Customer 2 is determined to be sufficiently close to the restaurant, and Customer 3 (as a controller of Table 5) has been prompted, e.g., via a push notification 1144 on his mobile device, to make an authorization response (e.g., corresponding to the "customer authorization response" as described hereinbefore according to various embodiments) on whether to accept or decline the table request from Customer 2.
  • the server may be configured to send a customer authorization request to Customer 3 in response to the table request from Customer 2, and then receive the customer authorization response from Customer 3 based on which the server will then determine whether to accept Customer 2 to join Table 5.
  • FIG. HE depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a fifth time instance after the fourth time instance).
  • a subsequent time instance e.g., a fifth time instance after the fourth time instance.
  • Customer 1 has now decided to select and join Table 5.
  • Customer 2 has successfully joined Table 5 since he has been determined to be allowed by the server to join the table.
  • existing Customer 3 has accepted the table request from Customer 2.
  • the server has also assigned Customer 2 as a controller (co-controller) of the table.
  • both Customers 2 and 3 are able to see each other's current orders, such as via a respective selectable tab 1152, 1154 presented on the respective GUI.
  • Customer 2 is still under the guest account as Customer 2 has not yet logged in.
  • FIG. 1 IF depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a sixth time instance after the fifth time instance).
  • a subsequent time instance e.g., a sixth time instance after the fifth time instance.
  • the table request from Customer 1 for Table 5 has been sent to the server and is being processed by the server since Customer 1 has been determined to be sufficiently close to the restaurant.
  • the server is configured to send a customer authorization request to each of Customers 2 and 3 to seek a customer authorization response.
  • both Customers 2 and 3 each will receive a customer authorization request, e.g., via a push notification 1162, 1164 on the respective mobile device, to make a customer authorization response on whether to accept or decline the table request from Customer 1. Accordingly, each existing customer at the table will have an opportunity to accept or decline the table request from a new customer.
  • FIG. 11G depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a seventh time instance after the sixth time instance).
  • a subsequent time instance e.g., a seventh time instance after the sixth time instance.
  • Customer 1 has successfully joined Table 5 since he has been determined to be allowed by the server to join the table.
  • the server is configured to make the determination based on the earliest or fastest customer authorization response from amongst the existing customers at the table, and in this example, Customer 3 was the fastest to provide the customer authorization response.
  • FIG. 12 depicts a flow diagram 1200 illustrating an aspect of a method for facilitating management of a restaurant relating to an order update according to an example embodiment of the present invention.
  • information on the updated order will be sent from the mobile device to the server, which will then in turn provide the information on the updated order to each other customer at the same table.
  • an order e.g., adding item(s), removing item(s), editing item(s) (e.g., quantity and/or size)
  • server in response to a customer at a table updating an order (e.g., adding item(s), removing item(s), editing item(s) (e.g., quantity and/or size)) on his/her mobile device, information on the updated order will be sent from the mobile device to the server, which will then in turn provide the information on the updated order to each other customer at the same table.
  • the server may be configured to determine whether there are other existing customer(s) at the table in response to receiving information on an updated order, and if so, the server is configured to send such information to each other existing customer at the table so that each customer at the table will have access to and is able to view the current (i.e., up-to- date) order made by each other existing customer at the same table. For example, when a customer changes/modifies their order on their mobile device, the changes will also be reflected to all existing customers at the same table, thus, each existing customer at the table will be able to see in real-time the changes, if any, the other existing customers have made.
  • Each customer at table may also duplicate one or more items ordered by other existing customers at the same table and add such item(s) to their order.
  • FIGs. 13A and 13B show exemplary screenshots (GUIs) on the three mobile devices associated with the three different customers, respectively, for an exemplary scenario relating to the above- mentioned aspect described with reference to FIG. 12.
  • GUIs exemplary screenshots
  • FIGs. 13 A and 13B may follow on from the exemplary scenario described above with reference to FIGs. 11 A to 11G.
  • FIG. 13 A depicts three screenshots on the mobile devices associated with the three customers, respectively, at a time instance (e.g., an eighth time instance after the seventh time instance).
  • a time instance e.g., an eighth time instance after the seventh time instance.
  • Customer 1 is modifying an item in his order.
  • the number of "Ice Lemon Tea” is being modified from one to three.
  • Customers 2 and 3 are able to see Customer l's current order, which is still "1 x Ice Lemon Tea" since Customer 1 has not yet submitted his update of the item.
  • FIG. 13 A depicts three screenshots on the mobile devices associated with the three customers, respectively, at a time instance (e.g., an eighth time instance after the seventh time instance).
  • Customer 1 is modifying an item in his order.
  • the number of "Ice Lemon Tea” is being modified from one to three.
  • Customers 2 and 3 are able to see Customer l's current order, which is still "1 x Ice Lemon Tea" since Customer 1 has not yet submitted his update
  • 13A also illustrates a "duplicate" button 1302, 1304 allowing either Customer 2 or 3 to duplicate/copy one or more items in Customer's order, as well as various options/selections in relation to the item (e.g., the quantity and/or size), and add to their own order by triggering the virtual "duplicate" button 1302, 1304.
  • a "duplicate" button 1302, 1304 allowing either Customer 2 or 3 to duplicate/copy one or more items in Customer's order, as well as various options/selections in relation to the item (e.g., the quantity and/or size), and add to their own order by triggering the virtual "duplicate" button 1302, 1304.
  • FIG. 13B depicts three screenshots on the same three mobile devices, respectively, at a subsequent time instance (e.g., a ninth time instance after the eighth time instance).
  • a subsequent time instance e.g., a ninth time instance after the eighth time instance.
  • Customer 1 has submitted his update of the item to "3 x Ice Lemon Tea", as well as selecting to upsize the drink.
  • the changes by Customer 1 to the item in his order are also reflected on each of the mobile devices of existing Customers 2 and 3 at the same table in real-time.
  • FIG. 14 depicts a flow diagram 1400 illustrating an aspect of a method for facilitating management of a restaurant relating to a log in process according to an example embodiment of the present invention.
  • the server may be configured to treat each existing customer at a table as an individual customer. For example, even if a customer did not or has not logged in, the server may still create and assign an account (e.g., a guest account) to the customer.
  • the guest account may have the same abilities and functionalities as an individualized customer account since the guest account is still associated to an individual customer, but just that the guest account does not have the customer's particulars, such as name, phone number, email address, photo, and so on.
  • the server determines (e.g., by the server) whether the customer has already joined a table. If the customer has not yet joined any table, the app may proceed to a main page (e.g., a home page or a menu page). On the other hand, if it is determined that the customer has already joined a table, the guest account linked to the table is switched to the individualized customer account logged into by the customer. Furthermore, at 1404, it is determined (e.g., by the server) whether the customer has any existing items added to his order. If so, the order made under the guest account is transferred or copied to be an order under the individualized customer account logged into by the customer. Each other existing customer at the table may also be notified of the login by the customer.
  • a main page e.g., a home page or a menu page
  • FIGs. 15A and 15B show exemplary screenshots (GUIs) on the three mobile devices associated with the three different customers, respectively, for an exemplary scenario relating to the above- mentioned aspect described with reference to FIG. 14.
  • GUIs exemplary screenshots
  • FIGs. 15 A and 15B may follow on from the exemplary scenario described above with reference to FIGs. 13 A and 13B.
  • FIG. 15 A depicts three screenshots on the mobile devices associated with the three customers, respectively, at a time instance (e.g., a 10 th time instance after the ninth time instance).
  • a time instance e.g., a 10 th time instance after the ninth time instance.
  • Customer 1 may be viewing the current order made by Customer 3
  • Customer 3 may be viewing the current order made by Customer 2 (under the guest account).
  • Customer 2 may realize that he has forgotten to log in, and thus decides to log in now by proceeding to the login page and entering his login details (e.g., username or email address and password).
  • FIG. 15B depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., an 11 th time instance after the 10 th time instance).
  • a subsequent time instance e.g., an 11 th time instance after the 10 th time instance.
  • Customer 2 has successfully logged into his individualized customer account, and as he has already joined Table 5, his previous guest account linked to the table is switched with the individualized customer account which he logged into. For example, this may be implemented by removing or delinking the guest account to the table and linking the individualized customer account to the table.
  • such existing items are transferred or swapped to be an order under the individualized customer account 1502.
  • the server may also be configured to remember where Customer 2 last visited, and immediately redirect Customer 2 to the same page to advantageously provide a seamless login process.
  • the server may also notify each existing customer at the table of the login by Customer 2, such as via a speech bubble 1504, 1506.
  • FIG. 16 depicts a flow diagram 1600 illustrating an aspect of a method for facilitating management of a restaurant relating to a log out process according to an example embodiment of the present invention.
  • the server may be configured to determine whether the customer is currently linked to (i.e., has joined) a table. In this regard, if the customer has already joined a table, the server may be configured to remove the customer from the table. Otherwise, the account in which the customer is linked to may be switched from the individualized customer account to a guest account.
  • the server may determine whether there is any other customer that has joined the table. If so, a notification (e.g., via a push notification, such as a speech bubble) may be sent to each existing other customer at the table to inform them that the customer has left the table, and then the account in which the customer is linked to may be switched from the individualized customer account to a guest account. Otherwise (that is, if no other customer exists at the table), the server may simply proceed to switch the account in which the customer is linked to from the individualized customer account to a guest account. Any order by the customer that has left the table will also no longer be viewable or accessible by the existing customers at the table.
  • a notification e.g., via a push notification, such as a speech bubble
  • the mobile device may be configured to redirect to another page (e.g., a home page or a menu page) and no longer able to view the order anymore.
  • another page e.g., a home page or a menu page
  • FIG. 17 shows exemplary screenshots (GUIs) on the three mobile devices associated with three different customers, respectively, for an exemplary scenario relating to the above-mentioned aspect described with reference to FIG. 16.
  • GUIs exemplary screenshots
  • FIG. 17 may follow on from the exemplary scenario described above with reference to FIGs. 15A and 15B.
  • FIG. 17 depicts three screenshots on the mobile devices associated with the three customers, respectively, at a time instance (e.g., a 12 th time instance after the 11 th time instance).
  • a time instance e.g., a 12 th time instance after the 11 th time instance.
  • the server may be configured to send a notification (e.g., via a push notification, such as a speech bubble) 1702, 1704 to Customers 1 and 3 to inform them that Customer 2 has left the table. It can also be observed from FIG.
  • FIG. 18 depicts a flow diagram 1800 illustrating an aspect of a method for facilitating management of a restaurant relating to a table status checking process according to an example embodiment of the present invention.
  • the server may be configured to perform periodic checks on the status of the tables according to various example embodiments.
  • the server may be configured to determine whether the table is occupied. If the table is not occupied, then the process may end until the next checking interval. On the other hand, if the table is detected as being occupied, at 1804, the server may be configured to determine whether there is any existing order made at the table. If so, the process may end until the next checking interval since an existing order may indicate that the table is being properly utilized by existing customers.
  • the server may be configured to determine how long the customer(s) has joined the table. If the customer(s) has joined the table for longer than a predetermined time period, the server may then be configured to release the table by removing all existing customers from the table (e.g., by delinking their accounts from the table) and setting the status of the table to an available status. Otherwise, the process may end until the next checking interval.
  • the server may also be configured to check the status of the tables in the restaurant periodically to determine whether there are any tables that should be set free for being at an occupied status inaccurately, such as customers having joined but then decided to leave without making any orders.
  • the status of a table may include one or more of an available or open status/state indicating that the table is unoccupied, an occupied status/state indicating that the table has been joined by one or more customers, a busy status/state indicating that the customer(s) that has joined the table has submitted their order(s) such as waiting or having their meals, a paid status/state indicating that all order(s) by customer(s) that has joined the table has been paid, and a cleared status/state indicating that all customer(s) that joined the table has left the table and/or left the establishment.
  • the server may be configured to check periodically for tables that are held at an occupied status. For example, there may be cases where customers have joined the table but did not place any orders for a long time because they may have changed their mind and decided to leave the restaurant. If the table is occupied for a time longer than a predetermined threshold, the server may be configured to free the table by removing all customers detected to have joined the table and setting the table's status to available again.
  • the predetermined threshold may be set to any value as appropriate for various purposes, such as by a restaurant staff or management, such as but not limited to, a range of 3 to 15 minutes, 4 to 10 minutes, or 5 to 7 minutes.
  • various example embodiments advantageously enable customers to act as controllers and manage their own tables at an establishment such as a restaurant.
  • Various embodiments of the present application may be applied in the food and beverage industry, but are not limited thereto. As an example, various embodiments may also be applied in the same or similar manner to various services/outlets requiring room reservations, such as karaoke outlets where customers may then self-manage their rooms (e.g., corresponding to the tables described hereinbefore according to various embodiments) as the controllers.
  • various services/outlets requiring room reservations such as karaoke outlets where customers may then self-manage their rooms (e.g., corresponding to the tables described hereinbefore according to various embodiments) as the controllers.
  • each order (e.g., including one or more items added thereto) by a customer is treated as an individual order (e.g., individual shopping or order cart).
  • individual order e.g., individual shopping or order cart
  • various example embodiments of the present invention enable users to perform a group payment of multiple shopping or order carts ordered at a table.
  • a conventional ordering and payment application used at a restaurant may allow a customer to pay for their own individual order. Therefore, in a group of customers (e.g., friends) where one customer offers to pay for the entire bill (i.e., pay for all the orders by the group of customers), the conventional way to achieve this is to consolidate everyone's order under that paying customer. This usually requires each customer to take turns to informing that paying customer the item(s) that he/she wants in order for that paying customer to add such item(s) under his/her order. As a result, not only is this time consuming, there is a possibility that the desired item(s) by a customer may be understood incorrectly by the paying customer, thus resulting in an order with incorrect items.
  • Various embodiments of the present invention advantageously address, or at least mitigate, the above-mentioned problems associated with the above-mentioned conventional technique.
  • various example embodiments of the present invention advantageously enable each customer to customize and place their own order, and any one of the customers at the same table has the ability to pay for any one or more of the orders made by others on the same table by selecting the order(s) (e.g., customers' individual shopping or order carts) that he/she desires to pay.
  • various embodiments advantageously enable each customer to have their own separate order and manage their own order independently, while providing the capability for a customer to pay for one or more of other customers' orders (e.g., friends' orders) together with their own order.
  • a method comprises a step of receiving, by a payment module at the server, a first payment request from the first mobile communication device associated with the first customer to pay for at least the second order or a second payment request from the second mobile communication device associated with the second customer to pay for at least the first order, and a step of sending, by the payment module, a first payment request notification to the second mobile communication device for setting the second order on the second mobile communication device to be in a lock state to prevent the second order from being modified by the second customer in response to the first payment request or a second payment request notification to the first mobile communication device for setting the first order on the first mobile communication device to be in a lock state to prevent the first order from being modified by the first customer in response to the second payment request.
  • the payment module may receive a payment request from a mobile communication device associated with a customer to pay for the customer's order as well as one or more other customers' orders made by other customers at the table.
  • the payment module may be configured to send a payment request notification to each mobile communication device of the one or more other customers whose orders have been requested to be paid by the paying customer.
  • a payment request notification may be configured for setting the order on the respective mobile communication device to be in a lock state to prevent the order on the respective mobile communication device from being modified by the respective customer.
  • the ordering function on each respective mobile communication device may be disabled.
  • this advantageously avoids any mismatch or discrepancy between the order which a customer is in the process of paying for and the actual order, and also avoids an undesirable scenario whereby the final amount to be pay continues to change as other customers change their orders which are in the process of being paid for.
  • the above-mentioned order locking technique may in turn result in an issue if the paying customer did not manage to pay (e.g., various reasons such as left the restaurant, mobile device battery went flat, credit card errors, change of mind, and so on) and all the orders which are supposed to be paid for may thus be undesirably left in the lock state.
  • Various embodiments of the present invention address this problem by releasing each order that has been locked after a predetermined time period.
  • the predetermined time period may be set as appropriate or as desired, such as by a restaurant staff or administrator.
  • the predetermined time period may ranging from 30 seconds to 5 minutes, 1 to 4 minutes, or 2 to 3 minutes.
  • various embodiments of the present invention advantageously facilitate group payment in an establishment, such as a restaurant, as well as providing order management.
  • FIG. 19 depicts a flow diagram 1900 illustrating an aspect of a method for facilitating management of a restaurant relating to an order update process according to an example embodiment of the present invention.
  • the server may be configured to determine whether the order is in a lock state due to another customer being in the process of paying for the order. If so, the server may be configured to inform the customer that his order is in a lock state as the order is in the process of being paying by another customer. Otherwise, the server may be configured to allow the customer to modify his/her order.
  • the server may be configured to detect whether there exist other customers at the table (e.g., based on the table occupancy database). If so, the server may be configured to send information on the updated order to each other customer at the same table.
  • the types of modifications or updates may include adding item(s) to an order, removing item(s), and editing item(s) (e.g., quantity and/or size).
  • the above order update process advantageously address the above-mentioned problem whereby one or more orders in the process of being paid for are modified, resulting in a mismatch or discrepancy between the order which a customer is in the process of paying for and the actual order.
  • FIGs. 20A and 20B show exemplary screenshots (GUIs) on three mobile devices associated with the three different customers, respectively, for an exemplary scenario relating to the above- mentioned aspect described with reference to FIG. 19.
  • GUIs exemplary screenshots
  • FIG. 20A depicts three screenshots on the mobile devices associated with the three customers, respectively, at a time instance (e.g., a first time instance).
  • a time instance e.g., a first time instance.
  • Customer 1 may be modifying an item that he ordered from "1 x Ice Lemon Tea” to "3 x Ice Lemon Tea”
  • Customer 2 may be at an order payment selection whereby he has selected to pay for all three orders, that is, for the orders made by Customers 1 and 3, as well as for the order he made
  • Customer 3 may also be at an order payment selection page and has selected to pay for only the orders made by himself and Customer 1.
  • the order payment selection page may show a number of checkboxes, one for each existing customer at the table, the checkbox being selectable to pay for the order made by the corresponding customer. Furthermore, based on the checkboxes selected, a receipt summarizing the items under the corresponding orders made by the customers may be displayed for verification by the paying customer.
  • FIG. 20B depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., a second time instance after the first time instance).
  • a subsequent time instance e.g., a second time instance after the first time instance.
  • Customer 1 has modified the item to "3 x Ice Lemon Tea".
  • the server is configured to send the information on the updated order by Customer 1 to Customers 2 and 3.
  • the price summary 2022, 2024 for Customer 1 shown on the GUIs on the mobile devices of both Customers 2 and 3 are updated.
  • the total price 2026, 2028 of the orders selected to be paid is also updated to take into account the modified item by Customer 1.
  • FIGs. 21A and 21B shows exemplary screenshots (GUI) on two mobile devices associated with two different customers (Customers 2 and 3), respectively, for an exemplary scenario relating to the above-mentioned aspect described with reference to FIG. 19.
  • GUI graphical user interface
  • FIGs. 21A and 21B may follow on from the exemplary scenario described above with reference to FIGs. 20A and 20B.
  • FIG. 21 A depicts two screenshots on the mobile devices associated with the two customers, respectively, at a subsequent time instance (e.g., a third time instance after the second time instance).
  • a subsequent time instance e.g., a third time instance after the second time instance.
  • Customer 2 have proceeded to a payment page to pay for the orders selected on the previous order payment selection page (in this case, all of the three orders).
  • a timer 2104 may be initiated to provide a time within which the payment has to be completed.
  • Customer 3 decided to modify his order to, for example, add an item.
  • FIG. 2 IB depicts two screenshots on the mobile devices associated with the two customers, respectively, at a subsequent time instance (e.g., a fourth time instance after the third time instance).
  • a subsequent time instance e.g., a fourth time instance after the third time instance.
  • Customer 2 is still at the payment page, although the timer 2014 is now down to 23 seconds left.
  • the server is configured to set the order of the Customer 3 to be in a locked state while Customer 2 is in the process of paying the order made by Customer 3, the attempt by Customer 3 to update the item will be rejected by the server.
  • the problems described above such as a mismatch or discrepancy between the order which a customer is in the process of paying for and the actual order, can be avoided.
  • Customer 3 may also be notified (e.g., via a pop- up notification 2114) that his order is in a locked state, as well as the duration of the waiting time (corresponding to the timer at the payment page).
  • FIG. 22 depicts a flow diagram 2200 illustrating an aspect of a method for facilitating management of a restaurant relating to the processing of a confirmed order (e.g., paid or submitted) according to an example embodiment of the present invention.
  • the server may be configured to determine the type of the order, such as but not limited to, a reservation type, a pre-order type (e.g., pre-ordering one or more items before arriving at the restaurant or while waiting at the restaurant for a table to be available), a dine-in type, or a take-away type (i.e., not for dining at the restaurant and item(s) ordered is to be taken away).
  • a reservation type e.g., a pre-order type (e.g., pre-ordering one or more items before arriving at the restaurant or while waiting at the restaurant for a table to be available)
  • a dine-in type e.g., a dine-in type
  • a take-away type i.e., not for dining at the restaurant and item(s) ordered is to be taken away.
  • the server may then be configured to send information on the order to a printer for printing out a receipt with the order details (e.g., customer name, table number, and description of item(s)) and/or send information on the order to a kitchen/waiter display device for displaying the order details to, e.g., a kitchen staff for preparing the items in the order.
  • the server may also be configured to notify the user confirming that the order has been submitted and/or paid.
  • the server may be configured to determine whether the order includes one or more orders made by other customers at the table (e.g., the customer may decide to also pay for one or more orders made by other customers at the table). If so, the server may be configured to inform the other customer of each of such orders that their order has been submitted and paid for. For example, a payment thank you page may then be displayed on the GUI on the respective mobile device while the order is being prepared. On the other hand, if the order does not include any order made by other customer(s) at the table (e.g., the customer has decided to only pay for his own order), at 2210, the server may be configured to determine whether there are other orders made at the table that has not yet been paid.
  • the server may be configured to determine whether there are other orders made at the table that has not yet been paid.
  • the server may be configured to inform the other customer of each of such orders that their order has been submitted (but not yet paid) by the customer that submitted the order.
  • the server may then be configured to show an order summary page for the other customer of each of such orders, including the total cost of that customer's order, along with a payment option.
  • FIGs. 23A to 23F show exemplary screenshots (GUIs) on three mobile devices associated with the three different customers, respectively, for exemplary scenarios relating to the above-mentioned aspect described with reference to FIG. 22.
  • FIG. 23 A depicts three screenshots on the mobile devices associated with the three customers, respectively, at a time instance (e.g., a first time instance).
  • Customer 1 may be at an order summary page (e.g., viewing his order cart)
  • Customer 2 may be at a payment page in the process of paying for the three orders
  • Customer 3 may be at a payment option summary page with options to pay for one or more orders.
  • FIG. 23B depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., a second time instance after the first time instance). As illustrated, at the second time instance, Customer 1 may still be at the order summary page, Customer 2 may proceed to pay for the three orders, and Customer 3 may still be at the payment option summary page.
  • a subsequent time instance e.g., a second time instance after the first time instance.
  • FIG. 23C depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., a third time instance after the second time instance) once Customer 2 has successfully paid for the three orders.
  • the server may then be configured to direct the mobile device of each of Customers 1 , 2 and 3 to a payment thank you page.
  • the mobile device of Customer 1 is directed to the payment thank you page from the order summary page
  • the mobile device of Customer 2 is directed to the payment thank you page from the payment option summary page shown in FIG. 23B.
  • FIG. 23D depicts three screenshots on the mobile devices associated with the three customers, respectively, at a time instance (e.g., a first time instance).
  • a time instance e.g., a first time instance
  • Customer 1 may be at a payment option summary page with options to pay for one or more orders
  • Customer 2 may be at a payment page in the process of paying for the three orders
  • Customer 3 may be at an order summary page (e.g., viewing his order cart).
  • FIG. 23E depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., a second time instance after the first time instance).
  • a subsequent time instance e.g., a second time instance after the first time instance
  • Customer 1 may still be at the payment option summary page
  • Customer 2 may proceed to pay for the two orders, such as, by performing a swiping action on the GUI
  • Customer 3 may still be at the order summary page.
  • FIG. 23F depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., a third time instance after the second time instance) once Customer 2 has successfully paid for the two orders.
  • the server may then be configured to direct the mobile device of each of Customers 2 and 3 to a payment thank you page, while the mobile device of Customer 1 is directed to the payment option summary page. It can be observed that the option to pay for Customers 2 and 3 is no longer available (since their orders have been paid) and the total costs of the order has also been updated accordingly.
  • the server may also be configured to inform Customer 1 that Customer 3 has submitted the orders. Customer 1 may then proceed to pay the outstanding bill.
  • various embodiments of the invention advantageously enable users to perform group payment, while at the same time, still being able to manage their own order independently.
  • the server when the order is submitted or paid successfully, the server may be configured to send information on the order (e.g., customer name, table number, description of item(s), and any special request(s)) to the restaurant POS system, a kitchen/waiter screen, and/or a printer for printing out a receipt for the order.
  • FIG. 24A shows an example kitchen screen being displayed for the three orders made by the three customers.
  • the information displayed may include the customers' names, their table number, the items they have ordered, along with any special requests.
  • each item of an order may be individually itemized so that the status of each order can be updated and accounted for individually.
  • FIG. 24B shows an example waiter screen based on the same three orders.
  • a kitchen staff may indicate that an order item is ready (e.g., an order ready input by the kitchen staff via the touch sensitive display screen, which may then be sent to the server) and this may be reflected in the waiter screen (based on an order ready notification from the server) as shown FIG. 24B so that, for example, the waiter staff may take the necessary action, such as to deliver the item to the customer and/or request that the customer collect the item at a collection counter.
  • FIG. 25A depicts three screenshots on the mobile devices associated with the three customers, respectively, at a time instance (e.g., a first time instance) when items of their orders are indicated as ready, such as by a kitchen staff.
  • a time instance e.g., a first time instance
  • the mobile device of each customer may individually receive an order ready notification 2502, 2504, 2506 from the server.
  • FIG. 25B depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., a second time instance after the first time instance) after receiving notification that items of their orders are ready.
  • a subsequent time instance e.g., a second time instance after the first time instance
  • Customer 1 may be able to view a notification history page showing a history of the notifications received by his mobile device in relation to his order
  • Customer 2 may simply have remained at the payment thank you page
  • Customer 3 may be able to view a dining history page showing a history of the restaurants where he has dined at along with various information as appropriate, such as the respective total costs.
  • FIG. 25C depicts three screenshots on the mobile devices associated with the three customers, respectively, at a subsequent time instance (e.g., a third time instance after the second time instance).
  • a subsequent time instance e.g., a third time instance after the second time instance.
  • Customer 1 may be able to view a receipt page showing a summary of the items of the orders that have been paid for
  • Customer 2 may simply have remained at the payment thank you page
  • Customer 3 may be at the dining history page.
  • FIG. 26A depicts an exemplary screenshot on an exemplary POS system according to an example embodiment of the present invention.
  • the POS system may be configured to display various information about the tables and orders made at the restaurant, including status of each table and the order made by each customer.
  • the POS system may also be provided with a payment receiving option in the event that a customer may opt to pay by cash.
  • the POS system may be also be configured to analyze the dining history of a customer at the restaurant and generate a number of parameters or statistics on the customer's history with the restaurant, for example, based on information on previous visits to the restaurant stored at the server.
  • the parameters or statistics generated may include a total visit count, a last visit date and time, a total count of each item ordered, and one or more favorite items (e.g., based on the highest count of the one or more items). It will be appreciated by a person skilled in the art that various other parameters or statistics may be also be included as appropriate or as desired. This advantageously enables a restaurant staff to better understand their customer's dining preferences and be able to achieve a more personalized service with the customer (e.g., the customer may be automatically prompted whether they would like to order their most favorite item(s))
  • FIG. 27 depicts exemplary receipts that may be generated for the three orders by the three customers according to various example embodiments of the present invention.
  • various embodiments of the present application may be applied in the food and beverage industry, but are not limited thereto.
  • various embodiments in relation to the group payment functionality may be applied to, for example, shopping, such as online shopping or grocery shopping in person at a store, whereby one customer may decide to pay for one or more other customers' orders (e.g., their friends' orders) in addition to their own orders.

Landscapes

  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé mis en oeuvre par ordinateur pour faciliter la gestion d'un établissement comprenant une pluralité de tables. Le procédé comprend les étapes suivantes consistant à : recevoir une première demande de table et une seconde demande de table, respectivement à partir d'un premier dispositif de communication mobile associé à un premier client et d'un second dispositif de communication mobile associé à un second client, pour prendre place à une première table de la pluralité de tables ; déterminer si le premier client est autorisé à prendre place à la première table ; affecter le premier client en tant que premier régisseur de la première table si ce premier client est déterminé comme étant autorisé à prendre place à la première table ; déterminer si le second client est autorisé à prendre place à la première table ; et affecter le second client en tant que second régisseur de la première table si le second client est déterminé comme étant autorisé à prendre place à la première table. L'invention concerne également un système correspondant, un procédé destiné à faciliter la gestion de tables, et un dispositif de communication mobile correspondant.
PCT/SG2018/050031 2017-01-18 2018-01-18 Procédé pour faciliter la gestion d'un établissement, et système et dispositif associés WO2018136006A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
SG10201700432U 2017-01-18
SG10201700432U 2017-01-18
SG10201700722R 2017-01-27
SG10201700722R 2017-01-27

Publications (1)

Publication Number Publication Date
WO2018136006A1 true WO2018136006A1 (fr) 2018-07-26

Family

ID=62908825

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2018/050031 WO2018136006A1 (fr) 2017-01-18 2018-01-18 Procédé pour faciliter la gestion d'un établissement, et système et dispositif associés

Country Status (2)

Country Link
TW (1) TW201911207A (fr)
WO (1) WO2018136006A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103246720A (zh) * 2013-04-28 2013-08-14 西安交通大学 一种基于移动终端的餐厅推荐及点餐方法
US20140278613A1 (en) * 2012-09-28 2014-09-18 Rakuten, Inc. Information processing apparatus, information processing method, and information processing program
US20140330654A1 (en) * 2013-05-02 2014-11-06 Christopher Michael Turney Payment of restaurant bills
US20160048776A1 (en) * 2013-05-07 2016-02-18 Yoshihiro Azuma Reservation system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140278613A1 (en) * 2012-09-28 2014-09-18 Rakuten, Inc. Information processing apparatus, information processing method, and information processing program
CN103246720A (zh) * 2013-04-28 2013-08-14 西安交通大学 一种基于移动终端的餐厅推荐及点餐方法
US20140330654A1 (en) * 2013-05-02 2014-11-06 Christopher Michael Turney Payment of restaurant bills
US20160048776A1 (en) * 2013-05-07 2016-02-18 Yoshihiro Azuma Reservation system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FAN DIAN MOBILE APPLICATION, 9 June 2016 (2016-06-09), Retrieved from the Internet <URL:https://web.archive.org/web/*/http://www.fundot.com.cn> [retrieved on 20180322] *

Also Published As

Publication number Publication date
TW201911207A (zh) 2019-03-16

Similar Documents

Publication Publication Date Title
US12169862B2 (en) Online ordering for in-shop service
US11348192B2 (en) Systems and methods for personalized dining and individualized ordering by associating electronic device with dining session
US12165227B2 (en) Systems and methods for personalized transactions and individualized payment by associating device with joint transaction
US20150287006A1 (en) Tab Management Method And Apparatus
US20150149307A1 (en) Location-based ordering
US20170308818A1 (en) Payment and ordering system and application for a mobile client
JP6702848B2 (ja) 業務管理方法、業務管理プログラム、及び業務管理装置
US20180240205A1 (en) Order Management Server, Order System, and Recording Medium
US20210209523A1 (en) System and method for end-to-end contactless dining experience and management
US20170213160A1 (en) Service management method and system
US20220207626A1 (en) System and method for contactless dining experience
CN108305414A (zh) 餐厅自动结算方法及系统、智能餐厅
US20200193403A1 (en) Systems and methods for processing customer payments for an establishment
EP3144876A1 (fr) Systèmes et procédés de traitement de commande et de paiements interactifs pour la restauration
US20220207592A1 (en) Contactless dining experience system and method
JP6072966B2 (ja) サービス提供システム及びサービス提供方法
CN105378787A (zh) 店铺用系统
WO2018136006A1 (fr) Procédé pour faciliter la gestion d&#39;un établissement, et système et dispositif associés
US20220327512A1 (en) System and method for enhanced foodservice management
US20220207593A1 (en) Contactless post-dining experience system and method
US11842382B2 (en) Systems and methods for interfacing with point-of-sale systems and customer devices at an establishment
US20220207627A1 (en) System and method for contactless post-dining experience
JP2020129199A (ja) サービス提供装置、サービス提供方法及びプログラム
JP2015014871A (ja) 空席管理装置、および空席管理システム
KR20210011687A (ko) 주문실수 예방 및 신속처리 가능한 식당 주문시스템 및 그 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18741900

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18741900

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载