WO2018136006A1

WO2018136006A1 - Method for facilitating management of an establishment, and system and device thereof

Info

Publication number: WO2018136006A1
Application number: PCT/SG2018/050031
Authority: WO
Inventors: Chuian Feng LUI; Quan Fu LUI; Chee Kean TAN; Chun Hung Justin YAP
Original assignee: Dining Butler Limited
Priority date: 2017-01-18
Filing date: 2018-01-18
Publication date: 2018-07-26
Also published as: TW201911207A

Abstract

There is provided a computer-implemented method for facilitating management of an establishment comprising a plurality of tables. The method includes receiving a first table request and a second table request from a first mobile communication device associated with a first customer and a second mobile communication device associated with a second customer, respectively, to join a first table of the plurality of tables; determining whether the first customer is allowed to join the first table; assigning 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 whether the second customer is allowed to join the first table; and assigning 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. There is also provide a corresponding system, a method of facilitating table management, and a corresponding mobile communication device.

Description

METHOD FOR FACILITATING MANAGEMENT OF AN ESTABLISHMENT, AND SYSTEM AND DEVICE THEREOF

[0001] This application claims the benefit of priority of Singapore Patent Application No. 10201700432U filed 18 January 2017 and Singapore Patent Application No. 10201700722R filed 27 January 2017, the contents of which being hereby incorporated by reference in their entirety for all purposes.

TECHNICAL FIELD

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

BACKGROUND

[0003] Various conventional techniques exist for managing an establishment providing a service to customers. For example, in relation to restaurants, conventional restaurant management techniques generally require one or more restaurant staff to perform various tasks, such as table allocation/assignment management for customers. For example, conventionally, a restaurant staff at a restaurant may be assigned to locate an available table for a customer (or a group of customers). More specifically, when a customer arrives at a restaurant, a restaurant staff may inform the customer to wait at least momentarily while the restaurant staff confirms whether a table is available for accommodating the customer. In this regard, 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. [0004] However, 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. Therefore, if a restaurant staff is not available or is occupied with serving another customer, the customer would not be able to find out whether any table is available and would have to wait to be served. As a result, customer experience with the restaurant may be negatively affected, especially if the customer has to wait for an undesirable long period of time before being served. Furthermore, there also exists a problem whereby one or more tables are already available, but the restaurant staff tasked with table allocation may not promptly update the waiting customer for various reasons, such as being unaware that such one or more tables are already available and/or due to lack of adequate manpower. Therefore, with such a conventional technique, not only may the customer wait unnecessarily, 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. There are also the additional labor costs for training and assigning a restaurant staff to handle the task of table allocation for customers. Disputes may also often arise between the restaurant staff and the customer in relation to table allocation due to various reasons such as a misunderstanding and/or a perceived lack of prompt action by the restaurant staff.

[0005] There also exists a conventional technique whereby a restaurant staff responsible for table allocation (e.g., instead of personally going inside the restaurant and inspecting whether any table is available or communicating with another restaurant staff inside the restaurant via communication devices as mentioned above) may be able to view a display screen providing an overview of the table occupancy at the restaurant. However, such a conventional technique requires a restaurant staff to update the status (e.g., availability) of the tables and also suffers from the same or similar problems as mentioned above. For example, it is still necessary to train and assign such a restaurant staff to handle table allocation for customers, and it is also still required for a customer to engage with the restaurant staff in order to find out whether a table at the restaurant is available. Similarly, even when one or more tables may be indicated on the display screen as being available, 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). In other words, such a conventional technique is still bottlenecked by the capacity and ability of the restaurant staff responsible for handling table allocation.

[0006] There also exists a conventional technique whereby each table is allocated an associated computer tablet for ordering items by any one or more customers occupying the table. Such a computer tablet is pre-programmed to be linked to the associated table such that any order made on the computer tablet is simply deemed to be for any one or more customers occupying the associated table. However, again, such a conventional technique still suffers from the same or similar problems as mentioned above, for example, a restaurant staff is still required to handle table allocation for customers, and it is also still required for a customer to engage with the restaurant staff in order to find out whether a table at the restaurant is available, let alone the high costs to provide and maintain at least one computer tablet for each table in the restaurant.

[0007] Furthermore, for example, with respect to the above-mentioned conventional technique utilizing a computer tablet for each table, 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. Therefore, with such a conventional technique, not only may the customer wait unnecessarily for the bill, the table may also be unnecessarily unoccupied for a certain period of time (e.g., while waiting for the bill to be presented or while queuing to pay for the bill), resulting in inefficiencies in table occupancy and a loss in potential revenue for the restaurant. [0008] A need therefore exists to provide a method for facilitating management at an establishment, and a system and a device thereof, that 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 above), in particular, with respect to an establishment in the business of providing food and/or drink to customers. It is against this background that the present invention has been developed.

SUMMARY

[0009] According to a first aspect of the present invention, there is provided a computer-implemented method for facilitating management of an establishment comprising a plurality of tables, the method comprising:

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;

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;

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.

[0010] According to a second aspect of the present invention, there is provided a system for facilitating management of an establishment comprising a plurality of tables, the system comprising:

a memory;

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;

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, said determine 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 system 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

assign 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. [0011] According to a third aspect of the present invention, there is provided 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:

receiving 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;

determining, 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;

assigning 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, 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; 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.

[0012] According to a fourth aspect of the present invention, there is provided a computer-implemented method for facilitating table management at an establishment comprising a plurality of tables, the method comprising:

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;

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;

determining, by the table management module, whether to join the first table based on the server authorization response received,

receiving, by the table management module, 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 if the first customer is detected to have joined the first table; and

providing, by the table management module in response to the new customer authorization request, a new customer authorization response to the server based on a customer authorization input on the first mobile communication device.

[0013] According to a fifth aspect of the present invention, there is provided a mobile communication device comprising:

a memory;

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;

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 server based on a customer authorization input on the first mobile communication device.

[0014] According to a sixth aspect of the present invention, there is provided 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:

sending 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;

receiving, 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;

determining whether to join the first table based on the server authorization response received,

receiving 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 if the first customer is detected to have joined the first table; and providing, in response to the new customer authorization request, a new customer authorization response to the server based on a customer authorization input on the first mobile communication device. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Embodiments of the present invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of examples only, and in conjunction with the drawings, in which:

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.

24A;

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;

FIGs. 26A and 26B depict an exemplary screenshot on an exemplary POS system according to various example embodiments of the present invention; and 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.

DETAILED DESCRIPTION

[0016] 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. In particular, 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. It will be appreciated by a person skilled in the art that, unless specifically stated otherwise, 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. For example, it will be appreciated that 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.

[0017] As described in the background, various conventional techniques in managing an establishment in the business of providing food and/or drink to customers suffer from various problems. For example, in relation to restaurants, customers may have to wait unnecessarily to find out whether a table is available at a restaurant and/or to be seated at a table even when a table is available. This is because, for example, various conventional techniques require customers to engage with a restaurant staff in order to try to secure a table at a restaurant, and thus, the table allocation stage is inevitably bottlenecked by the capacity and ability of the restaurant staff responsible for handling table allocation for customers. As a result, 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. In this regard, it is not uncommon for disputes to arise between a restaurant staff and a customer in relation to securing a table due to various reasons, such as a misunderstanding or a perceived lack of prompt action by the restaurant staff. Accordingly, not only do such problems result in poor customer experience, they also result in a lower table turnover rate, which lead to a loss in potential revenue for the restaurant.

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

[0019] 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. As described hereinbefore, the establishment may be an establishment in the business of providing food and/or drink to customers. In various preferred embodiments, the establishment is a restaurant, and the plurality of tables is configured for accommodating customers to dine at the restaurant. In various embodiments, 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. In this regard, it will be appreciated by a person skilled in the art that 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. It will also be appreciated by a person skilled in the art that 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.

[0020] 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 to have joined the first table, the above-mentioned 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 a step 110 of 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.

[0021] In various embodiments, in relation to the step 102, 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.

[0022] In various embodiments, in relation to step 104, the table occupany database may be a database comprising information related to each table of the plurality of tables, respectively, at the establishment. For example, 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. For example, 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. It will be appreciated by a person skilled in the art that the information related to each table included in the database described above are by way of examples only, and various type(s) of information described above may be excluded or additional type(s) of information may be included for each table as desired or as appropriate for various purposes. In various embodiments, 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).

[0023] In various embodiments, in relation to step 106, 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. For example, such 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.

[0024] In various embodiments, in relation to step 108, 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. In this regard, 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.

[0025] In various embodiments, in relation to the step 110, similar to the first controller, 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. For example, such 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. For example, if 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).

[0026] In the context of various embodiments, customer(s) that have joined a table

(e.g., occupying the table) may simply be referred to as customer(s) at the table.

[0027] Accordingly, 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. As a result, in an example of 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. This is because, for example, 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. As a result, 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. Thus, customer experience with the restaurant may improve significantly. Furthermore, due to the increase in efficiency in table allocations, the table turnover rate may also improve, thus leading to a potential increase in revenue for the restaurant.

[0028] For example, it can be understood by a person skilled in the art that various technical features, such as but not limited to, a server associated with the restaurant, 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.

[0029] For example, 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. For example, if the first and second customers have joined the first table, both are assigned as controllers of the first table. Accordingly, 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. Furthermore, since all customers that have joined the table are each assigned as a controller (e.g., a co-controller) of the table, in the event that a new customer has request to join 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. For example, if only one customer is assigned as a controller, 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.

[0030] In various embodiments, 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. For example, 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. It will be appreciated by a person skilled in the art that the number of table requests (and thus the number of customers) 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.

[0031] In various embodiments, 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. For example, 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). For example, the table management module may receive a signal comprising the table request and the location data of the mobile communication device. In this regard, 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. In this case, the distance between the mobile communication device and the establishment may be determined based on the TOF of the signal. 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. This advantageously provides the ability to control/filter customers to the establishment such that only customers that are able and ready to proceed to the establishment may request for a table at the establishment so as to minimise no-shows due to various reasons (e.g., cannot find the establishment or change of mind).

[0032] In various embodiments, 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. In other words, from the time which one or more customers join the table, if after a predefined time period 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. For example, this advantageously facilitates the detection of no-shows or customers joining a table and then leaving the table (e.g., change of mind) without informing a staff of the establishment. For example, the predefined time period may be set by the establishment (e.g., a staff managing the establishment) as desired or as appropriate.

[0033] In various embodiments, 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. In this regard, 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. Similarly, 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. For example, this provides the flexibility for a customer to acquire a table initally using a guest account and then decide to sign up or log in to the customer's individualized customer account at a later stage. For example, 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. For example, a guest account may be a customer account that is created without such one or more particulars of the corresponding customer.

[0034] In various embodiments, 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. Furthermore, if it is considered as a new customer, a new table request may be required to be requested by the new customer, and thus, a customer authorization response may be required from the previous guest account. However, such a customer authorization response may not be able to be obtained since the previous guest account has already been logged out. Therefore, as an example, 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).

[0035] In various embodiments, 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. In other words, the current list of one or more items added by a customer to their order (e.g., shopping cart) 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. For example, any changes by a customer on their order may also be immediately reflected to each other customer at the table. For example, 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.

[0036] In various embodiments, 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. For example, 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. In response to such a payment request, 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. In particular, such 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. In other words, 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.

[0037] In various embodiments, 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. In other words, if payment for an order belonging to a customer has been successfully made by another customer (via its mobile communication device) at the table, 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. For example, a predetermined order and payment completion page (e.g., payment thank you page) may then displayed to the customer.

[0038] In various embodiments, 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. For example, 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. Once the preparation of an order has been completed, 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). Upon receiving the order ready input, 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.

[0039] Accordingly, it can be understood by a person skilled in the art that the method 100 according to various embodiments of the present invention 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.

[0040] 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. In various embodiments, the system 200 may correspond to, or may be embodied as, a server associated with the establishment.

[0041] 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 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 system 200 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 assign 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.

[0042] It will be appreciated by a person skilled in the art that 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. 2A 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 authorization response being in response to a first customer authorization request from the system 200 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 assign 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. Accordingly, 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, and 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).

[0043] In various embodiments, 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. In other words, various embodiments described herein in context of the methods are analogously valid for the respective systems or devices, and vice versa.

[0044] For example, in various embodiments, 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.

[0045] 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. [0046] 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. Similarly, as described hereinbefore, the establishment may be an establishment in the business of providing food and/or drink to customers, such as a restaurant. In various embodiments, 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). In various embodiments, 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.

[0047] 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 a new customer requesting to join the first table if the first customer is detected to have joined the first table; and a step 310 of providing, by the table management module in response to the new customer authorization request, a new customer authorization response to the server based on a customer authorization input on the first mobile communication device.

[0048] In relation to step 302, as described hereinbefore with respect to step 102 of the method 100, 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.

[0049] In relation to step 304, 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. For example, 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. Similarly, as described hereinbefore with respect to steps 104 and 108, 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.

[0050] In relation to step 306, 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.

[0051] In relation to step 308, if the first customer is detected to have joined the first table (and thus, is a controller of the first table), 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. In this regard, as a controller of the first table, 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. Accordingly, in relation to step 310, 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. Similarly, 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.

[0052] Similarly, as described hereinbefore with respect to the method 100, the method 300 for facilitating table management according to various embodiments advantageously enables customers to self-manage table allocations/assignments at an establishment, such as a restaurant. As a result, in an example of 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. This is because, for example, 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. As a result, 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. Thus, customer experience with the restaurant may improve significantly. Furthermore, due to the increase in efficiency in table allocations, the table turnover rate may also improve thus leading to a potential increase in revenue for the restaurant.

[0053] For example, it can be understood by a person skilled in the art that various technical features, such as but not limited to, a server associated with the establishment, 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.

[0054]

[0055] In various embodiments, 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. In this regard, 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. For example, such 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. Moreover, as described hereinbefore with respect to the method 100, 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.

[0056] In various embodiments, 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. For example, 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. If the login information is successfully verified (i.e., matches the corresponding account information stored at the account database), 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.

[0057] In various embodiments, 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. For example, 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. Furthermore, the information on item(s) added to one or more other orders by corresponding one or more other customers may be accessed on the first mobile communication device for display. For example, 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. For example, 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.

[0058] In various embodiments, 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. For example, in accordance with a payment option input by the a customer, 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. For example, as mentioned above, 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. For example, in response to such a payment request, 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. In particular, such 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. In other words, 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.

[0059] Accordingly, in various embodiments, 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.

[0060] In various embodiments, 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. In other words, from the time which a payment request notification has been received by a mobile communication device (and thus, the ordering function on the mobile communication device is disabled), if after a predefined time period and no payment confirmation notification for the order made on the mobile communication device has been received by the mobile communication device, then the ordering function on the mobile communication device may be restored to a free or normal state for allowing the order to be modified. For example, the predefined time period may be set by the establishment (e.g., a staff of the establishment) as desired or as appropriate.

[0061] In various embodiments, 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. For example, as described hereinbefore with respect to the method 100 according to various embodiments of the present invention, 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. Once the preparation of an order has been completed, 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). Upon receiving the order ready input, 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.

[0062] Accordingly, it can be understood by a person skilled in the art that the method 300 according to various embodiments of the present invention 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.

[0063] 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. In various embodiments, 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.

[0064] 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 to the new customer authorization request, a new customer authorization response to the server based on a customer authorization input on the first mobile communication device. For example, 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. [0065] It will be appreciated by a person skilled in the art that 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. 4, 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 server based on a customer authorization input on the first mobile communication device. Accordingly, 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, and 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).

[0066] In various embodiments, the mobile communication device 400 corresponds to the method 300 as described hereinbefore with reference to FIG. 1 , therefore, various functions or operations configured to be performed by the at least one processor 404 may correspond to various steps of the method 300 described in hereinbefore, and thus need not be repeated with respect to the mobile communication device 400 for clarity and conciseness. In other words, various embodiments described herein in context of the methods are analogously valid for the respective systems or devices, and vice versa.

[0067] For example, in various embodiments, 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.

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

[0069] 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. For example, 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). [0070] In various embodiments, 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. Thus, in an embodiment, 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. Any other kind of implementation of the respective functions which will be described in more detail below may also be understood as a "circuit" in accordance with various alternative embodiments. Similarly, 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.

[0071] Some portions of the present disclosure are explicitly or implicitly presented in terms of algorithms and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

[0072] Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as "receiving", "determining", "assigning", "maintaining", "linking", "sending", "switching" or the like, refer to the actions and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission or display devices. [0073] The present specification also discloses a system, a device or an apparatus for performing the operations/functions of the methods described herein. 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. Alternatively, the construction of more specialized apparatus to perform the required method steps may be appropriate.

[0074] In addition, 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. Moreover, 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. It will be appreciated by a person skilled in the art that various modules described herein (e.g., table management module 206, order management module 252, payment module 254, kitchen module 256, table management module 408, account management module 452, order management module 454, and/or payment module 456) 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.

[0075] Furthermore, one or more of the steps of 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.

[0076] In various embodiments, there is provided 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. Accordingly, 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.

[0077] In various embodiments, there is provided 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. Accordingly, 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.

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

[0079] 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) may be implemented as software, such as a computer program being executed within the computer system 600, and instructing the computer system 600 (in particular, one or more processors therein) to conduct the methods/functions of various embodiments described herein. 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. 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. 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.

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

[0081] 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. It can be appreciated by a person skilled in the art that 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. 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. For example, 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. 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. 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 (or may simply be referred to herein as "apps") 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). [0082] It will be appreciated by a person skilled in the art that the terminology used herein is for the purpose of describing various embodiments only and is not intended to be limiting of the present invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[0083] 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, and 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.

[0084] In order that the present invention may be readily understood and put into practical effect, various example embodiments of the present invention will be described hereinafter by way of examples only and not limitations. It will be appreciated by a person skilled in the art that the present invention may, however, be embodied in various different forms or configurations and should not be construed as limited to the example embodiments set forth hereinafter. Rather, these example embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art.

[0085] In particular, for better understanding of the present invention and without limitation or loss of generality, various example embodiments of the present invention will now be described with respect to the establishment being a restaurant. However, as mentioned hereinbefore, it will be appreciated by a person skilled in the art that the present invention is not limited to a restaurant, and various other types of establishments are also within the scope of the present invention, as long as the establishment is in the business of providing food and/or drink to customers.

[0086] 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. For example, 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. In contrast, 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.

[0087] According to various example embodiments, 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).

[0088] In various example embodiments, 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. In this regard, 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. For example, 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.

[0089] In various example embodiments, 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. For example, this advantageously addresses a problem whereby customers might join or occupy a table but then decide to leave the restaurant without ordering. For example, the restaurant may set an appropriate time period as the predetermined time period in the table management module at the system.

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

[0091] By way of an example, 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. In various example embodiments, 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. In various example embodiments, 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.

[0092] In various example embodiments, 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).

[0093] For illustration purpose only, FIG. 9 depicts an exemplary schematic overview of a restaurant 902 according to various example embodiments of the present invention. As shown, 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. As an example, 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). In the example, 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". As illustrated by the arrows in FIG. 9, the server 920 (e.g., corresponding to the "system" 200/250 as described hereinbefore according to various embodiments) 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.

[0094] 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. [0095] At 1002, 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. For example, 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. As an example, 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.

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

[0097] At 1006, 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. In various example 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. Once the decision is made by the server 920, the server 920 may then notify each existing customer of the outcome on their respective mobile device.

[0098] For illustration purposes only and without limitation, 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. It will be appreciated that 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. In this regard, FIGs. 1 1A to 11G (and a number of subsequent figures) 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.

[0099] 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). For reference purposes only and without limitation, the first customer (Customer 1), the second customer (Customer 2), and the third customer (Customer 3) may be referred to as "Quanfu", "Dell", and "Logit", respectively. As illustrated, at the first time instance, 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"). At the first time instance, 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. [00100] 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). As illustrated, at the second 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, and Customer 3 has now decided to select and join Table 5. In this example, 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.

[00101] 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). As illustrated, at the third 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, and 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. With respect to Customer 2, similarly, in response to his table selection input 1132 by Customer 2 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.

[00102] 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). As illustrated, at the fourth time instance, Customer 1 has logged in to his user account and has added two items 1142 to his order under his user account. As also shown in FIG. 1 ID, 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. In this regard, 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.

[00103] 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). As illustrated, at the fifth 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. In this example, although the table was occupied at the time, existing Customer 3 has accepted the table request from Customer 2. In addition, since Customer 2 has been allowed to join Table 5, the server has also assigned Customer 2 as a controller (co-controller) of the table. Furthermore, as illustrated on the GUIs on the mobile devices of Customers 2 and 3, 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. As can be observed on the GUI on the mobile device associated with Customer 3, Customer 2 is still under the guest account as Customer 2 has not yet logged in.

[00104] 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). As illustrated, at the sixth 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. However, since Table 5 is currently being occupied by both Customers 2 and 3, the server is configured to send a customer authorization request to each of Customers 2 and 3 to seek a customer authorization response. Therefore, as shown in GUIs of the mobile devices of both Customers 2 and 3, 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.

[00105] 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). As illustrated, at the seventh time instance, Customer 1 has successfully joined Table 5 since he has been determined to be allowed by the server to join the table. In this example, although the table was occupied by both Customers 2 and 3, existing Customer 3 was first to accept the table request from Customer 1. In this example, 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. As a result, Customer 2 has missed the opportunity to accept or decline the table request from Customer 1, and the push notification 1162 on the mobile device of Customer 2 may thus disappear. As Customer 1 has also been allowed to join Table 5, the server has also assigned Customer 1 as a controller (co-controller) of the table. Thus, Table 5 at the seventh time instance has three controllers. Similarly as described hereinbefore, as shown in FIG. 11G, each customer at the table will be able to see the current order(s) of each other customers at the table, such as via selectable tabs 1172, 1174, 1176 presented on the respective GUI.

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

[00107] In various example embodiments, 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. Therefore, at 1204, 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.

[00108] For illustration purposes only and without limitation, 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. For example, FIGs. 13 A and 13B may follow on from the exemplary scenario described above with reference to FIGs. 11 A to 11G.

[00109] 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). As illustrated, at the eighth time instance, Customer 1 is modifying an item in his order. In the example, 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. 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.

[00110] 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). As illustrated, at the ninth 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. Accordingly, as shown in the GUIs on the mobile devices of Customers 2 and 3, 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.

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

[00112] In various example embodiments, 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.

[00113] At 1402, in response to a customer logging in to his/her individualized customer account, it is determined (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.

[00114] For illustration purposes only and without limitation, 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. For example, FIGs. 15 A and 15B may follow on from the exemplary scenario described above with reference to FIGs. 13 A and 13B.

[00115] 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). As illustrated, at the 10^th time instance, Customer 1 may be viewing the current order made by Customer 3 and Customer 3 may be viewing the current order made by Customer 2 (under the guest account). For example, 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).

[00116] 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). As illustrated, at the 11^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. Furthermore, as he has existing items added to his order made under the guest account, such existing items are transferred or swapped to be an order under the individualized customer account 1502. For example, 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. For example, 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.

[00117] For example, without the above-mentioned switching process, there may be a problem whereby Customer 2 under the guest account is already assigned to a table, and if Customer 2 logs in to his individualized customer account, Customer 2 under the individualized customer account may then be considered as no longer occupying the table while the Customer 2 under the guest account remains linked to the table.

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

[00119] At 1604, when a customer logs out, 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.

[00120] At 1606, 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. In this regard, for example, in the event that another customer is viewing the order made by the customer that has just left, 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.

[00121] For illustration purposes only and without limitation, 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. For example, FIG. 17 may follow on from the exemplary scenario described above with reference to FIGs. 15A and 15B.

[00122] 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). As illustrated, at the 12^th time instance, Customer 2 has logged out and thus has been redirected to a home page. In this regard, 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. 17 that the GUI on the mobile device of each of Customers 1 and 3 no longer provides access to any order made by Customer 2 (e.g., the selectable tab 1508, 1510 providing access to the order made by Customer 2 shown in FIG. 15B has been removed). For example, Customer 3 may have been viewing Customer 2's order 1512 as shown in FIG. 15B, but has now been redirected to show his own order summary page 1706. The table occupancy database stored at the server may also be updated to reflect that Customer 2 is no longer linked to Table 5, and thus is also no longer a controller of the table.

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

[00124] For example, as various embodiments of the present invention enables customers to self-manage table allocations at an establishment, such as a restaurant, the server may be configured to perform periodic checks on the status of the tables according to various example embodiments. [00125] At 1802, for each table, 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. On the other hand, if no existing order at the table is detected, at 1806, 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.

[00126] Therefore, 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.

[00127] For example, 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.

[00128] Therefore, according to various example embodiments, 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. It will be appreciated by a person skilled in the art that 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.

[00129] Accordingly, various example embodiments advantageously enable customers to act as controllers and manage their own tables at an establishment such as a restaurant.

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

[00131] In various embodiments, 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). In this regard, various example embodiments of the present invention enable users to perform a group payment of multiple shopping or order carts ordered at a table.

[00132] For example, 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.

[00133] Various embodiments of the present invention advantageously address, or at least mitigate, the above-mentioned problems associated with the above-mentioned conventional technique. In this regard, 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. Accordingly, 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.

[00134] In various embodiments, there is provided 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.

[00135] For example, 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. In response to such a payment request, 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. In particular, such 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. In other words, 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, 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.

[00136] However, it is identified according to various embodiments of the present invention that 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. It will be appreciated by a person skilled in the art that the predetermined time period may be set as appropriate or as desired, such as by a restaurant staff or administrator. By way of an example and without limitation, the predetermined time period may ranging from 30 seconds to 5 minutes, 1 to 4 minutes, or 2 to 3 minutes.

[00137] Accordingly, various embodiments of the present invention advantageously facilitate group payment in an establishment, such as a restaurant, as well as providing order management.

[00138] Various example embodiments of the present invention will be described hereinafter by way of examples only and not limitations. It will be appreciated by a person skilled in the art that the present invention may, however, be embodied in various different forms or configurations and should not be construed as limited to the example embodiments set forth hereinafter. Rather, these example embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art.

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

[00140] At step 1904, in response to a customer modifying his/her order, 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.

[00141] At step 1906, 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.

[00142] By way of example only, 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).

[00143] Accordingly, 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.

[00144] For illustration purposes only and without limitation, 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.

[00145] 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). As illustrated, at the 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, and 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. For example, 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.

[00146] 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). As illustrated, at the second time instance, Customer 1 has modified the item to "3 x Ice Lemon Tea". In this regard, the server is configured to send the information on the updated order by Customer 1 to Customers 2 and 3. As a result, as shown in FIG. 20B, 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.

[00147] For illustration purposes only and without limitation, 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. For example, FIGs. 21A and 21B may follow on from the exemplary scenario described above with reference to FIGs. 20A and 20B.

[00148] 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). As illustrated, at the third 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). For example, a timer 2104 may be initiated to provide a time within which the payment has to be completed. While Customer 2 is at the payment page, Customer 3 decided to modify his order to, for example, add an item.

[00149] 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). As illustrated, at the fourth time instance, Customer 2 is still at the payment page, although the timer 2014 is now down to 23 seconds left. With respect to Customer 3, since 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. As a result, for example, 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. As shown, 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).

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

[00151] At 2202, in response to a confirmed order, 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). If the order type is a dine-in or take-away type, 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.

[00152] At 2206, 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. If so, 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. [00153] For illustration purposes only and without limitation, 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.

[00154] According to an exemplary scenario whereby Customer 2 decides to pay for the three orders made by himself and Customers 1 and 3, 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). As illustrated, at the 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, and Customer 3 may be at a payment option summary page with options to pay for one or more orders.

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

[00156] 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. As illustrated, at the third time instance, 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. In this regard, the mobile device of Customer 1 is directed to the payment thank you page from the order summary page, and the mobile device of Customer 2 is directed to the payment thank you page from the payment option summary page shown in FIG. 23B.

[00157] According to another exemplary scenario whereby Customer 2 decides to pay for only the two orders made by himself and Customer 3, 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). As illustrated, at the 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, and Customer 3 may be at an order summary page (e.g., viewing his order cart). [00158] 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). As illustrated, at the second 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, and Customer 3 may still be at the order summary page.

[00159] 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. As illustrated, at the third time instance, 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.

[00160] Accordingly, 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.

[00161] In various example embodiments, 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. As an example illustration, FIG. 24A shows an example kitchen screen being displayed for the three orders made by the three customers. As shown, the information displayed may include the customers' names, their table number, the items they have ordered, along with any special requests. In various example embodiments, each item of an order may be individually itemized so that the status of each order can be updated and accounted for individually. As an example illustration, FIG. 24B shows an example waiter screen based on the same three orders. For example, 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.

[00162] 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. As shown, the mobile device of each customer may individually receive an order ready notification 2502, 2504, 2506 from the server.

[00163] 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. For example, 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, and 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.

[00164] 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). For example, 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, and Customer 3 may be at the dining history page. Furthermore, at the dining history page, it is possible to provide a review or feedback of their experience with the restaurant.

[00165] For illustration purpose only, FIG. 26A depicts an exemplary screenshot on an exemplary POS system according to an example embodiment of the present invention. As shown, 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. For example, as shown in FIG. 26B, 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. For example, 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))

[00166] As an example illustration only and without limitation, 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.

[00167] It can be understood by a person skilled in the art that various embodiments of the present invention may be implemented to operate with an existing POS system at a restaurant.

[00168] As mentioned hereinbefore, various embodiments of the present application may be applied in the food and beverage industry, but are not limited thereto. As a further example, 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.

[00169] While embodiments of the invention have been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

CLAIMS What is claimed is:

1. A computer-implemented method for facilitating management of an establishment comprising a plurality of tables, the method comprising:

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.

2. The method according to claim 1 , further comprising:

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

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, said 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.

3. The method according to claim 1 or 2, 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.

4. The method according to any one of claims 1 to 3, further comprising setting, by the table management module, a state 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.

5. The method according to any one of claims 1 to 4, wherein said assigning comprises linking, by the table management module, an account associated with the first customer to the first table, wherein 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.

6. The method according to claim 5, further comprising 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, wherein said switching includes transferring 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.

7. The method according to any one of claims 1 to 6, further comprising:

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

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.

8. The method according to claim 7, further comprising:

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 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 method according to claim 8, further comprising 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.

The method according to any one of claims 7 to 9, further comprising:

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 for displaying information on the first order and/or the second order;

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

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 system for facilitating management of an establishment comprising a plurality of tables, the system comprising:

a memory;

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;

assign 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.

12. The system according to claim 11, wherein the at least one processor is further configured to: receive 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

determine, 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, said determine 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.

13. The system according to claim 11 or 12, wherein the at least one processor is further configured to control 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.

14. The system according to any one of claims 11 to 13, wherein the at least one processor is further configured to set a state 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.

15. The system according to any one of claims 11 to 14, wherein said assign the first customer comprises linking an account associated with the first customer to the first table upon the first customer being allowed to join the first table, wherein 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.

16. The system according to claim 15, wherein the at least one processor is further configured to switch 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, wherein said switch 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.

17. The system according to any one of claims 11 to 16, wherein the at least one processor is further configured to:

maintain, at the second mobile communication device associated with the second customer, 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

maintain, at the first mobile communication device associated with the first customer, a second current list of one or more items added to a second order by the second customer via the second mobile communication device.

18. The system according to claim 17, wherein the at least one processor is further configured to:

receive 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

send, in response to the payment request, 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.

19. The system according to claim 18, wherein the at least one processor is further configured to send 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.

20. The system according to any one of claims 17 to 19, wherein the at least one processor is further configured to:

send the first order and/or the second order, upon being submitted or paid, to a display device for displaying information on the first order and/or the second order;

receive 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

send 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.

21. 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:

A computer-implemented method for facilitating table management at an establishment comprising a plurality of tables, the method comprising:

The method according to claim 22, further comprising 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 being linked to the first table, wherein 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 according to claim 23, further comprising 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, wherein said switching includes transferring 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 method according to any one of claims 22 to 24, further comprising:

receiving from the server, by an order management module at the first mobile communication device, 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

providing access to the current information associated with the second order received on the first mobile communication device for display.

The method according to claim 25, further comprising:

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 method according to claim 25, further comprising:

receiving, by the order management module, 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 according to claim 27, 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.

29. The method according to any one of claims 25 to 28, further comprising:

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;

presenting the first order ready notification on the first mobile communication device.

30. A mobile communication device comprising:

a memory;

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 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:

receiving 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 if the first customer is detected to have joined the first table; and

providing, in response to the new customer authorization request, a new customer authorization response to the server based on a customer authorization input on the first mobile communication device.