A COMPUTER-ENABLED METHOD, SYSTEM AND COMPUTER PROGRAM FOR PROVIDING AN INTUITIVE USER INTERFACE ARRANGED TO CREATE A DYNAMIC PRODUCT LIST INTEGRABLE INTO A SERVICE PROVISION PROCESS TO PERFORM THE TASK OF DELIVERING A COMPLEX SERVICE AND MANAGING AN ASSOCIATED TRANSACTION

Technical Field

[0001] The invention relates to a system, method and computer program for providing a dynamic and intuitive user interface arranged to create menu items comprising ingredients and alternate menu items that can be configured to create different dynamic menus with different price points within a volumetric framework using a product tree structure, stock and purchasing integrations that can be attached to one or more physical or furniture items within a venue for different booking times and different durations that can be seamlessly integrated into a dynamic ordering system as part of a booking allocation process and using a product tree

[0002] In one embodiment, the invention is directed at the integration of the dynamic menu and ordering system into a configurable widget or app for the identification of the user and the user’s constraints for the presentation of an individual dynamic menu whereby the selection of menu items can be seamlessly integrated into a booking allocation process where the menu items and menu selected are constraints used in the booking allocation process to determine an optimised outcome.

[0003] In one embodiment, the invention provides a complete transaction audit trail so that the menus and menu system as well as the booking allocation system form part of the core accounting systems for the autonomous transfer, printing, including operational elements as well as reconciliation of menu selections, deposits, part payments, final payments and the completion of the total service and transaction process utilising a volumetric framework or with the use of a traditional two dimensional POS system.

Background

[0004] Restaurant dine-in menus have traditionally been written or printed on paper, where ordering has been through a process of a customer selecting items from that paper menu and then a staff member entering the selected items within a POS system.

[0005] In more recent times, electronic menus have been created for restaurant dine-in patrons but have followed the previous logic of paper menus whereby they are essentially paper menus being displayed on an electronic device. In other words, the electronic menus have had little or no transactional integration linked to a booking process. Further, the prior art does not utilise menu selections as constraints within the booking allocation process. For example, the prior art only recognises group sizes as the only constraint that can impact the dining duration time and hence the time allowed or allocated for a booking. As one can easily understand, a person having a one course meal requires far less dining time at a table than a person having a three-course meal. Further, it is also easy to understand that a person consuming a three-course meal offers greater revenue and contribution to the venue. As such, the ability to offer different duration times for different bookings represents something that has great economic benefit to a restaurant.

[0006] The prior art also has no ability to consider the different cooking times of different menu items, for example as noted earlier, the prior art can only recognise different dining duration times for different group sizes. It has no ability to differentiate different cooking times between different menu selections, for example a person having three course meal comprising scallops, pan-fried fish and a chocolate cake can complete their meal far more quickly than a person having caviar, a 1 -kilogram T-bone steak and a souffle, simply because of the different cooking times involved. The cooking time information can therefore be a critical constraint in the determination or application of booking durations applied to a booking either before or after the original booking allocation process, as a booking duration time can be amended by being increased or decreased during a subsequent menu selection process. This menu selection time duration constraint can be further constrained by other factors such as the price of the selected menu items, the booking time, the day, the occasion, etc.

[0007] With the more recent introduction of pre-ordering, again the pre-order menus for dine-in restaurants are treated as information collection sources and for information transmission. Such information has not been collected and used as transactional information as all prior art dine-in restaurant booking systems are programmed and designed as booking systems, and not as secure transactional systems that are integral to accounting systems when accounting for pre-payments, deposits, part-payments and full payments that can be reconciled and seamlessly transferred to other accounting and transaction systems such as POS systems, trust accounts, revenue received in advance accounts, banking reconciliations, or directly to a general ledger. As noted above, booking duration times are pre-set by the prior art and cannot be changed during a menu pre-order process, resulting in processes that are not optimised.

Summary

[0008] In one aspect, the invention provides a computer-enabled method for creating an interactive menu comprising one or more of a food item, beverage item or other item or service arranged to be associated with a booking system, the menu including one or more constraints utilised as input to allocate booking requests to one or more spaces in a venue, comprising

an operator user interface arranged to allow an operator to enter information regarding a plurality of menu items to appear on each of the one or more menus, each of the plurality of menu items including one or more products having ingredients and attributes, including a series of permutations of menu items, the permutations relating to at least one of an allergy indication, a dietary requirement, a dietary preference, and a recipe alternative, whereby the attributes of the menu items are associated with one or more constraints associated with a booking request including one or more persons associated with the booking request, whereby when a booking request is assessed with all other constraints is allocated to one of the one or more spaces by a dynamic booking allocation algorithm to generate a booking, an interactive menu including at least one of more menu items is generated in response to the dynamic allocation of the booking request, the interactive menu being linked with at least one of the one of the one spaces allocated to the booking and the one or more persons associated with the booking request,

whereby the dynamically allocated booking requests are saved in a database and the optimised allocation instruction set is made available to one or more of a user associated with the venue and the booking requestor, whereby the interactive menu is capable of being provided by an interface for interaction by the one or more persons associated with the booking request or an associated third party or the venue, whereby upon selection of menu items by the one or more persons associated with the booking request or associated third parties, the menu items are associated with the booking.

[0009] The method may comprise the further step of the one or more tables being associated with a volumetric space/time framework arranged to provide information regarding the spatial positioning of each one of the one or more tables over time, whereby the menu is associated with the volumetric space/time framework.

[0010] The method may comprise the further step of providing a menu module capable of receiving information regarding alternative related products, the alternative related products being arranged to selectively be provided on the interactive menu in response to constraints derived from the booking allocation.

[0011] The method may comprise the further step of the module utilising the menu selected to determine the availability of a space and the ability to effect an optimised condition.

[0012] If the product request is not confirmed then the booking requestor may be provided with at least one alternative determined utilising the constraint information.

[0013] In one embodiment, the menu attributes include a:

[0014] a. specific service;

[0015] b. specific booking time;

[0016] c. specific duration time;

[0017] d. specific day of the week;

[0018] e. specific date;

[0019] f. specific group size;

[0020] g. specific occasion; and

[0021] h. specific booking duration.

[0022] In one embodiment, the menu includes associated constraint information regarding supplementary items including:

[0023] a. extended duration times;

[0024] b. locations within a venue;

[0025] c. classes of tables within a venue;

[0026] d. specific types of table;

[0027] e. specific tables within a venue; and

[0028] f. specific levels of service.

[0029] In one embodiment, the price associated with each menu item is dynamically set according to:

[0030] Price by menu item;

[0031] Price by menu;

[0032] Price by product by time;

[0033] Price by product by group size;

[0034] Price by occasion;

[0035] Price by period of extended duration time;

[0036] Price by peak and off-peak times; [0037] Price by table based on table utility and table location characteristics;

[0038] Booking fees;

[0039] Price by additional services; and

[0040] Discounts and promotions during less popular times.

[0041] In one embodiment, the booking user interface is arranged, in response to constraint information provided by the booking requestor, to provide additional constraint information to the booking requestor, whereby the booking requestor may choose to accept the additional constraint information or may choose to alter their request.

[0042] In one embodiment, the method includes the further step of providing menu constraint information regarding menus available dependant on the time period constraint information provided by the booking requestor, whereby the booking requestor can select, via the interface, to accept the additional constraint information or alter the request dependent on the menu constraint information.

[0043] In one embodiment, the method includes the further step of utilising menu constraint information regarding the number of courses or products or services provided in a menu based on the at least one request to constrain or select the interactive menu displayed to the booking requestor.

[0044] In one embodiment, the method includes the further step of the database including time and/or date constraint information regarding at least time and/or date that a space is available to be allocated whereby each time and/or date includes an indicator arranged to allocate a relative rating to the time and/or date, whereby the rating is utilised as a constraint condition, whereby the booking requestor is maybe prompted to pay an amount or take a further action to secure the booking dependent on the time and/or date or other criteria.

[0045] In one embodiment, the method includes the further step of the booking requestor interface allowing the booking requestor to select at least one item from at least one menu to be served during the time period of the booking.

[0046] In one embodiment, the user interface is configured to enable the at least one booking requestor to select a menu, and items on the menu for the allocated use of the space and pay for at least a portion of the use of the space in advance of using the space.

[0047] The method may include the step of providing an invitation module configured to enable the booking requestor to invite one or more additional remote users to use the user interface to select menu items from the interactive menu.

[0048] In another aspect, the invention provides a computer-enabled method for creating a menu arranged to be associated with a table and table combination framework to devise a floor plan where spaces are associated with one or more menus, comprising an operator user interface arranged to allow an operator to enter information regarding a plurality of menu items to appear on each of the one or more menus, each of the plurality of menu items including one or more products having ingredients and attributes, the products being organised in a tree structure, the tree structure including a series of permutations of menu items, the permutations relating to at least one of an allergy indication, a dietary requirement, and a dietary preference, whereby the attributes of the menu items are associated with one or more constraints associated with a booking request, whereby an interactive menu is generated in response to the booking request, the interactive menu being linked with a sub-set of the plurality of menu items,

whereby the interactive menu is capable of being displayed on an interface for interaction by a booking requestor or an associated third party, whereby selected menu items are associated with the booking request.

[0049] In another aspect, the invention provides a computer-enabled method for creating a menu comprising one or more of a food item, beverage item or other item or service arranged to be associated with a booking system, the menu including one or more constraints utilised as input to allocate booking requests to a time period associated with a space in a venue, comprising an operator user interface arranged to allow an operator to enter information regarding a plurality of menu items to appear on each of the one or more menus, each of the plurality of menu items including one or more products having ingredients and attributes, including a series of permutations of menu items, the permutations relating to at least one of an allergy indication, a dietary requirement, a dietary preference, and a recipe alternative,

whereby the attributes of the menu items are associated with one or more constraints associated with a booking request including one or more persons associated with the booking request, whereby when a booking request is assessed with all other constraints is allocated to one of the one or more of a plurality of tables by a dynamic booking allocation algorithm to generate a booking, an interactive menu including at least one of more menu items is generated in response to the dynamic allocation of the booking request, the interactive menu being linked with at least one of the one of the time period associated with the space in the venue and allocated to the booking and the one or more persons associated with the booking request,

whereby the dynamically allocated booking requests are saved in a database and the optimised allocation instruction set is made available to one or more of a user associated with the venue and the booking requestor, whereby the interactive menu is capable of being provided by an interface for interaction by the one or more persons associated with the booking request or an associated third party, whereby upon selection of menu items by the one or more persons associated with the booking request or associated third parties, the menu items are associated with the booking.

[0050] In some embodiments, the method includes the step of each of the plurality of menu items including one or more products being organised in a tree structure.

[0051] In another aspect, the invention provides a computer-enabled method for creating a menu including one or more of a food item, beverage item, other item or service arranged to be associated with a booking system, the menu including one or more constraints utilised as input to allocate booking requests to one or more of a plurality of tables in a space in a venue, comprising an operator user interface arranged to allow an operator to enter information regarding a plurality of menu items to appear on each of the one or more menus, each of the plurality of menu items including one or more products having ingredients and attributes, the products being organised in a tree structure, the tree structure including a series of permutations of menu items, the permutations relating to at least one of an allergy indication, a dietary requirement, a dietary preference, and a recipe alternative, whereby the attributes of the menu items are associated with one or more constraints associated with a booking request including one or more persons associated with the booking request, whereby when a booking request is assessed with all other constraints is allocated to one of the one or more of a plurality of tables by a dynamic booking allocation algorithm to generate a booking, an interactive menu including at least one of more menu items is generated in response to the dynamic allocation of the booking request, the interactive menu being linked with at least one of the one of the one or more of a plurality of tables allocated to the booking and the one or more persons associated with the booking request,

whereby the dynamically allocated booking requests are saved in a database and the optimised allocation instruction set is made available to one or more of a user associated with the venue and the booking requestor, whereby the interactive menu is capable of being provided by an interface for interaction by the one or more persons associated with the booking request or an associated third party, whereby upon selection of menu items by the one or more persons associated with the booking request or associated third parties, the menu items are associated with the booking.

[0052] In one embodiment, the method comprises the step of creating a product tree which includes menu items, ingredients and cooking instructions which comprise the further step of menu permutations of the original menu, together with menu permutation ingredients, recipes and pricing, to cater for allergies and dietary requirements, such that a menu permutation would be displayed as required and the menu permutation and the menu permutation price would apply as part of the transaction process, stock decrementing, stock ordering and stock control, such that the menu and any menu ordering process are treated as part of, and integral, to the accounting and financial systems of the venue.

[0053] In one embodiment, the menu items and menu permutations include duration times required for cooking and/or consumption times, such that these additional times can be used to determine or adjust the booking duration times permitted and applied during the booking allocation process, or to subsequently amend the original duration times applied during the booking allocation process or any subsequent pre-ordering menu selection process, or any subsequent changes to the menu or items selected.

[0054] In one embodiment, including a configurable widget as detailed in the "widget application”, as detailed in Table 1 , supporting this present application to identify the channel and/or the user and retrieve the preferences, information and constraints applicable to the channel and/or user to provide an personalised menu that is dynamic, interactive and personalised with respect to the channel and to the individual user.

[0055] In one embodiment, a link to the user's selected menu and booking information so that selections, amendments, changes or additions can be made to the booking and the booking information, whereby those additional changes may impact the booking allocation details.

Brief Description of the Drawings

[0056] Further features of the present invention are more fully described in the following description of several non-limiting embodiments thereof. This description is included solely for the purposes of exemplifying the present invention. It should not be understood as a restriction on the broad summary, disclosure or description of the invention as set out above. The description will be made with reference to: [0057] FIG. 1 a is an example computing system on which a method and/or a computer program may be operated, in accordance with an embodiment of the invention;

[0058] FIG. 1 b is an example of a flowchart illustrating a computer system upon which a computer enabled method may be operated, in accordance with an embodiment of the invention;

[0059] FIGs. 1 c, 1 e and 1f are illustrations of a volumetric (three-dimensional) framework for providing a complex product and service in accordance with an embodiment of the invention;

[0060] FIG. 1d is an illustration of a volumetric (three-dimensional) framework for providing a complex product and service in accordance with an embodiment of the invention, as compared to a an embodiment of the prior art;

[0061] FIGs. 2a-2e are flowcharts illustrating a computer enabled method for a booking process in accordance with an embodiment of the invention;

[0062] FIGs. 2f-2g are flowcharts illustrating a computer enabled method for a booking process in accordance with an embodiment of the prior art;

[0063] FIGs 3a-d are diagrams illustrating a prior art transaction process and a transaction process in accordance with an embodiment of the invention;

[0064] FIGs. 4a-h are screenshots illustrating constraint set-ups within the system including pre-order constraints, menu set-up, menu and course duration time set-ups, Super VIP and VIP overrides, table reset times;

[0065] FIGs. 5a-d are screenshots illustrating the product tree and product set-ups in accordance with an embodiment of the invention.

[0066] FIG 5e is a flowchart illustrating a product setup procedure to enable a menu configuration in accordance with an embodiment of the invention;

[0067] FIGS 5f-h are screenshots illustrating a product setup (including alternatives) in accordance with an embodiment of the invention;

[0068] FIGs. 6a-i are screenshots illustrating a setup process in accordance with an embodiment of the invention;

[0069] FIG 7a is a flowchart illustrating a setup process in accordance with an embodiment of the invention;

[0070] FIGs 7b-c are screenshots of an interface for a setup process in accordance with an embodiment of the invention;

[0071] FIGs 8a-8e are screenshots illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;

[0072] FIGs 9a-b are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;

[0073] FIG 9c-d are diagrams illustrating a prior art transaction process and a transaction process in accordance with an embodiment of the invention;

[0074] FIG 9e is a flowchart illustrating a menu pre-ordering and payment process in accordance with an embodiment of the invention; [0075] FIG 9f is a modular diagram illustrating the components of a widget and a database in accordance with an embodiment of the invention;

[0076] FIGs 10a-d are screenshots of an interface illustrating an aspect of a dynamic floor plan interface in accordance with an embodiment of the invention;

[0077] FIG 11 a is a modular representation of the data constructs and the modules utilised to process a booking request in accordance with an embodiment of the invention;

[0078] FIGs 12a-b are screenshots depicting a menu headings setup set of screens in accordance with an embodiment of the invention;

[0079] FIGs 13a-b are screenshots depicting a menu folders setup set of screens in accordance with an embodiment of the invention;

[0080] FIGs 14a-k are screenshots depicting a duration menu setup set of screens in accordance with an embodiment of the invention;

[0081] FIGs 15a-b are screenshots depicting a non-duration menu setup set of screens in accordance with an embodiment of the invention;

[0082] FIG 16a is a screenshot depicting a menu pricing screen in accordance with an embodiment of the invention;

[0083] FIGs 17a-e are screenshots depicting a restaurant service setup set of screens in accordance with an embodiment of the invention;

[0084] FIGs 18a-b are screenshots depicting a product size setup set of screens in accordance with an embodiment of the invention;

[0085] FIGs 19a-d are screenshots depicting a product tree setup set of screens in accordance with an embodiment of the invention;

[0086] FIGs 20a-d are screenshots depicting a butler service setup set of screens in accordance with an embodiment of the invention;

[0087] FIGs 21 a-b are diagrammatic representations of the modules and components of a system in accordance with an embodiment of the invention;

[0088] FIGs 21c is a flow chart depicting a menu setup and posting process in accordance with an embodiment of the invention;

[0089] FIGs 22a-b are flow charts depicting a pre-ordering process utilised to manage the flow and transactions in a restaurant or venue in accordance with an embodiment of the invention;

[0090] FIGs 23a-b are screenshots depicting a menu ordering app for use in managing guests associated with a booking at a restaurant or venue in accordance with an embodiment of the invention;

[0091] FIGs 24a-f are screenshots depicting a menu ordering app for use in managing the pre-ordering of a meal in accordance with an embodiment of the invention;

[0092] FIGs 25a-b are flow charts depicting an image recognition system process utilised to manage the flow and transactions in a restaurant or venue in accordance with an embodiment of the invention; [0093] FIGs 26a-l are screenshots depicting an in-service application for use by a customer and/or associated guests to manage the flow and transaction in a restaurant or venue in accordance with an embodiment of the invention;

[0094] FIGs 27a-m are screenshots depicting an in-service application for use by a staff member to manage the flow and transactions in a restaurant or venue in accordance with an embodiment of the invention;

[0095] FIG 28a is a flow chart depicting an image recognition system process utilised to manage the flow and transactions in a restaurant or venue in accordance with an embodiment of the invention;

[0096] FIGs 28b-c are diagrammatic representations of an in-service app and image recognition system utilised to manage the flow in a restaurant or venue in accordance with an embodiment of the invention;

[0097] FIGs 28d-e are flow charts depicting an image recognition system process utilised to manage the flow and transactions in a restaurant or venue in accordance with an embodiment of the invention;

[0098] FIG 28f is a diagrammatic representation of an in-service app and image recognition system utilised to manage the flow in a restaurant or venue in accordance with an embodiment of the invention;

[0099] FIG 29a is a diagrammatic representation of an architecture of multiple devices interacting to produce a single transaction in accordance with an embodiment of the invention; and

[0100] FIGs 30a-h are screenshots depicting a set of dashboard screens in accordance with an embodiment of the invention.

Description of Embodiments

The Computing System

[0101] One embodiment of the computing system is shown at FIG. 1 a.

[0102] In FIG. 1 a there is shown a schematic diagram of a computing system, which in this embodiment is a computing system 100 suitable for use with an embodiment of the present invention. The computing system 100 may be used to execute application and/or system services such as a computer program and an interface in accordance with an embodiment of the present invention.

[0103] With reference to FIG. 1 a, the computing system 100 may comprise suitable components necessary to receive, store and execute appropriate computer instructions. The components may include a processor 102, read only memory (ROM) 104, random access memory (RAM) 106, an input/output devices such as disc drives 108, remote or connected mobile devices 1 10 (such as computers, smartphones or tablets and the like), and one or more communications link(s) 114 including internet links to other applications, websites and system services including Internet cloud services 120.

[0104] The computing system 100 includes instructions that may be installed in ROM 104, RAM 106 or disc drives 1 12 and may be executed by the processor 102. There may be provided a plurality of communication links 1 14 which may variously connect to one or more user devices 1 10, such as computers, smartphones or tablets, wherein the one or more user devices have a user interface for interacting with user by collecting and displaying data or information using the conventional means provided by such devices. At least one of a plurality of communications link 114 may be connected to an external computing network through a telecommunications network, including Internet cloud services 120.

[0105] In one particular embodiment the device may include a database 116 which may reside on the storage device 1 12. It will be understood that the database may reside on any suitable storage device, which may encompass solid state drives, hard disc drives, optical drives or magnetic tape drives. The database 1 16 may reside on a single physical storage device or may be spread across multiple storage devices, either locally or remotely.

[0106] The computing system 100 includes a suitable operating system 118 which may also reside on a storage device or in the ROM of the server 100. The operating system is arranged to interact with the database 1 16 and with one or more computer programs to cause the server to carry out the steps, functions and/or procedures in accordance with the embodiments of the invention described herein.

[0107] The user interface 110 of one or more mobile devices facilitates the collection and display of user data for the computing system 100. The user interface 1 10 may be a program or website accessed on a computer or mobile device via a communication network, such as the Internet. Alternatively, the user interface 1 10 may be a widget arranged on a website that may be accessed by a user using a computer or mobile device via a communication network such as the Internet. The user interface 1 10 may also be provided as a mobile application or "app” present on the user device, such as a tablet or smart phone.

[0108] The at least one user interacts with the user interface 1 10 and may be a first user (also referred to as the "booking requestor”) requesting to use a space in a venue. The at least one user may also include a second user (referred to as the "operator” or "venue operator”), who is associated with the venue and utilizes the optimised space allocation instruction set provided by the allocation module to enable the use of the space by the booking requestor.

[0109] The booking requestor interacts with the computing system to make a request. The requestor may make a request for one or more patrons of the venue to use the space in a venue, where the requestor may also be one of the patrons of the venue. That is, a user that interacts with the system is referred (on their own behalf or on behalf of a group of people) is referred to as a booking requestor and the person (or group of people) that will be allocated a table (i.e. attend the venue or restaurant) may be variously referred to as the "patron” or "patrons”, the "customer” or "customers”, the "guest” or "guests” and/or the "diner” or "diners”, or any other term as appropriate for the venue.

[01 10] An embodiment includes the computer system 100 processing the request and undertaking all subsequent steps in an autonomous manner. Alternatively, in another embodiment, the operator may use one of the user interfaces 1 10 provided to one or more devices to receive, input, or modify information in order to provide further input to the computer system 100, so that the computing system may process the request and provide instructions to the entity.

[01 1 1] In processing the request, the computer system 100 may arrange objects in the space in accordance with the optimised space allocation instruction set. That is, the booking requestor acts as a customer making a request which is to be "serviced” by the operator in accordance with the optimised space allocation instruction set. As may be appreciated by a skilled addressee, there may be any number of remote users and operators who are able to interact with the computing system via the user interface 1 10 via any number of different devices.

[01 12] Referring to Figure 1 b there is shown a schematic diagram of the ResButler project. The ResButler application 126 is hosted in a cloud computing environment. The ResButler project 128 includes a web server 130 a venue login and security database 132, an allocation module or system 134 comprising one or more modules or algorithms 136, which connect to a venue database 138 and a venue web server 140. The ResButler project 128 connects with multiple devices 142, 148 and 152. The device 142 is a third party desktop forward/laptop that is capable of displaying a website rendered by venue web server 140. The venue web server 144 incorporates a venue booking widget 146. Similarly, device 148 is a mobile device such as a smartphone or tablet computing system. The device 148 includes an instance of the menu app 150. Analogously, device 152 is a kiosk including a computing system capable of executing a venue kiosk app 154. The ResButler project 128 also interfaces with a device 120 which is located within the venue. The devices 120 may include a point of sale device (POS) 124 and or a device capable of displaying a dashboard 122 in accordance with an embodiment of the invention.

[01 13] Referring to FIG. 1c, there is shown a diagrammatic representation of a space and volume framework 158. The framework 158 is based on a cartesian three-dimensional framework, which acts as a frame of reference to allow for the visualisation of the elements required to operate a space, including the physical movement of items within the space. The volumetric framework 158 operates across three axes, generically labelled the x-axis 162, the y-axis 156 and the z-axis 160. Each of the axes allow a constraint to be physically mapped relative to the two other constraints that constitute the framework. This provides an additional dimension with which to provide a complete visualisation and operation of the management of a space, as can be seen with reference to FIG. 1 d.

[01 14] Referring to FIG. 1d, there is shown a diagrammatic representation of a space and volume framework as applied to a restaurant booking system in accordance with the embodiment of the invention. There is shown the three-dimensional framework 170 with dimension x 178, dimension y 164 and dimension z 166, compared to a prior art framework 168 which illustrates a Gantt chart 176 including a first dimension 172 and a second dimension 174.

[01 15] Referring to FIG. 1e, there is shown a diagrammatic representation of a space and volume framework as applied to a dual diary system in accordance with the embodiment of the invention. In more detail, there is described a practical application of the concept of FIG. 1 d where the framework 186 with dimensions x 188, y 182 and z 184 are located within the context of a posting calendar 180, which is arranged to interact with a user-defined reporting calendar 190.

[01 16] Referring to FIG. 1f, there is shown a diagrammatic representation of a space and volume framework as applied to a restaurant booking system in accordance with the embodiment of the invention. A restaurant floor plan 192 is overlaid on the three-dimensional framework. In more detail, a floor plan creation module 194 is utilised to create a floor plan for a restaurant, including the size and shape of the restaurant space, the creation of sub-areas and sections, the division of the areas and/or sub areas into classes, the addition of tables and chairs (including dimensions), etc. The floor plan is placed in the volumetric framework 198 within the calendar 196, where the x and y axes represent the length and width of the space, and the z axis represents time. As such, each area, sub area, class, table, chair, etc. can be tracked over time. The z axis is controlled by a time constraint module 193 which includes time constraints 195 such as opening hours, seating periods, etc.

[01 17] In other words, the volumetric framework, in addition to the calendar and the floor creation module and time constraint module create a real time simulation of the restaurant, allowing the operator to track all aspects of the restaurant/space over time. This framework is derived from the realisation that the pivotal structure (both physical and conceptual) in the operation of a space such as a restaurant, is the booking and how the booking is allocated and managed. The placement of tables and chairs, the opening hours, the food served, the staff employed, etc., are ultimately all connected to the booking. As such, the volumetric model is a completely different manner in which to conceptualise the operation of a space (and in particular a restaurant space or any other space where a service is provided and there are multiple constraints).

[01 18] Referring to Figures 2a-2g, there is shown a series of flow charts illustrating a comparison between the prior art and a system in accordance with an embodiment of the invention. These figures were previously included in PCT application PCT/AU2018/051 168 (and co-pending PCT application PCT/AU2018/051 169, PCT/AU2018/051 170 and PCT/AU2018/051 171 ) as noted in the background above and also, in the artificial intelligence Australian provisional application AU2019/900128. These figures are also included in the further 1 1 additional co-pending Australian provisional patent applications lodged on 29 April 2019 which are also related to and support this application. The aforementioned applications are incorporated herein, in their entirety, by reference and are listed below in table 1.

[01 19] Table 1 :

0120] Referring to now FIGs. 2a to 2e, there is shown a diagrammatic representation of each of the component parts of the system in accordance with an embodiment of the invention. The following descriptions and information add further matter to the original disclosure in the above-mentioned PCT applications to further particularise the features and embodiments described herein. To the extent that the additional description of features and integers contained herein contradicts any disclosure with respect to a feature or integer disclosed in the previous applications, it will be understood that, to the extent of the contradiction, the present application will be taken as being correct for the purpose of the inventions and embodiments disclosed and defined in the present application.

[0121] The following references serve as a summary of the information referred to within the embodiment detailed by Figures 2a-2g.

Information and set-up for embodiments described herein

[0122] Restaurant Set-up Rules (278): There are three basic embodiments disclosed herein, each of which utilise a different set of rules to set up a restaurant or any other space that can be reserved for any purpose. In all embodiments, the rules and constraints are arranged to permit the proper contextual relationships, relativities, utility of and flexible table and chair or equipment capacity to allow for effective differentiation, discrimination, yield management, dynamic pricing, revenue management, cost and operations management and the achievement of bespoke (configurable) individual quantitative and qualitative goals of a restaurant.

[0123] In the context of the specification and the embodiments and broader invention described herein, the terms "relationship”, "relativity”, "utility” and "contextual relationships” have specific meanings as related to equipment, furniture and other items which can be arranged within a space/venue and which can be ascribed specific attributes, constraints and by extension rules which utilise the attributes and constraints.

[0124] Firstly, the term "relativity” in the context of the specification refers to quantifiable attributes and constraints that describe quantifiable variables of a table, chair, furniture or equipment that in turn form the basis for a qualitative assessment of the table, chair and/or equipment. For example, the size and shape of the table, which are quantitative variables, may have an impact on a qualitative attribute of the table, such as the "class” of table. A first class table may be of a larger size and a first class chair may be more luxurious (larger chair). The attribute, however, is relative to other attributes and therefore in and of itself may not be determinative of the overall qualitative assessment of the table. For example, in addition to a physical attribute of the table, the location of the table relative to the space may also be determinative of the class of the table. For example, a table that is near a window and has a view may be considered a first class table, even if the physical attributes of the physical table do not necessarily match those of a "first class” table.

[0125] In other words, the term "relativity” refers to quantifiable attributes of furniture/equipment.

[0126] Correspondingly, the term "utility” refers to the overall utility that is derivable from the relative attributes and constraints that are associated with each item of furniture, including tables, chairs and other items of equipment.

[0127] Secondly, the term "relationship” refers to an association between two or more items, objects etc. For example, a relationship may be that a table is capable of being placed in a particular section. This is a constraint that defines a relationship between the table and the section.

[0128] Relationships may be one-to-one, or may be multiple, in that an object or item may have a relationship with a number of other objects or items. In other words, the relationships behave as a constraint with respect to how the two objects or items can interact. In the past specification, the reference to a "contextual relationship” or to "context”, refers to a relationship that acts as a constraint when specific conditions are met. For example, two tables may have a contextual relationship when placed adjacent to each other, or together, but have no such relationship when they are not placed adjacent to each other.

[0129] The rules and constraints stand in contrast to the prior art solutions, which are limited to a predetermined and unchanging limited solution set of non-descript tables and table combinations with simple minimum and maximum chair constraints. The three embodiments shown at (278) are "space”, "tables” and "tables, table combinations and shadow tables” described further below:

Space

[0130] The space embodiment uses a volumetric framework, and a restaurant floor plan or other file or data base to provide a series of restaurant allocation and organisation rules, including the relationships, relativities, utility and capacity of tables, chairs, other furniture and all other constraints within the restaurant.

Tables

[0131] Each table is ascribed an extensive set of characteristics and constraints, such that each table has a specific relativity, relationship, utility and capacity relative to each other table. Moreover, each chair is also ascribed a space relativity which is treated as a second aspect of the invention. This embodiment is similar to the space embodiment noted above. However, there is no utilisation of exact dimensions. In other words, less emphasis is placed on the spatial/dimensional aspect of the "space”, but the rules and algorithm still mimic the "space” embodiment above to achieve a similar outcome. This additional embodiment permits the addition and/or removal of tables from the total capacity of the restaurant.

[0132] The use of a list of tables and associated attributes as the underlying set of variables used to define the relativity, relationship, utility and capacity of each table and chair acts as a "common denominator” or as a benchmark for those relativities, relationships, utilities and capacities that provides that relativity. Hence, the use of a list of tables detailing the relationships, relativities, utilities and capacity between each other is an embodiment of the claimed invention. A further embodiment is any combination or permutation of relativities, relationships utilities and capacities of tables, chairs, and the restaurant rules that permits the differentiation, discrimination, yield management, dynamic pricing, revenue management, cost and operations management to achieve bespoke outcomes as disclosed within this and the other related applications.

Tables, Table Combinations and Shadow Tables

[0133] Through an extensive definition of the relationship, relativity, utility and capacity of each table and table combination with each other table and table combination to define a set of constraints rules can be applied to achieve desired outcomes. The development of rules provide granular differentiation and improve outcomes.

[0134] Within this embodiment is the concept of "shadow tables", defined as tables that do not physically exist in the total solution set of tables and table combinations as in the prior art. Alternatively stated, these "shadow tables” are not shown and do not exist on the floor plan within the prior art. These "shadow tables” are a list of permutations of tables that can be placed in an area, sub area, or space such that they can replace previously existing table or table combination within that area, sub area or space such that the allocation process permits the addition of or removal of tables and or chairs from the floor plan to provide a different and more optimised outcome than the prior art.

[0135] It will be understood that the permutations are not limited to a fixed number of tables, but can include the addition or removal of tables. For example, a permutation may include two separate tables T 1 and T2 and a combined table T 1 +T2 as per the prior art. However, in the present embodiment, there can also be provided a further table not existing in the prior art (T3) which permits the addition of a different combined table T 1 +T2+T3. In other words, the permutation allows for the incorporation of additional tables or removal of tables providing completely different configurations and numbers of table to vary the seating capacity, orientation, or any other aspect of the table combination in the sub area or area.

Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications, but more specifically with the following related patent applications:

1. Space - as described in Table 1

2. Widget - as described in T able 1

3. Menus - as described in Table 1

4. Yield Management- as described in Table 1

5. POS Transactions - as described in Table 1

6. Rosters - as described in Table 1

7. Operations - as described in Table 1

8. Ordering and Allocation Integration - as described in Table 1

9. Gaming - as described in Table 1

10. Exchange - as described in Table 1

1 1. Artificial Intelligence - as described in Table 1

12. POT Applications - as described in Table 1

[0136] The restaurant set-up rules shown at (278) in one embodiment also include set-up rules for all other spaces or purposes such as for the set-up and booking of functions and/or events with an area, subarea, private room or the entire restaurant. In a further embodiment the set-up rules referred to at (278) also refer to function spaces, event spaces, theatre, show and other spaces, such that a complete event can be enquired, modified, confirmed with or without part or full payment on-line and without the requirement of manual intervention by venue staff.

[0137] Embodiments are further described in related co-pending patent applications, with particular reference to the following related patent applications:

13. Functions - as described in Table 1

[0138] In a further embodiment, the restaurant set-up measurements provide information that permits a venue to detail the normal or standard set-up for a restaurant including the type, size and normal number of chairs that would be used for a table at a particular location. The restaurant set-up information can be used to determine if more than the standard number of chairs normally set for that table at that location is the physical maximum number of chairs that can be allocated to the table. In a further embodiment the restaurant set-up information can include information which indicates where one or more extra chairs can be placed on a table to increase the capacity of a table (which may also be determined by the relative location of the table in the venue).

[0139] For example where a table of two is placed up against a wall (and, hence the wall side is unusable) but, the other side can take an extra chair (as that chair will not be in a walk-way or interfere with any other table, the system is aware of the constraint and can add an extra chair to the table to increase its capacity if required during the booking allocation process.

[0140] In a further embodiment the information where the "change” of a table top from say one that is say 750mm by 700mm to one that is 800mm round to permit the seating of 4 people and not 2 (as per the original 750mm by 700mm) in the same location, the restaurant set-up rules can include information as to when a restaurant reaches a certain threshold or capacity, such that the rules and algorithms can be used to apply one or more of increasing the capacity to some or all the tables to the maximum number of chairs; or to the maximum table top size, or some other permutation within the information provided and available within the restaurant set up rules.

[0141] In another embodiment the restaurant set-up rules can be combined with any other information or any other permutation of the available information as described herein such that the restaurant allocation rules and algorithms can achieve any of the required quantitative and qualitative outcomes desired by the restaurant. For example, knowledge of the restaurant space, tables, table classes, table locations can be used in conjunction with the information available within a customer's history or CRM to allocate the customer's booking request instantaneously to their favourite or preferred table and preferred chair, or if the customer's favourite is not available to the customer's second preferred table and a preferred seating position, or failing that allocate the booking request to the next highest ranking class of table or table location as so on until that booking is allocated.

[0142] In one embodiment, the allocation of a booking can be associated with one physical space, physical item and the same booking can be transferred to another physical space or physical item such that a booking can comprise more that one "experience”. For example, a booking can be allocated to a bar table or bar stool for say 7pm to 7:30pm and then moved to the main dining room from 7:30pm to 9:30pm and then back to the bar at 9:30pm for a night cap. In a further embodiment, as this sequence of events can treated as a single booking during the booking allocation process then the system can maintain all financial details and information within that one booking and one account so that information does not have to be manually transferred, or manually reconciled, including any pre-payments within the system or the process by which it is integrated within any POS system.

[0143] In a further embodiment the restaurant set-up rules referred to above could be applied to other industries and businesses including, for example, hairdressers, gyms, libraries, accommodation, car rentals and aviation, or any business that requires the allocation of a physical space, physical item during a booking allocation process.

[0144] In a further embodiment, the framework, rules, methods, procedures and algorithms, of the current invention can also be applied to the booking of appointments where the primary purpose of the appointment is not the physical space or a physical item but the provision of services such as legal advice, accounting advice, doctors' appointments, hospital appointments etc.

[0145] Menus (280): Menus and the use of menus, rather than simply being a presentation of products available for purchase, are integrated into various aspects of the broader system These include channel and widget configuration to offer different menus, not only by time, but by other constraints such as class and specific table; availability and search by different courses and menus; the ability to require customers to commit to different menus and different courses at different times; the ability to recognise and identify different channels and customers to offer specific menus and tailored menus with different conditions such as duration times, prices, payment conditions etc.; eliminate the need for indicating allergy details on menus as alternate menu items would be displayed that did not include the "offending” allergic ingredients, similarly with dietary requirements; the use of alternate menu items not only makes the display to the customer more friendly and personal but permits proper stock decrementing and revenue/sales analysis; the requirement for a customer to select a menu and the number of courses so that more accurate duration times can be calculated or requiring customers to accept variable duration times based on the number of courses they have selected in conjunction with one or more other constraints (such as occasion, time of booking, group size, etc.) in determining the duration a booking would be permitted to occupy a table; the integration of menus into a "product tree” to permit the seamless integration of pre-orders into point of sales systems and the seamless integration of the reconciliation process of prepayments and deposits without the need to create separate pre-paid accounts within POS systems. These embodiments shown at (280).

Channel Configurability, Differentiation and Identification

[0146] In one embodiment, the claimed invention includes the ability of the operator to offer different menus with different dishes, different prices, different numbers of courses, different time durations and can be incorporated with different time durations and that specific information can be used and applied as part of the optimisation and booking allocation process.

Individual Identification

[0147] In one embodiment, the booking allocation system can identify the customer seeking to make a booking and present them with an individual menu or another specific menu and with the knowledge of the individual access that individuals CRM details and apply other additional constraints with respect to their menu selection such as a different duration time or a different duration time at their preferred table as part of the optimisation and booking process.

Required Selection of a Menus and or Courses

[0148] In one embodiment, a customer can be required to select a specific menu and or courses and with that required selection would be a set time such that the selection of the menu item and/o courses, a specific time duration could be applied to that selected menu and courses, incorporating other additional constraint information such as group size, occasion, day of the week, time of booking etc, to apply and or determine a duration time to be applied to that booking request and for that duration time to be used and applied as part of the booking allocation process. Alternate Menu Items

[0149] In one embodiment, a customer who has an allergy or dietary preference is only shown dishes that are compatible with their requirements, such that the menu item displayed does not include the inappropriate ingredients and simply shows the menu item as the dish will be presented when cooked.

Menu Systems Integration

[0150] In one embodiment the booking allocation system contains a menu building module and/or a separate menu building module includes a product tree structure for the development of menu items (products) that contain ingredients for stock decrementing as well as alternate menu items and ingredients where those menu items are modified for allergies or dietary requirements so that proper stock decrementation can occur. In one embodiment, each menu item by being linked to a product tree permits seamless integration with POS systems, kitchen and bar printing.

[0151] In a further embodiment pre-orders are linked to the booking and there is no need to manually re enter any pre-payments or pre-orders to a POS system as prepayment accounts as prepaid amounts can remain and be controlled within the ordering system and the booking allocation process such that an automatic reconciliation process can be applied when the booking arrives such that the manual transfer between accounts is not required.

[0152] Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent application, but more specifically with the following related patent applications which are incorporated herein by reference:

14. Menus - as described in Table 1

15. Widget - as described in T able 1

16. Yield management - as described in Table 1

17. POS Transactions - as described in Table 1

18. Rosters - as described in Table 1

19. Functions - as described in Table 1

20. Artificial Intelligence - as described in Table 1

21. PCT Applications - as described in Table 1

[0153] Dynamic Pricing and Dynamic Product and Service Promotional Offers (282): The embodiments described herein include the complete differentiation of the products, services and benefits that can be utilised in the differentiation of a product and service during a booking or appointment process; the use of the complete list of options available for the differentiation of the product or service to create a unique set of differentiated products and services as compared to competitors that can then be offered to their customers; the use of the differentiated products and services as part of a booking or appointment process.

[0154] Through these processes, a restaurant online booking process, or other booking or appointment process can be used and permits a restaurant or other business to apply proper and complete yield management including dynamic pricing, peak period pricing, higher pricing of tables with better or higher utility, etc., as compared to the current practice of only offering simple discounts during off-peak periods and incorrectly referring to this as yield management. In a further embodiment the use of and the ability of adding the tailoring of a dining or other bookable experience or appointment such that additional, related or the simple re-arrangement of the sequence of activities can offer greater satisfaction and personalisation to create a total revenue management process. These embodiments are shown at (282) and include the differentiation of products.

[0155] In one embodiment additional constraints have been developed and incorporated within the booking allocation system including through the use of the volumetric framework within one embodiment of the invention to permit a full and complete differentiation of the products and services offered by a restaurant including differentiation not considered or accounted for by the prior art including by location, by ambiance, by class, by privacy, by individual table, by ranking of each individual table, by menu, by number of courses, by occasion , by category of customer, by ranking of customer, by event, by conditions or constraints by time of booking, by payment terms, by additional supplementary items committed to, by channel and then these additional differentiation aspects being incorporated and used within the booking allocation process so that the a restaurant can configure these items to optimise their preferred quantitative and qualitative outcomes.

The yield management and revenue management of products

[0156] In one embodiment the additional product differentiation referred to above is utilised by the claimed invention to permit the control of capacity offered by differentiated products and services and then to apply yield management techniques which permit the incorporation of dynamic pricing, differential pricing by the differentiated items. In a further embodiment the incorporation of additional and supplementary items including the ability to tailor the sequence of events within a booking or appointment (as one simple example of this embodiment is the ability to permit customers to design their own sharing platters and eliminating the need have an entree and/or a main course in a traditionally three course a la carte restaurant.

Promotions

[0157] In one embodiment the incorporation of configurable promotions, configurable back fill promotions, and interactive tactical upsell promotions to people hesitating during the booking process or to people who have already booked or to encouraging people to pre-order or while at the restaurant in-service ordering process.

Sale of specific tables and packages, auction of specific tables and packages and the sale of specific tables or packages through a restaurant table exchange.

[0158] In one embodiment the incorporation the sale of specific tables or packages by individual sale by the restaurant or through an "exchange”, "website” or other process that permits the resale of the tables and packages.

Butler and Concierge Service

[0159] In one embodiment there is provided a module that allows the incorporation of additional third-party or ancillary items to personalise the restaurant experience, change the order of service, provide bespoke offerings and experiences not normally or traditionally provided by restaurants, upsell during the booking and ordering process unusual items so that a restaurant can create greater differentiation to competitors. These experiences are not limited to the experiences normally provided by restaurants but targeted at experiences and offering that are outside existing norms to include anything desired by a customer and within the level of acceptability of the restaurant. In a further embodiment the additional information, spending and revenue for a booking can be used within the booking allocation process to provide higher spending, higher revenue, higher contribution or other classification of customers, or more specific experience requirements in the booking allocation process of the claimed invention. In one embodiment this can result in a higher spending customer being given a better table or being provided with an upgrade to a better class of table, extended duration or other benefits or preferential treatment.

[0160] Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications, but more specifically with the following related patent applications which are incorporated herein by reference:

22. Widget - as described in T able 1

23. Yield management - as described in T able 1

24. Space - as described in Table 1

25. Exchange - as described in Table 1

26. Gaming - as described in Table 1

27. Rosters - as described in Table 1

28. POS Transactions - as described in Table 1

29. Artificial Intelligence - as described in Table 1

[0161] Special Events Scheduled by Venue (284): In some embodiments, there is provided a process by which special events may be included by utilising the forecasting and planning modules to create and classify specific events as "one off” events so that they can be properly understood and interpreted by the forecasting modules and therefore also correctly classified and utilised as input data by the artificial intelligence module. More specifically these embodiments are shown at (284).

[0162] Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications, but more specifically with the following related patent applications which are incorporated herein by reference:

30. Yield Management - as described in Table 1

31. Rosters - as described in Table 1

32. Artificial Intelligence - as described in Table 1

[0163] CRM (286): In the embodiments described herein, the CRM is not merely a repository of information and historical data base, as is the case with all prior art, but is a system that contains constraints and information that can be accessed and utilised as part of the booking allocation process. These embodiments include the allocation of a Super VIP and or VIP to their favourite or preferred table automatically during the booking allocation process and not through a manual allocation process undertaken after the booking is accepted, as is the case with the prior art.

[0164] Further, in additional embodiments the restaurant or the venue can provide additional information and constraints as to how this CRM information should be utilised, how it should be enhanced, modified or applied during the booking allocation process, including, the addition of complementary items being added to their "running sheet” or "order of service” for their booking, for example, a free glass of wine, or an extended booking duration time, that no deposit or prepayment is required unlike other bookings or other benefit or information.

[0165] In a further embodiment, the booking allocation process can automatically embellish the booking allocation process by permitting differentiation between customers and better tailoring and personalise a person's restaurant experience. More specifically these embodiments are shown at (286). Embodiments and aspects of this application are supported by, and with further details provided within all the additional related patent applications:

[0166] External Websites (288): In some embodiments, external websites are utilised as not merely a source of information or reference data but as data and information that can be accessed and utilised in the booking allocation process. Embodiments of the allocation methodology, processes and rules can include, a person's social media influence rating, a person's occupation, or other distinguishing feature as inputs to determine the constraints to be utilised by the booking allocation process. More specifically these embodiments are shown at (288)

[0167] Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications.

Forecasting and Predictive Model (290): The level of detail used by the embodiments in the differentiation of the product or service, yield management, dynamic pricing, revenue management, the detail within a restaurant the personalisation of services etc., allow the forecasting and predictive model of the embodiment to be extremely sensitive and therefore results in far more accurate forecasts and predictions as there is greater monitoring ability as well as "levers” to make changes to achieve desired outcomes.

[0168] Specifically in one embodiment the forecasting and predictive model directly accesses the extensive constraints, variables, inputs, historical outcomes and trends, allocation rules, as well as planned events, third party websites, and use that information to develop its forecasts and then to monitor activity against those forecasts by the allocation methods, procedures, algorithms and allocation rules in the allocation of bookings to a space, a table, a table combination, chair or other item to achieve better forecasts and to make changes to the constraints so as to achieve even better outcomes. Embodiments also include the forecasts of functions and events as well as the monitoring of those events and the recommendation of changes or the making of changes to the applied constraints; booking capacities; booking classes; staffing; rosters; resource requirements; operational requirements; maintenance requirements, etc. More specifically these embodiments are shown at (290). Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications, but more specifically with the following patent applications:

33. Yield management - as described in Table 1

34. Rosters - as described in Table 1

35. Artificial Intelligence - as described in Table 1

36. Functions - as described in Table 1

37. Operations - as described in Table 1 38. PCT applications - as described in Table 1

[0169] Suppliers (292): Orders; Deliveries; Constraints, details etc. (292) The embodiment includes the ability to link a supplier to the booking allocation process such that the suppliers items can be offered within the booking process, the selection of what a person has chosen can then be added to the booking allocation process and algorithm and then an order be placed with the supplier when a person confirms their booking to create a completely integrated process. Embodiments of this process are supported by, and with further details provided within the additional related patent applications.

[0170] Database of Booking Requests (294): In one embodiment, the historical booking requests are directly accessed by the booking allocation methods, procedures, algorithms and allocation rules for the allocation of bookings to a space, a table, a table combination, chair, other item or for the allocation or creation of an appointment.

[0171] In a further embodiment additional information can be added to the data base of historical booking requests, their behaviour at the restaurant, the allocation provided to them in previous booking requests, overall demand for a time or a service that could not be satisfied and the timing and booking profile of those bookings, etc., (294) Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications.

[0172] Optimisation Quantitative and Qualitative Strategic Rules and Outcomes (296):

Embodiments of the allocations, methods, procedures, algorithms and allocation rules include the creation of specific rules to undertake specific outcomes which can be selected by a venue to create specific outcomes dynamically (the prior art cannot dynamically allocate bookings and relies on a predetermined single priority table and table combination list to allocate bookings).

[0173] The specific dynamic allocation can also be combined in different sequences combinations by different time periods, different services, etc., so as to create bespoke outcomes for the benefit of individual venues to better meet their targeted goals and the requirements of their customers. Embodiments with respect to this aspect are not limited to the following examples, detailed; Floor Space Optimisation Algorithm; Time Related Optimisation Algorithm; Event Related Optimisation Algorithm; Strategy Related Optimisation Algorithm; Third-Party Optimisation Algorithm; Pre-service Optimisation Algorithm; In-service Optimisation Algorithm; Self- Seating Optimisation Algorithm (296). Embodiments and aspects of this application are supported by, and with further details provided within all the additional patent applications:

39. PCT applications - as described in Table 1

[0174] Resource Parameters (298): The resource parameters include; Venue set-up times, bar set-up times, hosting requirements, kitchen set-up times, roster structures and frameworks including staff metrics such as customers that each staff member can cater for, minimum staffing levels, amount of food that each chef or food station can produce, minimum hours, pay rates, broken chairs, broken tables, equipment out of service etc. (298). Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications, but more specifically with the following patent applications:

40. Rosters - as described in Table 1 41. Operations - as described in Table 1

42. Artificial Intelligence - as described in Table 1

[0175] Reporting (231): Performance analysis; Customer satisfaction; Deliverables; Labour Analysis; Actual v. Predicted etc. (231) Reporting relates to the additional constraints possible within the claimed invention and the analysis of those constraints and their outcomes. In one embodiment, reporting relates to the use of that analysis to better forecast and utilise that information to create a feedback loop and information to the artificial intelligence module so that it can continually learn and improve this processes and outcomes. This application is supported by, and with further details provided within the additional related patent applications, but more specifically with the following patent applications:

43. Yield Management - as described in Table 1

44. Artificial Intelligence - as described in Table 1

[0176] Database Historical Information (233): Database historical information relate to information not currently available or used by the prior art. This information includes: booking duration times by courses, by individual table, by class of table, by occasion etc.; the time bookings made - booking time; classes of bookings; spend by booking types; yield management outcomes; revenue efficiency; walk-in promotions; etc. and wherein this information can be accessed and utilised within the booking allocation process and all other modules including forecasting and artificial intelligence (233) this application is supported by, and with further details provided within the additional related patent applications, but more specifically with the following patent applications, but more specifically with the following patent applications:

45. Yield - as described in Table 1

46. Artificial Intelligence - as described in Table 1

[0177] External Websites (235): External websites including weather information relate to information that is accessed and used by the current invention within it booking allocation process, forecasting and artificial intelligence. Embodiments relating to the use of information from external websites within the claimed are supported by, and with further details provided within the additional related patent applications.

[0178] Printed Operational In-Service Run Sheets (237): Printed operational and in-service run sheets relate to information that includes the results of the autonomous booking allocation process, the autonomous chair allocation or selection process etc., and is supported by, and with further details provided within the additional related patent applications.

[0179] Operational Requirements and Planning (239): Operational requirements and planning within this application refer to staffing levels ; rosters, including roster frameworks and standard rosters, roster creation, staff allocation to rosters, adjustments to rosters based on bookings received as compared to bookings forecasted; start/finish times, including pre-times, set-up times, closing procedures and times; orders; delivery schedules; maintenance planning; equipment replacement; occupational health and safety; procedure and policy monitoring; etc. (239). Embodiments within this aspect of the application are supported by, and with further details provided within the additional related patent applications, but more specifically:

47. Rostering - as described in Table 1 48. Operations - as described in Table 1

49. POS Transactions - as described in Table 1

[0180] Point of Sale Integration (241): In one aspect, embodiments of the point of sale (POS) integration relate to transactional aspects. These embodiments include the "real time” dynamic floor plan created by the claimed invention being integrated into POS systems with or without the application of the Cartesian "volumetric framework” (which in one embodiment includes more than a three dimensional volumetric framework, as it can include more than three axis) within the integrated POS systems such that the "real time dynamic floor plan” including details of the table, the chairs and booking details by chair, replaces the existing static floor plan within the prior art POS systems. The benefits of this dynamic real time floor plan ensure that restaurant tables are always shown as how they appear in real life, that the tables have the correct table numbers, that the tables show the correct chair set up and all pre-orders are shown on the correct table and the correct chair numbers that change in accordance with the customers request and the booking allocation process.

[0181] In a further embodiment any pre-payments, part payments or deposits including food, beverage and other items are transferred and referenced in detail by the booking system or ordering system, to the POS system on arrival and eliminate the need for the opening of pre-paid accounts within POS systems or other accounting systems which then require manual transfer of amounts between accounts etc. and a subsequent manual reconciliation process. Embodiments, therefore include integrations for dynamic floor plans; table and chair seating plans, allocations and details; orders; payments; deposits; sale items; Etc.; CRM detail integration as it related to the booking allocation and ordering processes of the current invention (241) Embodiments of this application are supported by, and with further details provided within the additional related patent applications:

50. POS Transactions - as described in Table 1

51. Space - as described in Table 1

52. Menus - as described in Table 1

[0182] In a further embodiment, the booking allocation system incorporates a transaction system that replaces and enhances the functionality of a traditional P.O.S. system. A transaction system is far more efficient and renders a traditional P.O.S. system obsolete, as most transactions do not occur at one point (hence the current name and terminology of Point-of-Sale systems) but the transactions occur at multiple points and the traditional P.O.S. systems no longer represent an efficient core revenue or accounting system.

[0183] In a further aspect the current invention with respect to POS systems relates to the integration and use of POS systems with a booking allocation system such that a person making an order at a counter can be allocated a table and or seat within the venue at the same time with or without a stipulated duration time. In another embodiment a person making an order at an ordering kiosk within a venue can be allocated a table or a seat at the venue with or without a stipulated duration time. In another embodiment where a person is allowed to enter a venue and choose a table or seat of their choice and then order, the embodiment through the integration of a booking system can advise the person how long they can occupy or use the table or chair. In another embodiment through the integration of a seating kiosk (self-seating kiosk), an appointment app a person can be allocated a table including duration permitted. In other embodiments the application of the invention to gyms, hairdressers and even to the appointment setting processes of lawyers etc. Embodiments of this application are supported by, and with further details provided within the additional related patent applications and more specifically:

53. Ordering and Allocation Integration - as described in Table 1

[0184] Stock Control, Ordering and Purchasing (243): In one aspect, embodiments of stock control relate the creation of alternate menu item for allergies and dietary requirements of the claimed invention. In one aspect the ordering and purchasing of the claimed invention relate to the creation offering for sale items not traditionally associated with restaurants and the automation of the transactional aspects so that no manual intervention or work is required. This includes the ordering of additional tables and chairs if the allocation model determines the requirement for additional furniture. Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications:

1. Space - as described in Table 1

2. Rosters - as described in Table 1

3. POS Transactions - as described in Table 1

[0185] Home Delivery and Takeaway Integrations for Production and Time Scheduling (245): In one aspect, embodiments of the home delivery, takeaway integrations for production and time scheduling include the monitoring of time durations, and the autonomous turning on, turning off, or provision of time information concerning food production times, yield management, dynamic pricing and point of sale (POS) integration of the transactional aspects. Embodiments and aspects of this application are supported by, and with further details provided within all the relevant patent applications.

[0186] Payment Rules (247): In one aspect, embodiments of payments include the ability to have different payment rules for different menus, different courses, different booking times different prices by booking channel, etc, so that a completely dynamic pricing system and payment constraints are created. Embodiments include; payment decision trees; prepayment and payment constraints, different channel constraints, product differentiation, dynamic pricing etc. (247) Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications.

[0187] Artificial Intelligence (251): In one aspect, embodiments of artificial intelligence include the complete automation of the entire restaurant process from a systems perspective which is beyond the ability and scope of prior art systems. Including data mining, advanced analytics, modelling and predictive analysis to automatically amend constraints. (251) Embodiments and aspects of this application are supported by, and with further details provided within additional patent applications and more specifically by the following applications:

2. Artificial Intelligence - as described in Table 1

3. Yield Management - as described in Table 1

[0188] Alternate Payment Systems (253): In one aspect, embodiments of the alternate payment systems is the ability of a venue to offer alternate payment such as a progress payment option, not available within the prior art. This becomes a viable option within the claimed invention as the autonomous reconciliation of part payments means that the manual reconciliation processes and labour burdens of the prior art are no longer cost prohibitive. Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications.

[0189] Referring to FIGs. 2a to 2e, the following references are provided as a summary of one embodiment of the information referred to within the flow chart as "Claimed Invention” 276, "Intuitive booking allocation super highway” (297) and booking allocation information 2026, utilising the information and constraints identified and developed 1 a to 1 v above:

[0190] Processes, methods and algorithms within the current invention

[0191] User, in one embodiment (255)

[0192] Various Configurable Access Channels, such that the offers, products services etc., can be completely different by channel (257)

[0193] Configurable User/User Interfaces: Restaurant booking widget, function booking widget, self seating kiosk, self-seating app, restaurant booking app, menu pre-ordering app/widget, promotional apps/widgets, booking form, and integrated systems such as POS systems. (259)

[0194] User requirements used in the Booking Allocation: Buy a specific table, request a specific table, request an extended dining duration, flowers, chocolates, card, entertainment, gift, different order of service, personal waiter, specific personal waiter, budget, occasion etc. (261 )

[0195] Strategic Control of Capacity, Product and Services for Booking Allocations: Strategic capacity availability by Area, Sub-area, Section and Class. Strategic Product and Service Availability by Menu, by Courses, by Variable Time Durations to meet revenue and yield management targets. (263)

[0196] Booking Allocation for the Optimisation of Space: (Sale of specific tables with guaranteed allocation, Super VIP guaranteed seating, VIP prioritised seating, Optimisation of remaining table allocations to Area, Sub-areas, Sections and Classes based on venue strategy, the introduction of additional tables and/or chairs, the removal of tables and/or chairs, the interchange of tables, the interchange of table tops, etc. (265) [0197] Payment/Deposit Confirmation (267)

[0198] Butler Service: Ordering of 3 ^rd Party Services/Products, the changing of the order of service, the introduction of items not traditionally offered by restaurants. (271 )

[0199] Time-Related Booking Optimisation: At a predetermined time (e.g.. 1 hr before service), reallocation of all bookings to offer the best tables to the highest ranking, non-guaranteed table-allocated customers (Musical Chairs) (269)

[0200] Event-Related Booking Optimisation: At the occurrence of an event, e.g.: Rain, reallocation of outdoor bookings to tables in undercover Areas, Sub-areas, Sections and Classes. Such a reallocation can be automatic through a linking of the booking process to a third party weather site or through a re-allocation allocation process that has been programmed and can identify the weather affected tables. (273)

[0201] Capacity-Related Booking Optimisation: An event that a particular class of table is at full capacity, a determination if demand for other classes of tables is such that they can be reduced and additional tables offered for the class in demand. (275) [0202] Strategy-Related Booking Optimisation: An ambience re-allocation: if restaurant is not expected to fill up or other parameters apply. (277)

[0203] Third Party Information Booking Optimisation: Theatre information, website information which may have an impact on capacity decision. E.g. allocating bookings to a minimum space in anticipation of a full theatre next door. (279)

[0204] Pre-service Booking Allocation Optimisation: A final optimisation before service taking all the above factors into account, as well as opening up capacity for walk-ins, if such capacity had been previously excluded from the allocated capacity. Creation of run sheets and service notes for staff. If a venue selects self seating option, floor plans and seating locations as they would appear at time of arrival of each booking are sent to each customer. (281)

[0205] Cockpit Dashboard: Dynamic Floor Plan; Time-based floor plan, the booking system having an inbuilt POS system, and the ability to take orders, receive orders, reconcile accounts, etc. including integration to other systems including other POS systems to create a completely integrated dynamic real-time systems environment (283)

[0206] In-service Booking Allocation Optimisation: Optimisation can be based on any combination or permutation of the above optimisation algorithms or different algorithms which can only use tables located within the restaurant and/or without moving pre-allocated bookings and/or allocating bookings based on space optimisation or other dimension such as allocation to the best table. (285)

[0207] Self-Seating Kiosk (Booking Allocation): Applicable for venues that have selected the self seating option. The kiosk can provide information on the seating location of confirmed bookings as well as the ability of accepting new walk in bookings as well as providing direction such that a host or someone to seat guests is not required. (287)

[0208] Autonomous Restaurant and Complete Integration: Fully integrated information system including table and position sensors. (289)

[0209] Point of Sale System: A fully integrated with dynamic real-time table plan layout with orders sent to kitchen and bar as appropriate and automatic reconciliations. (291)

[0210] Payments: Fully integrated with links to original booking including part payments by table, customer and position number. (293)

[0211] Accounting System: The complete integration of the booking systems with all accounting and transaction systems to produce all reports including revenue; P&L statements such that manual input is minimal (295). Including the implementation of a volumetric framework within the various accounting systems, for example the use of the volumetric framework for per-ordering, the POS system and other accounting systems.

[0212] Referring to FIGs. 2f to 2g, the following references are provided as a summary of the information referred to within the flow chart as "Prior Art” 223, "Reactive Allocation” 2030 with booking allocation information 2032:

[0213] Prior Art (223)

[0214] User (2000) [0215] Access Channels (2002)

[0216] User/User Interfaces: Restaurant Booking Widget, Booking Form. (2004)

[0217] User requirements used in the Booking Allocation: (Prior Art) Date, time, meal period, pax (2006)

[0218] Strategic Control of Capacity, Product and Services for Booking Allocations: (Prior Art) Capacity and Max Group Size by booking time interval for a standard time duration for the whole service or by group size (2008).

[0219] Payment/Deposit Confirmation (2010)

[0220] Allocation of Booking Request: (Prior Art) Use of a prioritised list of tables and table combinations to allocate bookings. Prior Art process finishes with this step. (2012)

[0221] Dashboard: Static Floor Plan (2014)

[0222] Payments (2016)

[0223] Referring to FIG. 2f and FIG. 2g, the following references are provided as a summary of the information referred to within the flow chart as "Prior Art” 223, "Booking Allocation Information” 2032:

[0224] Restaurant Set-up Rules: Open/closed; Meal periods; Floor Plan (not to scale); Seat block-outs; Rooms, Areas, Bars; Tables and table combinations prioritised list; Standard booking time duration or by group size (2020)

[0225] Promotional Offers: Discount by time interval (2022)

[0226] Database: List of unused tables and table combinations (2024)

[0227] It will be understood that the description with regard to FIG. 2a to FIG. 2e are not to be taken as an exhaustive description of the invention or embodiments, but rather a summary of an embodiment, to enable a person skilled in the art to gain an understanding of the broader inventive concept. It will be understood that the preceding and subsequent Figures describe the specific embodiments and aspects as are claimed herein in more detail and provide examples of reduction to practice. Moreover, the description with regard to FIG. 2a to FIG. 2e are not to be taken as evidence that the inventive concept is "abstract” or the mere implementation of an abstract concept. Rather, the description of FIG. 2a to FIG. 2e is intended as a primer or high-level view of the system as a whole, to enable the person skilled in the art to better understand the inventive concept.

[0228] It will be understood that the description with regard to FIGs. 2a to 2e are not prescriptive in that all herein features, steps and algorithms are required to be taken or taken in the order that they are shown the description or that they form a definitive list of features, steps and algorithms that comprise the invention. The purpose of FIGs 2a to 2e and the comparison to a prior art system shown in FIG. 2f and 2g is to highlight the inventive concept of using the knowledge of space, objects and their relativity and utility data combined with a series of algorithms optimise a space based on the strategic parameters or constraints of a venue.

[0229] Moreover, there is described below a series of algorithms, which for convenience, are numbered. Flowever, it will be understood that each algorithm is independent, and the numbering is not reflective of any specific order in which the algorithms are to be applied. The embodiment may apply one or more algorithms dependent on constraint information and the application can be separate to other algorithms, in conjunction with one or more other algorithms, in different sequences with the one or more other algorithms to achieve the desired outcomes for the booking time period in question. The application, sequence, mixture of the algorithms can be configured by each individual restaurant in accordance with their individual strategies and required outcomes.

[0230] The first embodiment referred to as the First Algorithm is termed the "Strategic Capacity Control" algorithm, module 263, which makes an assessment of requests based on availability with reference to allocations by space, subspace, class, by time, allowing capacity for walk-ins, by menu, by course, etc.

[0231] The second embodiment referred to as the Second Algorithm is termed the "Optimisation of Space Outcomes” module 265, and is relevant to guaranteed table allocations. The algorithm which is an iterative seating optimisation algorithm which is arranged to allocate seating first to Super VIP's and guaranteed seating allocations then based on availability by VIP, group size, etc., to optimise the allocation and position of tables. This algorithm is arranged to optimise floor space efficiency around guaranteed table allocations.

[0232] The third embodiment referred to as the Third Algorithm is termed the "Time Related Optimisation" algorithm, module 269, which is best described by an example. For example, one hour before service, if it is decided that no new tables should be added, all bookings are reviewed, and, if there are two different bookings at 6pm and one booking is from a regular customer and one is from a first time visitor, the regular customer is allocated to the better table and the first time customer is allocated to the other table.

[0233] The fourth embodiment referred to as the Fourth Algorithm is termed the "Event Related Optimisation” algorithm, module, 273, which is triggered or undertaken by the occurrence of an event. For example, if it rains, the algorithm would re-allocate part or all of the bookings to outside tables to inside tables as all or part of the outside tables may be rendered unusable.

[0234] The fifth embodiment referred to as the Fifth Algorithm is termed the "Full Capacity Optimisation”, module, 275, which is triggered or undertaken when one space, subspace, or class is full. For example, if a specific class within the restaurant was full the algorithm would evaluate if demand for the other classes for that service had availability. If other classes had availability then it would determine if those tables would be filled and what the revenue and contribution would be and if it then determined that it would be best to increase the size of the class that was full and reduce the seating availability in another class it could do so and increase the capacity within the class for which the booking request was received and allocate the booking request against one of the additional tables created in the expanded class.

[0235] The sixth embodiment referred to as the Sixth Algorithm is termed the "Strategy and Ambiance Optimisation", module 277, algorithm. All bookings are reviewed, and if it is found that the restaurant will not be at capacity, the bookings are spread around the restaurant so that a better ambience is achieved within the restaurant. For example, if a restaurant only has two bookings for a Monday evening, the Second Algorithm may have sat both bookings next to each other in a back corner of the restaurant as this was the most efficient use of the restaurant space. This algorithm recognises that this arrangement is not an ideal seating arrangement for an empty restaurant and allocates the two bookings in this example to give both bookings the two best available tables. [0236] The seventh embodiment referred to as the Seventh Algorithm is termed the "Third Party Information Optimisation”, module 279 algorithm. For example, the optimisation algorithm could access third party information such as the bookings for the local theatre and the start and finish times of a show to determine capacity allotments and constraints. Further, it can determine not to offer discounts or promotions at 9pm as the theatre will finish and it expects numerous walk-in customers.

[0237] The eighth embodiment referred to as the Eighth Algorithm is termed the "Pre-Service Quantitative and Qualitative” algorithm, module 281. This is the final optimisation algorithm before a service and can be a combination of one or more of the previous algorithms at the discretion of the restaurant manager. It is run at a predetermined time before service and is also used to create run sheets and provide information to restaurant staff as well as provide final seating plans and arrangements for self-seating customers. As another example, as a restaurant can be split into different classes part of a restaurant can offer self-seating and part of a restaurant can offer full table service.

[0238] The ninth embodiment referred to as the Ninth Algorithm is termed the "In-service Allocations without additional tables or changing existing table allocations" algorithm, module 285. This algorithm is executed after service begins and new bookings are limited to the use of only tables physically available within the restaurant. The in-service optimisation process uses the In-service Allocations algorithm to provide a limited optimisation process which limits the allocation process by means of additional constraints to optimise request allocation process with minimise the disturbance to current patrons.

[0239] The Ninth Algorithm is not mandatory as the eighth algorithm or any other algorithm or a combination thereof could continue to be used without the need to unseat existing bookings whilst maintaining the ability to add or remove one or more tables. Further, additional algorithms or variations of the booking algorithms could be added to provide additional and different allocation outcomes and as a consequence provide additional tools for both the customer and the restaurant to achieve their preferred objectives and customer service standards.

[0240] A co-pending PCT application filed contemporaneously with this application in the name of Grand Performance Online Pty Ltd and entitled "A COMPUTER-ENABLED METHOD, SYSTEM AND COMPUTER PROGRAM FOR PROVIDING AN INTUITIVE USER INTERFACE ARRANGED TO CREATE A DYNAMIC FLOOR PLAN UTILISABLE BY AN ALLOCATION ALGORITHM TO PERFORM THE TASK OF ALLOCATING A SPACE, FURNITURE, EQUIPMENT OR SERVICE” includes a number of annexures number 1 to 11, which are herein incorporated by reference.

[0241] In Annexures 1 to 11 details are provided of the measures and metrics used by the prior art and by the embodiments and broader invention described herein which are significantly greater and beyond the scope, functionality, integration and ability of the prior art. Specifically the prior art measures and metrics are contained within Annexure 1 while embodiments of the measures and metrics utilised within our claimed invention are detailed in annexures 2 to 11. The prior art is extremely limited in the ability to analyse and report as the prior art firstly does not appreciate and recognise the importance of additional measures and metrics for reporting, forecasting and artificial intelligence. Secondly the prior art does not have the structures, methods and procedures to be capable of calculating the measures and metric calculations to achieve better outcomes. Two such measures are "revenue yield” and "efficiency”.

[0242] Referring to Annexures 1 to 1 1 the following references are provided as a summary of the measures and metrics detailed within the Annexures:

[0243] Annexure 1 Prior art measures and metrics: This annexure highlights the prior art metrics and measures are limited to a limited number of practical and theoretical measures that are used and taught within universities to measure restaurant performance and measurements.

[0244] Annexure 2 Floor plan guidelines, rankings, and space efficiency measures for the claimed invention: This annexure provides variables related to spatial guidelines and measures, such as; floor space allocation, dining, bar and customer spaces, table top guide, fixed and flexible seating areas including walkways, chair size guide, spacing between tables, waiter stations guide, bar space and bar stools guide, area per person size guide, area per person size guide, area, sub-area, class, section, and table and stool rankings, table analysis, tables for sale, tables for auction, tables dedicated to specific channels, location analysis and floor space efficiency.

[0245] Annexure 3 Capacity utilisation and revenue efficiency measures for the claimed invention: This annexure provides variables related to capacity, utilisation and revenue efficiency measures, which include the concept of dynamic floor plans which is a concept of the claimed invention where by additional tables and chairs can be added to a floor plan during the booking allocation process and these additional tables and chairs need to be included within these performance measures and metrics. These measures and metrics include; revenue yield, seat capacity (production) and utilisation, table capacity (production) and utilisation, units of measure of capacity, physical constraints, hours open, service periods open, service hours open, back of house (kitchen) hours, front of house (dining room) hours, revenue measures.

[0246] Annexure 4 Booking Analysis for the claimed invention: This annexure provides variables related to booking analysis, such as; Booking requests allocated analysis, booking profile analysis, booking requests rejected analysis, source of booking analysis.

[0247] Annexure 5 Duration Time Analysis for the claimed invention: This annexure provides variables related to duration time analysis, such as; duration times by booking size, by occasion, by menu selected, by courses selected, by booking time, by booking day, by customer type, by requests for extended durations, by duration times extended, by table, by class.

[0248] Annexure 6 Product Mix Analysis for the claimed invention: This annexure provides variables related to a product mix analysis, for areas, subareas, classes, sections, tables, distribution and channel for items such as; food: by time, by service, by day, by server, by channel; Beverage: by time, by service, by day, by server, by channel; Supplementary items: by time, by service, by day, by server, by channel.

[0249] Annexure 7 Revenue and Customer Performance Analysis for the claimed invention: This annexure provides variables related to revenue and customer performance analysis, such as; detailed revenue analysis, detailed customer analysis detailed customer ranking and detailed channel analysis. [0250] Annexure 8 Staff and Roster Parameters for the claimed invention: This annexure provides variables related to staff ratios, requirements, hours, set-up times for the creation of forecasted rosters, performance measurements against those rosters and the use of artificial intelligence to update and maintain those performance measures and use the information to create further improvements to those rosters.

[0251] Annexure 9 Profit and Loss Layout (a la carte) structure and definitions for variable costs and fixed costs and contribution analysis for the claimed invention: This annexure variables related to the structure and the relationship between revenue and costs and how those revenues and costs can be determined and understood from a contribution perspective and marginal cost perspective such that decisions and actions taken can be measured in terms of cash generation, contribution and performance for reporting, forecasting as well as for feedback in the artificial intelligence loop.

[0252] Annexure 10 Break Even Analysis, Contribution Margins and Variable Pricing

Analysis for the claimed invention: This annexure provides variables related to the specific analysis of the financial performance of the claimed invention, the monitoring of the financial performance, for forecasting and for the use of these measures and metrics for learning and artificial intelligence within the framework of the other annexures detailed within this embodiment. This analysis includes; break even analysis utilising the defined profit and loss statement within annexure 9 and other cost performance and analysis measures.

[0253] Annexure 11 Supplier Pricing Comparisons and Monitoring for the claimed invention: This annexure provides variables related to requesting comparative pricing, supplier performance and reliability and the monitoring of their performance for recommendations and the automatic placement of orders.

[0254] Those skilled in the art can appreciate that the structure of the claimed invention, and more specifically with the measures and metrics referred to within the annexures, that these measures and metrics can easily be converted or adopted within the other industries referred to and to which this claimed invention can be applied to.

[0255] Referring to Figure 3a there is shown a prior art Point Of Sale (POS) system. A conventional POS system includes a product tree 300 which includes products that may be grouped in any arbitrary fashion as required by the user. For example, there may be groups and sub-groups of products, combinations of products, etc. A set of static "keys” is developed at 302 for display on an interface on a POS terminal. In practice, the keys are buttons which the operator can press to indicate that a product has been ordered. For example, one key may be "Entree: Scallops”, which, when selected, adds the product and the price of the scallops dish to the running total of an order. The static keys are assigned to a "till”, namely a hardware point of sale device, at 304. Where changes are required to the static key map, a new product and key map is developed at step 308 and the developed product and key map is "posted" to the till 306. In other words, the key maps on the till are static and the till has no ability to change products and/or items "on the fly”. Rather, the till is wholly dependent on what is "posted” to it at any given moment in time.

[0256] Referring to Figure 3b there is shown a prior art two-dimensional mapping of products and prices to a POS system. This Figure is analogous to Figure 3a, in that products and prices as a two dimensional construct 310 are associated with a static key map 312 before being posted to a till 314. There may also be provided hand-held device which offer a similar functionality to the till, namely the ability of an operator to select products from a static key map.

[0257] Referring to Figure 3c there is shown a volumetric framework as applied to a series of products and prices over time. The volumetric framework 318 is three dimensional. This allows products and prices to vary over time. This further allows the framework 318 to interact with a plurality of menus 320, such that the menus can be associated with each table, wherein the volumetric framework 322 includes a space volumetric framework 324 where the space volumetric framework is associated with the location and size of tables 328, and the volumetric framework of products is overlaid in a posting calendar 326 such that it is integrated with the reporting calendar 330. This in turn allows all devices to show a live, dynamically changeable (over time) menu 334. In other words, the menu, prices, POS system and all other components of the booking and management system autonomously change menu items, prices, etc., based on time, table selected, customer, and any other relevant constraints. This is further described with reference to Figure 3d.

[0258] Referring to Figure 3d there is shown a Volume Point of Sale System. As described previously, the product tree 300, meu sets 338 and menu sets as associated with the volumetric framework 340 are posted to a volumetric framework 342 within a posting calendar 344 which varies over time 346, and integrates with a user defined calendar 348 and therefore with a till 352. This in turn allows all devices to show a live, dynamically changeable (over time) menu. In other words, the menu, prices, POS system and all other components of the booking and management system autonomously change menu items, prices, etc., based on time, table selected, customer, and any other relevant constraints.

[0259] Referring to Figure 4a and 4b, the user interface may access manually estimated (estimated and entered by the operator) or predicted (by the predictive module) times required per course for a number of patrons. Figure 4d shows the setup of four menus: a la carte 406, limited a la carte 408, alternate drop 410 and post-theatre 412 via the add menu button 400.

[0260] Referring now to Figure 4b-4e, there is shown four courses set up for the menu called a la carte (figure 4a, 406): 1 course 414, 2 courses 416, 3 courses 418 and any courses 420. The user can input duration constraints by number of patrons and by course for each menu being set up, including minimum number of patrons constraints 422, maximum number of patrons constraints 424, standard duration for an input range of patron group size 426, the VIP duration for an input range of patron group size 428, and the SVIP duration for an input range of patron group size 430.

[0261] In one embodiment, the user interface groups all booking requests in accordance with the seating periods determined for a service as created and shown in FIG. 4f, including the setting of a table reset time at 442.

[0262] The automation of the menu selection allows for larger bookings to be appropriately and automatically allocated without disrupting the normal service of the venue by reducing the time and effort required to cater to large parties of patrons. As such, the embodiment addresses one of the problems identified in the prior art by providing a complete restaurant management system that transparently and autonomously manages the relationship with the client from the beginning of the booking to payment and end of service [0263] Referring to Figure 4g, in determining which menu to provide to the remote user, the user interface, may access relevant constraint information or other information, stored in one or more databases. The rules guiding the menu decision process includes but is not limited to the start and end of service times, the booking intervals, the latest time a booking would be accepted, and the maximum number of patrons, tables, walk-ins, and number of people per menu type.

[0264] Referring to Figure 4h, there is shown a setup screen where a user can configure the availability of menus by courses (4108, 41 10, 4112, 41 14, 41 16, 41 18, 4120 and by time 4102, within a meal period 4100. Override switches can be utilised to override the time availabilities set for a menu 4102, for VIP patrons 4104 and SVIP patrons 4106.

[0265] Referring to FIG. 5a, there is shown an example screen of a listing of product groups 507, showing specifically a "leaf 502 of a branch of the tree representing a specific product group. A corresponding list of products 504, associated with that specific product group 502, is also shown including product information details such as a product name 5190.

[0266] Referring to FIG. 5b, there is shown a setup screen for an existing product group 506. The user is shown to have selected a parent product group 510, which the product group 506 is grouped under, input a name 512, for the product group 506, input a description 514 and enabled the product group as an active product group 516. There is also shown an option to enable the product group 506 to appear on the booking widget as a concierge service selection 1726.

[0267] Referring to FIG. 5c, there is shown a setup screen for a product 522 including the selection of a parent product group 524, the input of the product name 526, description 528, PLU barcode number 530, the selection of a restaurant to which to link the product 532, the input of variable pricing by menu 534 (as setup in Figures 4a-e) and the selection of a price calculation type 536.

[0268] The setup screen is continued in Figure 5d, where there is shown inputs for the product widget display name 538, menu display name 540, menu description 542, an optional selection to link a supplier to the product 544, an option to link equipment to the product 546, an option to enable the product as an active product 548, buttons to open related setup screens to input recipe and product variation information 550, cooking instructions 552 and condiments 554. The user is able to save this iteration of the product data by clicking the save button 556.

[0269] Referring to Figure 5e, there is shown a flowchart illustrating a product setup to enable menu configuration for the menu pre-ordering widget. At step 558, the operator selects a product setup and at step 560, the operator selects a new product option. Subsequently, the operator selects a product group to assign the new product to at step 562, and the operator inputs the full name of the product at 564 and the product description at 566. The operator then inputs the PLU barcode number for the product at 568 and subsequently elects a restaurant to assign the product to at 570. The operator then inputs a product price at 572, and a display name (for display on the widget) at 574. The operator selects a relevant product supplier at 576 and a product price calculation type at 578. The operator then enables the product as an active menu item at 580 and then selects the variation button at 582 to access the setup interface for product variations. At step 586 the operator selects items from stock to add to the product ingredients list and at 588 the operator inputs preparation time and cooking time.

[0270] At step 590 the operator inputs the method of preparation and cooking and at step 591 , the operator selects one or multiple dietary categories to apply to the product. Optionally, at step 20100, the operator adds an alternative product. At step 596 the operator selects an alternative product description, and at 598 the operator selects appropriate allergy and or dietary requirement categories. The operator modifies the ingredients for the alternative product at 5100 and the operator saves the alternative product details at 5104. The operator then saves all product details at 5106. In this manner, the operator can create not only products for the menu, but alternative products to cater for customers with specific dietary requirements or allergies. As such, no manual intervention is required if the customer has specific requirements. Rather, the system provides the customer with a choice with regard to dietary requirements.

[0271] Referring to Figures 5f to 5h, there are shown screenshots which display the input screens associated with the process flow described with reference to Figure 5e. Firstly referring to Figure 5f, there is shown a product setup screen 5108, which is generally under the admin section of the ResButler interface, as indicated by pathway 5109. The setup fields shown on Figure 5f have been previously described in relation to Figures 5c-d.

[0272] Referring to Figure 5g, if the operator clicks the recipe button (Figure 5f, 5130), the operator is provided with the input screen 5138. The operator is presented with a stock item list from which the user can add items using add item buttons 5141. If added, the items are displayed in selected ingredients screen 5144 and the operator can add a quantity as shown generally at 5146. The operator can delete items from the ingredients list by using button 5148. The operator can add a preparation time at 5150 and a cooking time at 5152. The operator can also add a method for preparing and cooking the product at 5154 and can enter variations (alternative products) at area 5156. The user can add an alternative product description at 5158, select relevant allergies at 5160 and relevant dietary requirements at 5162.

[0273] Referring to Figure 5h, there is shown a continuation of the recipe screen of Figure 5g. The operator is provided with a modified ingredients list at 5172, where the operator can add an ingredient using button 5176 and remove ingredients using button 5174 or substitute ingredients using button 5178. The operator can add a different preparation time at 5180, a different cooking time at 25182 and a different recipe or cooking method at 5184. Once finished entering information, the operator can save the iteration of the recipe setup at 5186.

[0274] Referring to Figure 6a-i generally, there is shown setup screens for an operator to add specific products to specific menus as setup in Figures 4a-e, as a setup allowing for the facilitation of menu pre-ordering and menu ordering including links between bookings, allocations, products and transactions.

[0275] Referring to Figure 6a, there is shown a setup screen for the menu builder 600. Options to select an opening times set 604 and a menu set 606, allows the operator to recall a specific group of previously setup menus shown at 610, 612, 614, 616, 618, 620 and 622. The operator is able to add menu items to a specific menu by clicking the button 624, or by clicking the edit link 626 which is displayed if products have been previously added to a menu. [0276] On clicking either the add menu items button 624 or edit menu items link 626, the operator opens a related input screen shown in Figure 6b where there is shown tabs for three setup sections: menu headings 632, menu items 608 and course rules 608. Referring to Figure 6b, the selected tab is shown to be menu headings 632 where an operator can create menu headings by clicking the new menu heading button 634, after which created menu headings (638, 640 and 642) appear in a list which includes details such as mandatory purchase requirement 644 which determines whether or not a menu heading and its associated products are subject to an ordering constraint (described further in Figures 6h-i), display order 646, which determines in what order menu headings appear on the corresponding interactive menu display, and whether or not a menu heading is enabled as an active menu heading 648.

[0277] On clicking the new menu heading button 634, a related popup screen 650 is displayed (shown in Figure 6c). An operator may input a name for the menu heading 652, determine if the menu heading is categorised as a mandatory purchase requirement 654 and enable the menu heading as an active menu heading 656. On clicking save, an operator adds a new menu heading to the menu heading list shown in Figure 6d, shown by new menu headings 676, 678 and 680.

[0278] Referring now to Figure 6e, the selected tab is shown to be menu items 690, where an operator adds existing products from the product tree to the menu as menu items, grouped by previously setup menu headings 692, 694 and 696, by clicking the add menu item button 691.

[0279] On clicking the add menu item button 691 , a related popup screen 698 is displayed (shown in Figure 6f). An operator may select a product to add as a menu item by first selecting the applicable parent product group 6100, from which a list of associated products are displayed in a list 6102, which includes the pricing for each product based on the menu being setup 6104. One or multiple products can be selected by ticking checkboxes 6106 and 6108, then clicking the add button 61 12, by which the selected products are added to the menu item list for the selected menu heading as shown in Figure 6g.

[0280] Referring to Figure 6h, the selected tab is shown to be course rules 6126, where an operator may setup rules to constrain a customer's selection of menu items during the menu pre-ordering or ordering process. Rules are setup by courses within a menu shown by 6128 and 6140 in Figure 6h, and 6142 and 6144 in Figure 6i. As shown in Figure 6h, course rules include selecting which previously setup menu headings are to be displayed on the interactive menu by the categories "mandatory for selection” 6132, and "not mandatory for selection” 6134. The operator may then select to apply a minimum number of menu items required for order per person 6136, and subsequently if yes is selected, a minimum number of menu items under mandatory menu headings required for orders per person may be input.

[0281] Referring to Figure 6i, there is shown a continuation of the setup screen shown in Figure 6h, including a save button 6146 which saves an iteration of the menu builder setup for the selected menu.

[0282] Referring to FIG. 7a there is shown a flowchart depicting the posting process for one or multiple volumetric floor plans to a calendar by one of service, day of the week and date range. At step 700 a restaurant is selected. At step 702 a meal period is selected, followed by the selection of an allocation constraint set at step 704. Subsequently, a date range is selected at step 706. [0283] At step 708, the desired days of the week are enabled for opening times-related constraints and menu-related constraints, followed by the selection of desired constraint sets including opening times set 710, menu set 712, promotional menu set 714 and reduced price promotions set 716.

[0284] At step 718, the desired days of the week are enabled for backfill promotions and follow-on promotions, followed by the selection of the desired constraint sets including backfill promotions set 720 and follow-on promotions set 722.

[0285] At step 724, the desired days of the week are enabled for floor plan and floor plan-related constraints 724, followed by the selection of the desired constraint sets including floor plan 726 and allocation rules 728, after which all selected constraint sets are posted to the calendar by meal period, by day of the week and by selected date range 732 before the process ends at step 625.

[0286] Referring to FIG. 7b-c, there is shown a screenshot of an interface utilised by an operator to effect the method steps described with reference to FIG. 7a. In FIG. 7b, at 736 there is shown a title for the screen, and there is provided a restaurant selector. There is also provided a number of selectors including a meal period selector 740, an allocation constraint set selector 742, and a date range selector as indicated at 744 and 746. There are also provided four sets of selectable constraints, namely an opening-times and menu-related set of constraints 748, a backfill promotions and follow-on promotions set of constraints 764, a floor plan and floor plan- related set of constraints 774 and an allocation rules set of constraints 1668. The opening-time and menu constraint set allows the selection of an opening time set 756, a menu set 758, a promotional menu set 760 and a reduced price menu set 762 for each defined service/day period. Similarly, the backfill promotions and follow- on promotions set of constraints allows the selection of a backfill promotions set 770 and a follow-on promotions set 772 for each defined service/day period.

[0287] Referring to Figure 7c, there is shown a continuation of Figure 7b where the floor plan and floor plan-related set of constraints allows for the selection of a floor plan set 778 for each defined service/day period, and the allocation rules set of constraints allows for the selection of an allocation rules set 786 for each defined service/day period. Once all relevant sets have been selected, the operator posts the selected sets to the calendar by using the post button 788. In this manner, each service/day period can utilise a customised set of constraints.

[0288] Referring to Figure 8a there is shown a screenshot of a configurator in accordance with an embodiment of the invention. As described, the configurator allows multiple "channels” (i.e. different instances of the widget which behave differently and may be deployed to different websites, apps, etc.) to be individually controlled, wherein all features, inputs, outputs and aspects of the interface may be potentially turned off or on depending on the requirements of the restaurant.

[0289] The interface includes a title 802, a restaurant selector 804, booking widget configuration set selection facility 806, a series of selectable switches as shown at 810 generally (or 810a, b, c and d specifically), wherein each category as denoted by 808 includes sub-categories as denoted by 812 and 814. For each channel, there is also provided toggle switches 801 a, 801 b, 801 c and 801 d respectively. The interface also allows each element in each sub-category to be moved using arrows 816 or an entire category to be moved using arrows 818. [0290] Referring to Figure 8b through to 8e, there are shown screenshots, each displaying examples of sub-categories relevant to the setup of menus and menu-related constraints, such as menu selection 820, dietary requirements 838, allergies 840, menu preordering 852 etc. It will be appreciated that potentially any sub categories may be included, as per the figures shown.

[0291] Referring to Figure 9a there is shown an email process triggered by the creation of a booking. At step 900, a customer submits a successful booking via the booking widget. At step 902, a determination is made as to whether the booking includes a prepayment concierge service item. If yes, four emails are sent, as shown at steps 904, 912, 922 and 930. Referring to step 904, an email is sent to the restaurant, in the form of a new booking email 906, which includes booking details 908 and a link to the dashboard 910. Referring to step 912, an email is sent to the customer, in the form of a booking email 914, which includes booking details 916, an update booking link 918 and a menu pre-order link 920. Referring to step 922, an email is sent to the customer's guests, in the form of an invitation email 924, which includes booking details 926 and a menu pre-order link 928. Referring to step 930, an email is sent to the supplier, in the form of a new order email 932, which includes order details 936 and booking details 938.

[0292] If the booking does not include a concierge item, the email creation process continues along arrow 1 , which is described in more detail in Figure 9b.

[0293] Referring to Figure 9b there is shown a continuation the email creation process as indicated by arrow 1 (in the case where a booking request does not include a pre-ordered concierge item), which is further described with reference to Figure 9a. Referring to step 904 of Figure 9b, an email is sent to the restaurant, in the form of a new booking email 942, which includes booking details 944 and a link to the dashboard 946. Referring to step 948, an email is sent to the customer, in the form of a booking email 950, which includes booking details 952, an update booking link 954 and a menu pre-order link 956. Referring to step 958, an email is sent to the customer's guests, in the form of an invitation email 960, which includes booking details 962 and a menu pre order link 964.

[0294] Referring to Figure 9c, there is shown a prior art static pre order and transaction process including payment. As described with reference to the prior art point of sale systems, there is generally provided a device 966 which includes an ordering system 968. This is passed to a pre-order transaction module 970 and upon a guest arriving at 974, a table is opened for the guest and information is manually transferred at step 976 from the pre-order transaction system to the point of sale system and the transaction is completed at step 978.

[0295] Referring to Figure 9d. there is shown a diagrammatic representation of a volumetric space pre order and transaction process and payment system in accordance with an embodiment of the invention. As with the prior art, there is provided a device 980 which includes an ordering system 982 which transfers the order to a space and volume sale and transaction system 984. The pre-order transaction is loaded at 986 into a volumetric framework, such that, when the guest arrives at step 988, the per-order is automatically applied to a table as a result of the guest being seated and the transaction then completes automatically at step 990 when the guest leaves the restaurant. [0296] Referring to Figure 9e, there is shown a flowchart illustrating a menu pre-payment process. At step 992, a customer accesses the menu pre-ordering widget. The customer is identified at step 994, after which an interactive display illustrating the relevant table and chair position numbers for the booking is displayed at step 996. The customer assigns guests at step 998 to each chair position, and thereafter, an interactive menu is displayed at step 9100. The customer selects items at step 9102, and at step 9104, an order summary is displayed.

[0297] Thereafter, pre-payment options are displayed at step 9106, and the customer prepays for selected items at 9108. The transactions are subsequently added to the customer's account at step 2018. After prepayment and menus selection, then at step 9110 the transaction is added to a specific table when at a specific time before service, booking are allocated to tables at step 91 14, all booking information including menus are associated with the stable at step 91 16, such that when the customers arrive at step 91 18, they are seated, and if all orders have been pre-paid and pre-ordered, then at step 9120 the order is automatically sent to the kitchen. In this manner, the entire ordering process is automated or semi-automated, allowing for more efficient use of kitchen resources.

[0298] Referring to Figure 9f, there is shown the interaction between the device (customer device or kiosk) 9122 and the database 9146. The device 9122 is capable of executing a widget 9124 in accordance with an embodiment of the invention. The interface of the widget 9124 allows the customer to input an identifier 9126, which is then used by the widget (at 9145) to request CRM information from the client database 9146. Returning to the widget, once the CRM information is identified, the information is sent to the widget at step 9164 and is customised at step 9166, in order to display on the user interface of the widget 2032 specific promotions 2036, menu-related constraints 9140, and to hide or show specific fields based on constraint information as shown at 9142. The customer completes and submits the pre-order at 9144.

[0299] Returning to the client database 9146, included in the database is a CRM 9148, the CRM including customer records such as Customer‘A record 9150 which includes a customer ID 9152, booking history 9154, membership information 9156, customer preference data including dietary preferences, etc. 9158, customer behaviour information 9160, wherein the record 9150 is also associated with relevant promotions 9162.

[0300] Referring to Figures 9g-l, there are shown various screenshots of an ordering widget which utilises the menu and product items created with reference to Figures 9c-e. At Figure 9g, there is shown a first screen 9166 of a widget or app which allows a customer to update their booking details. This may be displayed as a result of the customer clicking on a link in an email 9164 or may be displayed to the customer in some other manner. The booking widget 9166 includes the restaurant name 9168, the number of guests 9170, the date of the booking 9172 and the time of the booking 9174. The display also includes the name of the customer who booked the space 9176 and a unique reference for the booking 9178. Using various buttons, the customer can edit a booking using button 9180, cancel a booking using button 9182, pre-order from the menu using button 9184 or view promotions using button 9186.

[0301] Referring to the example where the customer directly accesses the widget (not via a link in an email), the customer may be presented with a pre-ordering login screen 9190 which includes instructions 9192, where the customer can enter a booking reference number 9194 is known, or alternatively enter an email address 9196 and a booking date 9198 before clicking the continue button 9200.

[0302] Referring to Figure 9h, there is shown a subsequent screen 9202 which is displayed once the customer is identified and elects to pre-order their meal. At screen 9202 there is shown a welcome message 9204, a descriptor of the person logged in at 9205, and a general area 9206 which includes information about the booking 9210, a logo or image 9208, a link to view the table booked 921 1 , a link to view existing orders associated with the booking 9213, a listing of guests 9212 including each guest name 9214 and a facility to edit the guest name 9216. There is also optionally shown a promotion arranged to provide the customer with an opportunity to upgrade in some manner, which, in the example screen shown, provides the customer with a free drink if they add all guest names utilising button 9220.

[0303] There is further provided a series of tabs in area 9222, such as tab 9224 which corresponds to a specific guest, and tab 9226 which corresponds to the table. There is also shown the menu generally denoted by 9228, with various menu items (such as 9232) grouped under headings 9230 and 9238. There are also shown prices 9234 and the ability to add an item using add button 9236.

[0304] Referring to Figure 9i, if the customer selects the table booked view button from Figure 9h (921 1 ) a screen 9240 is displayed including a representation of the table 9246, a representation of chairs 9242 and 9244, where the selected chair is coloured differently (9244), and a tab representing each guest 9248, 9250, 9252 and 9254. Each guest tab allows a first name 9256 to be input, a last name 9258 to be input, an email address 9260 to be input, a mobile number 9262 to be input, an allergy to be optionally selected 9264 and a dietary requirement 9266 to be selected. All information input can be saved using button 9270 or cancelled using 9268.

[0305] Referring to Figure 9j, there is shown a closeup of a portion of the screen 9272, for a particular tab 9274 (of a series of guest tabs 9276, 9278, 9280 and 9282) where a popup screen for a selected menu item is displayed. There is provided an image of the item 9284, the name of the menu item 9286, the price 9288, the ingredients 9290, an option to select condiments 9292, an option to vary cooking instructions 9294, a button to add to the order 9298 and a cancel button 9296.

[0306] Referring to Figure 9k, there is shown a variation of the closeup of Figure 9j, where guest 4 (9280) has provided information regarding allergies 9300 and dietary requirements 9302 which results in the ingredients 9304 being changed, and optionally the condiments 9306 may also be varied, as may the cooking instructions 9308.

[0307] Referring to Figure 9I, once each customer has placed their order, there is shown a total screen 9310, which, for each guest, such as guest 9314 and guest 9328, there is shown an order 9312 including selected menu items 9316, 9318, 9320, 93221 and 9324, associated prices such as 9330, including sub-totals 9334 and a total 9336, and the ability to delete items using cross 9332. The customer can also proceed to payment by clicking button 9340.

[0308] An operator may select a specific table, as shown in FIG 10a in screenshot 1000, wherein the selected table will be shown in a popup screen 1002. Upon selecting a seat on the table, a full menu 1004 (Figure 5b) is shown, including different courses 1006, 1008, 1010 and 1012. The menu is specific to the type of booking. There is also provided a facility to add to the order, by using tabs 1018, 1020, 1022 and 1024 and 1026. As can be seen, each seat is shown 1028 (and 1036), and an operator can cancel an item on an order 1032 or send to kitchen 1034. Also, the operator can send all orders for a course to the kitchen 1038. In this manner, the operator can efficiently change orders, send orders to the kitchen, or cancel orders easily.

[0309] Referring to FIG. 10b-d, by clicking the order summary tab 1016, the operator can view a summary of payment and promotion details 1040 and a summary of the entire meal 1042, including costs. The operator can also select an option to pay the bill for the customer at 1046. Summary information for other customers on the table can also be shown, as seen at 1048.

[0310] Referring to Figure 1 1 a, there is shown a modular chart depicting the various hardware and software components of the ordering system and widget in accordance with an embodiment of the invention. Utilising the product tree 1100 and opening hours information 1 101 and 1 103, floor plan information 1 102, menu information 1 104, promotion information 1 106 including reduced price promotions 1 107, backfill promotions 1109 and follow on promotions 1 11 1 , plus booking fee information 1 108, extended duration information 1 109, concierge service item information 21 10, allocation rules 1 1 12, widget configuration rules 1 134 and email configuration data 1 135, all information is posted to the posting calendar 11 14 which includes table allocation logic 11 16 and transaction details 1 1 18 and interacts with the booking widget 1 136 which receives booking request 1 138 from customer 1 to create a seating process 1 120 which is then posted to the POS system within the volumetric framework, which is arranged to interact with the floor staff ordering app and databases 1 124. The floor staff ordering app is in communication with the printer integration manager 1 128 and a kitchen printer 1 130, and a till 1 132.

[031 1] The email configurator 1 135 communicates with the customer via emails 1 146 which include the ability to edit bookings 1 148 and cancel bookings 1 150 an also pre-order 1 152, which connect with the menu ordering app or menu ordering widget 1 144. Similarly, customer 2 (1 154) may interact directly with kiosk 1 156 which has a cloud connection to the calendar 1 158. The operator/owner/manager 1 131 may also have a cloud connection 1 133 to the diary and dashboard reporting system.

[0312] Referring to Figure 12a, there is shown a screenshot of a menu creation screen in accordance with an embodiment of the invention. The screen 1200 allows the restaurant to create a series of menu headings. The user can utilise the create new menu headings button 1202 to create headings such as those generally displayed in column 1204. The user can also enable or disable menu headings (i.e. choose to display or not display the headings) using tick boxes in column 1206. The headings may also be edited by clicking the edit button 1208.

[0313] If the user clicks the edit button 1208, they are taken to the edit menu headings screen 1210 as shown in Figure 12b, which allows the user to type a name for a menu heading at 1212, select one or more restaurants (displayed in column 1214) and enable the menu heading to be displayed in menus associated with the restaurant by clicking the check boxes in column 1216, and also type menu display names for the menu headings in input boxes 1220. The menu headings screen also allows the user to create and display subheadings by selecting the enable subheadings box 1222 and input subheadings as shown in input boxes in column 1224. The user may delete existing subheadings by selecting the trash icon associated with each subheading 1226 or may alternatively add more subheadings by utilising the addition icon 1228. The entire menu headings feature may be enabled or disabled by selecting check box 1230, and once the user is satisfied with their changes, they can click the save button 1232 to save any changes.

[0314] Referring to Figure 13a, the setting up of menus also requires the setting up of one or more menu folders, which is achieved through the user interacting with screen 1234. The user selects a restaurant from a drop-down menu 1236 and can then create a new menu folder utilising button 1238, to create folders such as those generally displayed in column 1240. The user can also enable or disable menu folders (i.e. choose to display or not display the folders) using tick boxes in column 1242. The folders may also be edited by clicking the edit button 1244. When the user clicks button 1238, they are taken to the screen shown in Figure 13b. The new menu folder creation screen shown generally at 1300 allows the user to enter a folder name 1302 and enable the folder by using check box 1304. Once the user is satisfied with their input, they can save the new folder by clicking save button 1306.

[0315] Referring to Figure 14a, the embodiment described herein also utilises a concept of duration menus. In summary, a duration menu is a menu linked with duration constraints by the number of people associated with a booking or other criteria associated with a service and if associated with a booking, is utilised by the booking algorithm to allocate that booking to a table as a factor to determine booking duration time. Screenshot 1400 shows the duration menus screen, where a user enables and disables duration menus. At 1404 a user can select the create new duration menus button to create a new duration menu. Created menus are listed in column 1406 and an associated menu folder for each duration menu is displayed in the corresponding column 1408. The user may enable or disable each menu by selecting or deselecting the tick icon in column 1410. Correspondingly, a user may edit a duration menu by selecting the relevant edit icon, such as icon 1412.

[0316] When a user selects the create new duration menu button 1404 of Figure 14a, the user is presented with screen 1414 of Figure 14b. In Figure 14b, the elements of tab 1416 are shown, including a text box used to assign a name to the menu at 1418, a widget display name text box at 1420, a menu display name at 1422, a menu folder pull down menu 1424 arranged to associate the menu with a menu folder, a feature to allow the user to upload an image to be displayed on the menu (at 1426), and the ability to enable the duration menu by selecting check box 1428. The user may also save any changes at any time using the save button 1430.

[0317] Referring to Figure 14c, there is shown a screen shot 1432 of a screen for tab 1434, which allows the user to add menu items. The user may select a new menu heading by using icon 1436. The screen 1432 also displays existing (previously chosen) menu headings 1438, 1450, 1452 and 1454, as examples. Turning to menu heading 1438, a user may associate menu items with a selected menu heading by utilising the add menu item button 1440, which populates a table generally denoted by 1442 which allows a user to view a menu item, view a menu item size (as shown by column 1444), view a standard price 1446, move menu items up and down relative to other menu items nested under the same menu heading, determining the order in which menu items are rendered when viewed by an end user (1445), and also delete menu items by using trash can icon 1448. The menu headings may also be moved relative to each other by using up and down arrow icons 1456 and 1458. The movement of menu headings affects the order in which the menu is rendered when viewed by an end user (i.e. a customer/diner).

[0318] Referring now to Figure 14d, there is shown a continuation of the screen of Figure 14c for beverages, including a menu heading 1460 and subheadings 1462, 1472, 1474 and 1476. Under each subheading (only subheading 1462 is shown in an expanded form for the purposes of illustration), a user can add a menu item using button 1464. Added menu items are generally shown in the table denoted by 1466, including a column for size 1468 and a standard price 1470.

[0319] Referring now to Figure 14e, there is shown a pop-up screen generally denoted by 1478. In the pop up screen which is generated when a user wishes to select a menu heading (by use of icon 1436 of Figure 14c), a user may select or deselect menu headings by using tick boxes 1480 and 1482 (for example) to select or deselect menu headings. The user may then save their selection using button 1486 or may cancel their selection using button 1484.

[0320] Referring now to Figure 14f, there is shown a pop-up screen 1488 which is displayed when a user selects an add menu item button, such as those shown at 1440 in Figure 14c and 1464 at Figure 14d. The user may filter options by using drop down menu 1490 and products for selection are shown at 1492 where the user can select different sizes for products by using the checkboxes in columns 1494 and 1496, such as checkbox 1498 and 14100. The user may then save their selection using button 14104 or may cancel their selection using button 14102.

[0321] Referring now to Figure 14g, there is shown a screen 14106 highlighting the third tab of the general duration menus screen, namely the courses tab 14108. The courses tab 14108 allows a user to create menus with variable numbers of courses and associate various parameters or constraints with each set of courses. Menus with different numbers of courses can be added using the plus symbol icon 141 10. In the screen 14106, there are shown three different examples of a set of courses including 141 12 (1 course meal) 14124 (2 course meal) and 14126 (3 course meal). For each different set of courses defined, a series of constraints may be input using input boxes, including a minimum number of people at input box 141 14, a maximum number of people at input box 141 16, a standard time for a booking duration time at input box 14118, a VIP time for a seating at input box 14120 and a Super VIP time for a seating at input box 14122. Each set of constraints may be deleted using trash can icon 14128 or more constraints may be added using the plus icon at 14130. A user may save their input by using save button 14132.

[0322] Referring now to Figure 14h, there is shown a screen 14134 highlighting the fourth tab of the general duration menus screen, namely the menu type tab 14136. A user may select a menu type by using radio buttons 14138 and save their selection by using save button 14140.

[0323] Referring now to Figure 14i, there is shown an example of where the user selects the second radio button, namely the package button. If the package button is selected, then the screen 14142 is displayed in the menu type tab 14144. Additional options are presented to the user, including the ability to select a product to set package pricing at 14146, where a package price 14148 is displayed and the user may edit the product or package price by utilising edit icon 14150, and the package may be associated with one or more menu headings, where the user is presented with available menu headings as displayed in column 14152, and the user can use the check boxes in column 14154 to select or deselect a menu heading to associate with the package, and may also input a mandatory ordering quantity per person by utilising the input boxes generally down at 14156. The user may save their input by using save button 14158.

[0324] Referring now to Figure 14j, there is shown a pop-up screen 14160 which allows a user to select a product to set a package price. The user may select a product group using pull down menu 14162 and is presented with a series of products in column 14164 including a standard price 14166 and the ability to select or deselect products using check boxes 14168. The user may save their selections using button 14172 r cancel their selections using cancel button 14170.

[0325] Referring now to Figure 14k, there is shown a screen 14174 highlighting the fifth tab of the general duration menus screen, namely the table classes tab 14176. A user may select a table class (or multiple table classes) to associate with a duration menu by using check boxes 14178 and save their selection by using save button 14180.

[0326] Referring now to Figure 15a, there is shown a non-duration menu screen 1500. Non-duration menus are menus that are not linked with duration constraints and if associated with a booking, are not utilised by the booking algorithm to allocate that booking to a table, and by extension have no effect on the duration time of a booking. At screen 1500 the user can select a restaurant to apply the non-duration menu to by using pull down menu 1502. The user may also create a new non-duration menu by using button 1504. Previously created menus are displayed in column 1506 along with their associated menu folder in column 1508. A user may enable or disable menus by selecting or deselecting tick icons in column 1510 and may edit any of the menus by using the edit icons in column 1512.

[0327] Referring now to Figure 15b, there is shown a screen 1514 that is displayed when a user selects the create non-duration menu button 1504 of Figure 15a. At 1516 there is shown a create/edit tab that allows a user to create a non-duration menu, including inputting a name for the menu at text box 1518, inputting a widget display name at text box 1520, inputting a menu display name at input box 1522, selecting a menu folder to associate with the non-duration menu at pull down menu 1524, and upload an image to display on the menu at upload box 1526. The user may enable or disable the non-duration menu by using check box 1528 and may save their work by using save button 1530.

[0328] Referring now to Figure 16a, there is shown a screen shot 1600 of a menu pricing screen. The menu pricing screen allows the user to set different prices for the same menu item dependent on circumstances. The user, after selecting a restaurant from pull down menu 1602, is presented with two pull down menus to allow the user to filter results in a manageable manner. The first pull down menu, 1604, allows the user to limit generated input fields to input fields associated with a single menu folder. The second pull down menu, 1606, allows the user to select a product type, such as food, beverage, etc. Once the pull down menus 1604 and 1606 have been selected by the user, there is displayed a table which includes a series of columns which represent service periods as compared to a standard price, denoted by 1608, 1610, 1612, 1614, 1616 and 1618, which each represents a column of prices for associated menu items, which are displayed in the rows generally denoted by 1620 and 1622. The user may then enter a price for each menu item for each specific service period.

[0329] Referring now to Figure 17a, there is shown a screen shot 1700 of a restaurant service screen, which allows the user to associate one or more menus with one or more service periods, dates and/or times. The user, after selecting a restaurant from pull down menu 1702, is presented with two pull down menus to allow the user to filter results in a manageable manner. The first pull down menu, 1704, allows the user to limit to an opening time. The second pull down menu, 1706, allows the user to select a set of menus, such as Friday menus, as shown in the Figure. Once the pull-down menus 1704 and 1706 have been selected by the user, there is displayed a series of tabs, the first of which, 1708, as shown in the Figure, is a screen that allows the user to add duration menus. The user may add different types of duration menus, as shown by buttons 1710, 1714 and 1718 (breakfast, lunch and dinner menus respectively as shown in the example screenshot 1700). The menus added are shown below each of the buttons 1710, 1714 and 1718. That is, breakfast menus are shown at 1712, lunch menus at 1716 and dinner menus at 1720. The user may delete a specific menu using the trash icon 1722 and may change the relative position of the menus (as they would be displayed to a customer) by using up arrow 1726 and down arrow 1724.

[0330] Referring now to Figure 17b, there is shown a pop-up screen 1728 that is displayed when the user clicks an add menu button, such as menu button 1718 of Figure 17a. The pop up 1728 allows the user to select a menu folder by using pull down menu 1730 which displays a series of duration menus at 1732. The user can select and deselect menus by using check boxes 1734 and 1736 and can either cancel their selections by using cancel button 1738 or add their selections by using add button 1740.

[0331] Referring now to Figure 17c, there is shown a second tab of the screen of Figure 17a, namely the add non-duration menus tab 1742. The user may add different types of duration menus, as shown by buttons 1744, 1748 and 1752 (breakfast, lunch and dinner menus respectively as shown in the example screenshot 1700). The menus added are shown below each of the buttons 1746, 1750 and 1754. That is, breakfast menus are shown at 1746, lunch menus at 1750 and dinner menus at 1754. The user may link non-duration menus to specific duration menus by clicking each edit link icon 1758 in each duration menu link column 1756, or delete a specific non-duration menu using the trash icon 1764 and may change the relative position of the menus (as they would be displayed to a customer) by using up arrow 1762 and down arrow 1760.

[0332] Referring now to Figure 17d, there is shown there is shown a pop-up screen 1766 that is displayed when the user clicks an add menu button, such as menu button 1752 of Figure 17c. The pop up 1766 allows the user to select a menu folder by using pull down menu 1768 which displays a series of non-duration menus at 1770. The user can select and deselect menus by using check boxes 1772 and can either cancel their selections by using cancel button 1776 or add their selections by using add button 1778.

[0333] Referring now to Figure 17e, there is shown a pop-up screen 1780 which allows the user to link one non-duration menu to one or multiple duration menus. The pop up 1780 allows the user to select a menu folder by using pull down menu 1782 which displays a series of duration menus at 1784. The user can select and deselect menus and can either cancel their selections by using cancel button 1786 or add their selections by using add button 1788.

[0334] Referring now to Figure 18a, there is shown a product sizes screen 1800 which allows a user to create product sizes for use in one or more menus. The user can utilise the create new product size button 1802 to create sizes such as those generally displayed in column 1804. The user can also enable or disable product sizes using tick boxes in column 1806. The sizes may also be edited (i.e. change the size and/or name of each product size) by clicking the edit button 1808.

[0335] Referring now to Figure 18b, there is shown a screen 1810 which is displayed when a user clicks the create product size button 1802 of Figure 18a. The user can add a name for the product size at text input box 1812 and may enable the product (i.e. cause the product size to be viewable) by using the check box 1814. The user may save any changes using the save button 1816.

[0336] Referring now to Figure 19a, there is shown a screen which allows the user to edit information and constraints regarding the display information on a menu with regard to a menu item. At edit screen 1900, the first tab 1902 provides the user with the ability to add information regarding the product (menu item). This includes the product group 1904, the name 1906, a description 1908, a barcode 1910, a display name on the widget 1912, a menu display name 1914, a description (for the menu) 1916, and also select a supplier 1918 and extend the duration of the product/menu item 1920. The user may enable the product (i.e. cause the product to be viewable) by using the check box 1924. The user may save any changes using the save button 1926.

[0337] Referring now to Figure 19b, there is shown a second tab 1930 of a screen 1928 which allows the user to edit information and constraints regarding the display information on a menu with regard to a menu item. The second tab 1930 allows the user to add and vary sizes, including the ability to add a size using button 1932. Available sizes are shown in table 1934, and a user may delete sizes using trash can icon 1936. The user may save any changes using save button 1938.

[0338] Referring now to Figure 19c, there is shown a pop-up screen 1940 which appears when the user clicks the add size button 1932 in Figure 19b. A series of available product sizes are shown at list 1942, and the user may select or deselect product sizes using check boxes 1944. The user may further cancel their selections using cancel button 1946 and add selections using button 1948.

[0339] Referring now to Figure 19d, there is shown a third tab 1950 which allows the user to edit information and constraints regarding the prices for different product sizes associated with a menu item for different restaurants. The third tab 1950 displays a series of restaurants in column 1952 and associated standard prices for different product sizes in columns 1954 and 1956. There is also shown, in the embodiment described herein, a butler service table, which allows the user to associate a product size 1960 with a butler service subcategory 1962, and in turn allow the user to require prepayment, text input and/or enable the butler service, by using the check boxes in columns 1964, 1966 and 1968 respectively for the purpose of offering any setup items to end users during the booking process.

[0340] Referring now to Figure 20a, there is shown there is shown a butler service category screen 2000 which allows a user to create butler service categories for use in one or more menus. The user can utilise the create new butler service category button 2002 to create categories such as those generally displayed in column 2004 and also provide a description as shown in column 2006. The user can also enable or disable categories using tick boxes in column 2008. The categories may also be edited (i.e. change the size and/or name of each product size) by clicking the edit button 2010.

[0341] Referring now to Figure 20b, there is shown an example of the edit screen 2012 that is provided to the user when the user selects the edit button 2002 of Figure 20a. The edit screen 2012 allows the user to enter a text-based name 2014, a text based description 2016, and select or add subcategories as shown in list 2018. The user can delete subcategories using trash icon 2020, and add categories using plus sign icon 2022. The user can enable the category by checking the enable check box 2024, and can save any alterations, additions or changes by clicking save icon 2026.

[0342] Referring now to Figure 20c, there is shown a screen 2028 that allows a user to create a product group, including selecting a parent product group at pull down menu 2030, adding a name at text box 2032, adding a description at text input box 2034. The user can enable the product group by checking the enable check box 2036, and can save any alterations, additions or changes by clicking save icon 2038.

[0343] Referring now to Figure 20d, there is shown the third tab 2042 in screen 2040 which allows the user to edit information and constraints regarding the prices for different products associated with a menu for different restaurants. The third tab 2042 displays a series of restaurants in column 2044 and associated prices for different products in columns 2046 and 2048. There is also shown, in the embodiment described herein, a butler service table 2054, which allows the user to associate a product size 2056 with a butler service subcategory 2058, and in turn allow the user to require prepayment, text input and/or enable the butler service, by using the check boxes in columns 2060, 2062 and 2064 respectively.

[0344] Referring to Figure 21 a, there is shown a diagrammatic representation of a system in accordance with an embodiment of the invention. The system includes several components, including a volumetric framework 2102, which is in communication with a system admin dashboard 2100, a dashboard for each individual restaurant or group of restaurants 2104, which in turn is connected to a series of databases 2108 including databases 21 10, 21 12, 2114 and 21 16. Where information is to be inputted into the database from the dashboard, there exists a logic layer 2106 between the dashboard and the databases.

[0345] Returning to the volumetric framework 2102, the framework is in communication with a booking system 21 18, which in turn is in communication with a CRM 2136. In turn, using APIs 2120 and 2134, the booking system 21 18 and CRM 2136 communicate with a suite of user apps 2122, including a booking app 2124, a menu ordering app 2126, a self-seating app 2128, a self-seating kiosk app 2130 and a booking exchange app 2132. The volumetric framework 2102 also operates with an in-service system 2138 which communicates with an in- service app 2142 connected to a payments gateway 2144, the in-service system 2138 also being in communication with a docket printer 2140.

[0346] Referring to Figure 21 b, there is shown a specific embodiment of the system of Figure 21 a, with a particular reference to the use of menus. The system includes several components, including a volumetric framework 2148, which includes specific files for particular services and dates 2150, each service including specific available menus 2152 and allocated bookings 2154. The framework 2148 is in communication with a system admin dashboard 2146, a dashboard for the individual restaurant or group of restaurants 2156, which in turn is connected to a menu database 2174 (amongst other databases 2172) via logic 2168, 2161 and 2170.

[0347] Returning to the volumetric framework 2148, the framework is in communication with a booking system 2176, which in turn is in communication with a CRM 2186 which includes customer information 2188. In turn, using APIs 2178 and 2184, the booking system 2176 and CRM 2186 communicate with a suite of user apps 2180, including a menu ordering app 2182. The volumetric framework 2148 also operates with an in-service system 2190 which communicates with an in-service app 2194 connected to a payments gateway 2196, the in- service system 2194 also being in communication with a docket printer 2192.

[0348] Returning to the restaurant dashboard 2156, the dashboard includes (amongst other components not shown in Figure 21 b) a menu availability setup module 2158 which includes the ability to input a set of menu availability constraints via interface 2162, the module 2158 interacting directly with the menu database 2174 via logic 2161 to allow the interface 2162 to access data captured in database 2174. The dashboard 2156 also includes a menu setup module 2160, which includes the ability for the staff member to enter input information regarding menus, booking constraints, etc. via interface 2164 and also the ability to enter product pricing by menu via interface 2166, which is then translated using logic 2170 and saved in database 2174. The menu availability setup module 2158 accesses menu database 2174 via logic 2161 to inform the input fields rendered for the menu availability setup module interface. Utilising logic 2168, the menu availability constraints, as well as specific data captured in menu database 2174 are saved to the volumetric framework database 2148 for the relevant date, service and seating.

[0349] Referring to Figure 21 c, there is shown a flow chart depicting a menu setup and posting process in accordance with an embodiment of the invention. To begin, a staff member is required to set up three components. The three components may be set up contemporaneously or independently of one another, but all three must be set up in order for a menu to be created and posted to the volumetric framework. As a menu must be based on one or more products, the staff member must set up (or access a pre-existing) product or products. At step 2109, the staff member creates product sizes, then at step 211 1 the staff member inputs information to create a product (described elsewhere in the present specification) and subsequently associates product sizes with products at step 21 13.

[0350] The staff member, to subsequently create a menu, must create menu headings at step 2101 and contemporaneously, creates menu folders at 2103. As explained above, the process of creating menu headings and menu folders may occur at different times or contemporaneously, but both steps must be taken before a staff member may proceed to create a menu. At step 2105 the staff member may create duration menus and at step 2107 the staff member may create non-duration menus. Subsequently, the staff member may add menu headings and menu subheadings to duration menus and non-duration menus at step 21 15, after which products by size may be added to duration menus and non-duration menus, grouped by menu headings and menu subheadings at step 21 17. Duration constraints by course and by number of people for a booking, may then be added to duration menus at step 21 19, and table class constraints are added to duration menus and non-duration menus at step 2121. Subsequently, the staff member may associate product pricing by size or by menu at step 2123, and a menu posting set is created at step 2125 according to required restaurant service variability. At step 2127 duration menus are added to a posting set by meal period, and at step 2129 non-duration menus are added to the posting set, by meal period and linked to duration menus. At step 2131 menu availability by specific times is set for each menu, and at step 2133 the maximum number of people by time interval, per menu is set for each posting set. The menu posting sets are subsequently posted to the calendar at step 2135 (for posting see Figure 7b) and subsequently, at step 2137, the posted menus are accessed by date and service, via the menu ordering app or widget, when the app or widget interfaces with the booking system.

[0351] Referring to Figure 22a, there is shown a flow chart depicting a pre-ordering methodology in accordance with an embodiment of the invention. Figures 22a-d illustrate a pre-service menu pre-ordering flow in accordance with an embodiment of the invention. When a booking is created at step 2200, a booking confirmation email 2202 is sent including an option to invite guests at step 2204. When the user clicks on the link to pre-order, a pre-ordering widget or app 2206 is launched on the user’ device. The app determines if a menu has been selected at step 2208. If not, the customer selects from a menu at step 2210. Once a menu has been selected (or if the menu has been pre-selected) the process continues to step 2212 where the customer selects one non-duration menu. The customer then selects, at step 2214 if they want to allow guests to pay during the pre-ordering process. The customer then inputs guest details at step 2216 before the process proceeds along arrow 1 (which connects to the process flow diagram of Figure 22b).

[0352] Referring to Figure 22b, there is shown a flow chart depicting a pre-ordering methodology in accordance with an embodiment of the invention. Figure 22b is a continuation of the process flow of Figure 22a. At arrow 1 , the process sends invitations at step 2218 and the pre-ordering is enabled for the customer and the customer's guests at step 2220. Thereafter, two contemporaneous processes occur (i.e. they are capable of occurring at the same time, although it will be understood that the actual steps may occur at different times, as some steps depend on customer and/or guest input, and such input may occur at different times). At step 2254, the customer's guests receive an invitation email and the guest can click a link in the email to pre-order at step 2256. The clicking of the link opens a widget and/or app‘A (2258) which provides an order summary 2260 for all guests. The guest may click the add items from the menu link at 2262, at which time menus are displayed in the app and/or widget at step 2264, before the process continues along arrow 2 (which is continued in Figure 22c).

[0353] Contemporaneously, at step 2222, the customer receives an invitation email and confirmation that guests can pre-order and the customer can click a link in the email to pre-order at step 2224. The clicking of the link opens a widget and/or app Έ' which provides an order summary 2226 for the customer and all guests. The customer may click the add items from the menu link at 2228, at which time menus are displayed in the app and/or widget at step 2230, before the process continues along arrow 3 (which is continued in Figure 22c).

[0354] Referring to Figure 22c, there is shown a flow chart depicting a pre-ordering methodology in accordance with an embodiment of the invention. The flow chart of Figure 22c is a continuation of the process flow of Figure 22b. Arrow 2 continues the process at step 2266, where pricing and payment options are displayed based on the customer's guest payment selection. At step 2268, a determination is made as to whether the customer has allowed the guest to pay. If not, then at step 2290, a determination is made as to whether pre payment is required. If not, then the process continues to step 2274, where the guest selects and submits selected menu items, before the process continues along arrow 4 which is described with reference to Figure 22d. Returning to step 2290, if pre-payment is required, a guest adds their items to the order at step 2292 before the process continues along arrow 5 which is described with reference to Figure 22d.

[0355] Returning to step 2268, if the guest is permitted to pay, a determination is made as to whether pre payment is required at step 2270. If not, the process goes directly to step 2274, where the guest adds and submits menu items to the order, before the process continues along arrow 4 which is described with reference to Figure 22d. If pre-payment is required, the process proceeds to step 2272, where the guest submits payment details prior to proceeding to step 2274 (previously described). At step 2274, in addition to proceeding along arrow 4, the guest may also order more by clicking the order more link at step 2276, or the guest may close the widget and/or app by clicking the close link at step 2278.

[0356] Arrow 3 continues the process at step 2232, where pricing and payment options are displayed. At step 2234, a determination is made as to whether pre-payment is required. If not, the process goes directly to step 2238, where the customer adds and submits menu items to the order, before the process continues along arrow 6 which is described with reference to Figure 22d. If pre-payment is required, the process proceeds to step 2236, where the customer submits payment details prior to proceeding to step 2238 (previously described). At step 2238, in addition to proceeding along arrow 6, the customer may also order more by clicking the order more link at step 2240, or the customer may close the widget and/or app by clicking the close link at step 2242.

[0357] Referring to Figure 22d, there is shown a flow chart depicting a pre-ordering methodology in accordance with an embodiment of the invention. At arrow 4, which is a continuation of arrow 4 of Figure 22c, a check is made at step 2280 to determine whether payment has been sent. If so, then the process proceeds to send a pre-order summary email and receipt 2282 to the guest with a link 2284 to allow the guest to amend their pre-order, before the process loops back to‘A (shown in Figure 22b). If not, then the process proceeds to send a pre-order summary email 2286 to the guest with a link 2288 to allow the guest to amend their pre-order, before the process loops back to‘A (shown in Figure 22b).

[0358] At arrow 5, the customer received, at step 2294, an email request to provide payment details for the guest order, with a link 2296 to navigate to the payment page. When the customer clicks the link 2296, the pre-order app and/or widget is opened at step 2298 and at 22100 the customer submits the required payment details. Thereafter, the guest receives an email at 22102 with a pre-order summary and is provided with a link 22104 to edit the pre-order, which, if clicked, loops the process to arrow A' of Figure 22b. Contemporaneously, the customer receives an email with a summary of the pre-order at step 22106, before the process ends at step 22108.

[0359] At arrow 6, which is a continuation of arrow 6 of Figure 22c, a check is made at step 2244 to determine whether payment has been sent. If so, then the process proceeds to receive a pre-order summary email and receipt 2246 to the customer with a link 2248 to allow the customer to amend their pre-order, before the process loops back to‘B’ (shown in Figure 22b). If not, then the process proceeds to receive a pre-order summary email 2250 to the customer with a link 2252 to allow the customer to amend their pre-order, before the process loops back to Έ' (shown in Figure 22b).

[0360] Referring to Figure 23a, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. At 2302 there is shown generally a confirmation screen 2302 including a confirmation message 2304. The user may update or cancel their booking by using button 2308 and invite guests and pre-order by using button 2310. If the user selects the option to invite guests and pre-order, they are shown their booking details at screen 2314, including details regarding the booking at 2316 (including restaurant, date, time, etc.) and they are provided with non-duration menus to select from in area 2318, which in the example screen of Figure 23a, includes a wine list pull down menu 2320 and a beverage menu 2322.

[0361] Referring to Figure 23b, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention, which is associated with the screens shown in Figure 23a. The user is also shown an invite your guests screen 2324, which allows the user to select a seat to allocate to themselves using pull down menu 2326 and can then enter guest details at 2328 including to select a seat to allocate to a guest and send an invitation to the guest using button 2330.

[0362] Referring to Figure 24a, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. There is shown a mobile version of an ordering app 2400 which allows the user to log in by using their booking reference number, which can be entered at input box 2402, or their email address, which can be input at 2404. Once the user is logged in, they are taken to an upcoming bookings screen 2406 which shows bookings (in the example of Figure 24a, bookings 2410, 2412 and 2414 are shown). The user may navigate away from the upcoming bookings screen using icon 2408.

[0363] Referring to Figure 24b, there is shown an end user (customer) interface screen for a mobile device depicting an interface 2415 in accordance with an embodiment of the invention which is a continuation from Figure 23b. The user may select the pre-order button 2416, in which case they are taken to the second screen of Figure 24b (2419), which displays the booking details at 2420, and lists guests at 2421 , allowing the user to view more information regarding the guests by selecting arrow 2422. The user may also begin the pre-order process by selecting button 2424.

[0364] If the user would prefer to use the Resbutler app (rather than a web browser interface, the user may download the Resbutler app by using button 2417, at which time the download process is initiated as shown by box 2418.

[0365] Referring to Figure 24c, there is shown an end user (customer) interface screen for a mobile device depicting an interface 2425 in accordance with an embodiment of the invention. In Figure 24c, the pre-ordering screen is shown, which is displayed when the user selected the pre-order button 2424 of Figure 24b. The booking information is displayed at area 2426, and various menus are selectable by selecting tabs 2428, 2429, 2430 and 2432. In the example screen shown, tab 2428 is selected, as shown by the underlining. The user may then navigate directly to sub sections within the menu by using icons 2434, and the selected sub section is shown generally at 2436, with menu items 2438 displayed. Further sub sections may be displayed depending on the size of the screen, as shown at 2440. A summary of items selected is displayed in area 2442. If the user selects area 2442, they are taken to a summary screen 2444 which includes tabs 2446 and 2448 and shows a summary of items (such as 2452) under sub section headings such as 2450, 2454 and 2456. A total amount is displayed at 2458 and the user may submit the order by using button 2458.

[0366] Referring to Figure 24d, there is shown an end user (customer) interface screen for a mobile device depicting an interface 2459 in accordance with an embodiment of the invention, which is the screen displayed when the user clicks the submit button 2458 of Figure 24c. In the example shown, the user is asked for pre payment by pop up screen 2460 and may pay using any appropriate technology, such as an integrated payment solution 2462. The user may also elect to cancel the order at 2464. Once the user has paid and the payment has been processed, confirmation is provided at 2466 and the user may navigate away from the confirmation screen using button 2468.

[0367] Referring to Figure 24e, there is shown an end user (customer) interface screen for a mobile device depicting an interface 2469 in accordance with an embodiment of the invention. In the example of Figure 24e, the ordering process has occurred, and the user can add more menu items to their pre-order by selecting button 2474, or can view or edit the order summary by selecting arrow icon 2472. If the user chooses to vary or view the pre-order, they are taken to screen 2476, and are shown that they have pre-ordered and paid for items such as shown at 2478. A total is also shown at 2480.

[0368] Referring to Figure 24f, there is shown an end user (customer) interface screen for a mobile device depicting an interface 2481 in accordance with an embodiment of the invention. In the example of Figure 24f, the ordering process has occurred, and the user can edit a guest's order 2482 by selecting button 2484. If the user chooses to vary or view the guest's pre-order, they are taken to screen 2486, and are shown that the guest has pre-ordered either personally if tab 2488 is selected, or for the table if tab 2490 is selected. A total is also shown at 2492.

[0369] Referring to Figure 25a, there is shown a flow chart depicting an in-service menu ordering methodology in accordance with an embodiment of the invention. As explained previously, a user may also order in the restaurant during service, by utilising their app and/or widget (if operated via a web browser). The guest arrives at the restaurant at step 2500, and the system verifies the arrival of the guest at 2502. The verification may occur in any number of manners, including via self-seating kiosk, via the app or widget, or via some other technology, including a geofencing technology (i.e. the system detects that the user's mobile device is within the restaurant) or via facial recognition technology (i.e. the system detects that the guest has entered the restaurant by scanning the face of all guests who enter).

[0370] The arrival of the guest triggers notifications and prompts the user to begin their ordering process, as detailed at step 2504. Once the order is complete, the order is sent to the kitchen at step 2506. Upon attempting to send the order to the kitchen, the system checks to determine whether all orders for all guests associated with a booking have been received at step 2508. If not all orders have been received, a notification is sent to all users who have not ordered at step 2510, and after a defined period of time, the system re-checks to determine if all orders have been received by looping back to step 2508. If all orders have been received, the process continues along arrow 1 , which is described with reference to Figure 25b.

[0371] Referring to Figure 25b, there is shown a flow chart depicting an in-service menu ordering methodology in accordance with an embodiment of the invention which is a continuation of the ordering process of Figure 25a. Continuing along arrow 1 , once all orders for stage 1 are received, they are prepared and served at step 2512. The system then verifies that all orders have been consumed, either by setting an arbitrary time for consumption, or utilising more intelligent systems, such as image recognition, to determine whether all orders have been consumed, as shown at step 2514. Once step 2514 is completed, the system checks, at step 2516, whether all subsequent orders have been sent to the kitchen. If not all orders have been received, a notification is sent to all users who have not ordered at step 2518, and after a defined period of time, the system re-checks to determine if all orders have been received by looping back to step 2516. If all orders have been received, the process continues to step 2520, where the system determines if the users have pre-paid. If not, the system notifies the users of the need to pay and provides payment options. Thereafter, once payment is received and the meal has finished, the process ends at step 2524

[0372] Referring to Figure 26a, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention, which illustrates example screens that would be seen by a user when they are in the restaurant and using the in-service ordering system. For example, at 2600 there is shown a notification, such as the notification sent by the system at step 2510 described with reference to Figure 25a. Once the user clicks the notification 2600, a popup screen 2602 is displayed reminding the user to order their first and second courses. The user is then directed to the screens described with reference to Figure 26b.

[0373] Referring to Figure 26b, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. There is shown a screen 2606 providing details of a specific booking, details being shown at 2608. As indicated at 2610, if a user has pre-paid, there is shown a summary of items bought, which can be expanded using arrow 2612. There is also a summary shown of items added to the bill at 2614, and a summary of items sent to the kitchen at 2616. The user may order items by clicking button 2618 and may review the bill (both pre-paid items and items to be billed) by clicking button 2620. If the user clicks the arrow 2612, they are taken to order summary screen 2622, which includes tabs 2624 and 2626. In the Figure, the For Yourself tab is selected, which displays all items chosen (such as 2634 and 2639) under subheadings 2628, 2632 and 2638. A total including cost is displayed in area 2640.

[0374] Referring to Figure 26c, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention, where the user may order items from a menu in-service. The user is provided with the booking summary at 2642 and may access different available menus by using tabs 2644, 2645, 2646 and 2647. Within each menu, the user may directly access sections by using buttons 2650, and the selected section is displayed, as an example, at 2652, Menu items are displayed at 2654 and a summary of the running total of items selected is displayed at 2656. [0375] Referring to Figure 26c (2657), there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. There is shown a detail screen for a particular menu item (2659). An image of the menu item may optionally be shown at 2658, and a description and price are provided at 2660. If certain cooking instructions are necessary, they can be selected at area 2662 and optional condiments and modifications to the menu item can be input by the user at areas 2664 and 2670. If an option, such as 2666, requires an additional payment, it is displayed at 2668.

[0376] Referring to Figure 26d, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. There is shown a detail screen for a particular menu item where the user may also select a quantity, as shown at 2672. The user, in this example screen, may also select the course at which the menu item is to be provided at 2674, and may also decide to provide it for themselves, or for the table at 2676 and 2678 respectively. This option is specifically designed for restaurants where dishes are intended to be shared amongst diners at a table. The user may add the menu item by selecting button 2680, which is then added to the total on the main menu screen, as shown at 2682.

[0377] Referring to Figure 26e, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. Returning to the selected items screen 2684, the screen is divided into subheadings 2686, 2690 and 2696, displaying selected items such as 2692. There is also shown items that have been pre-ordered and pre-paid 2694, and once the order is sent to the kitchen, this is displayed at 2698, along with a summary of items that have been pre-paid 26100 and items ordered in-service 26102. If a user has not selected an item (such as 2688) and it appears that this may be an oversight, the user is prompted at 26104 to confirm that their omission is purposeful, and the user may return to the menu to order (if it is an oversight) by using button 26106, or may alternatively confirm that the omission is purposeful by selecting button 26108, which causes the order to be sent to the kitchen by the system.

[0378] Referring to Figure 26f, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. Once the user has instructed the system to send the order to the kitchen, they receive confirmation at 26110 and may return to the menu by selecting button 261 12, at which time they are sent back to the initial screen including the booking details 261 14, summary details of the order being displayed at 261 16 and 261 18, including confirmation that the order has been sent to the kitchen at 26120. The user may see the details of the order by selecting arrow icon 26122 and may view the bill by selecting button 26124.

[0379] Referring to Figure 26g, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. If the user selects to view the details of the order by selecting arrow icon 26122 of Figure 26f, they are taken to the screens of Figure 26g, where an order summary is shown at 26126, including course information 26128, 26130 and 26139, item information 26136, confirmation that the order was sent to the kitchen 26132 and the current status of the order 26134, confirmation of whether the item has been pre-paid 26138, and a summary of total cost 26142, the number of pre-paid items 26144 and the items added in-service 26146. [0380] Referring to Figure 26h, if the user elects to close the app and someone has not ordered, the app will provide a notification 26148 to that effect. There is also shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. In the example screens shown, at 26150 a notification is provided to remind the user that orders for a course are due, and as can be seen at 26152 of Figure 26i, further notifications may be provided once a certain amount of time has elapsed.

[0381] Referring to Figure 26i, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. In the example screens shown, at 26154 an alternative notification is provided to remind the user that orders for a course are due, and as can be seen at 26156 of Figure 26j, further alternative notifications may be provided once a certain amount of time has elapsed.

[0382] Referring to Figure 26j, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. The user may select for a menu item, a course for the menu item to be served during, at area 26158 by selecting the available courses such as 26160. In the example shown, as the meal has already progressed beyond the first and second courses, only a third course option is displayed.

[0383] Referring to Figure 26k, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. If a guest has not been seated by a certain time during the service, the system may send a notification to the guest or the customer, as at 26162 asking the guest or customer to confirm the arrival of their guest via pop up 26164, by either confirming the guest intends to arrive by selecting the button at 26168, or informing the system that the guest has cancelled by selecting the button at 26166.

[0384] Referring to Figure 26I, there is shown an end user (customer) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. If the user wishes to convey a message to the restaurant (in a situation where a staff member is not immediately available), the user may select the speech bubble icon 26170 and be taken to a messaging pop up 26172, where messages may be exchanged with the staff member or chatbot, either via text (as shown generally by messages 26174, 26176 and 26178) or via voice recognition using the icon 26180. It will be understood that the messaging function may interact directly with the booking or in-service system (e.g. where a request is made to change a booking), in which case the messaging service is automated and the booking or in-service system takes action as required, or in certain circumstances, when the message conveys information that cannot be acted upon by the system, the message may be relayed to a staff member (e.g. a notification may appear on the in-service app on the device under the control of a staff member).

[0385] Referring to Figure 27a, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. The mobile interface displayed at Figures 27a-m generally are directed to an in-service app utilised by staff of the restaurant to manage various aspects of the restaurant during service. Referring to Figure 27a in particular, there is shown an interface 2700 for a selected restaurant, with a specific restaurant staff member logged into the interface at 2702. The staff member may select a date of service 2704 and a service period 2706 or may access other information by using icon 2708. The staff member may then elect to display the floor plan 2716 and may turn "on or off” certain areas of the restaurant by using pull down menu 2710. There is provided a slider 2720, which provides a dynamic floor plan. As the slider is moved along (the slider representing time), the restaurant layout automatically changes to reflect the layout at any given time during the service period, including bookings and other information necessary to operate the restaurant. The other information may be selectively turned "on or off using pull down menu 2712, and the staff member may also choose to see a more traditional booking list by selecting icon 2714.

[0386] Referring to Figure 27b, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. Where the staff member has elected to see the booking list, a list is shown, including tabs 2724, 2726 and 2728, allowing the staff member to filter information. Information regarding bookings is shown at 2730, with particular icons, such as 2739, indicating the status of the booking (e.g. not yet arrived, just seated, meal in progress, departed, etc.). Moreover, other information such as the status of the guests can be displayed in a summary form (e.g. SVIP at 2738 and MO at 2740).

[0387] Referring to Figure 27c, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. Where the staff member manually seats guests, the staff member may update the status of a booking by selecting icons, such as arrived 2742, partially seated 2744 or seated 2746. The staff member may also elect to go back by selecting 2748.

[0388] Referring to Figure 27d, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. Where the staff member has updated the status of a booking, the updated status is shown, as in, for example, 2750.

[0389] Referring to Figure 27e, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. Figure 27e provides an alternative manner in which to view information, whereby a staff member can select an individual table/booking from the floor plan, and view information regarding the table/booking. For example, the tab 2756 allows the user to view guest information for the table as shown in diagrammatic form at 2758. The information can include guest names 2762, the items paid for by the guest 2764, or the fact that no items have been ordered at 2766. The staff member also has access to a menu via 2768, and may view different menus by selecting tabs 2770, 2772 and 2774, and sub-sections using buttons 2776, such as sub section 2778, and is provided with a full menu including menu items 2780 and price 2782. The staff member may also seat users by using button 2754.

[0390] Referring to Figure 27f, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. If the staff member wishes to view more information about the guest, including their status 2786, their membership level 2788, their membership number 2790, previous information about their visits to the restaurant 2792, their phone number 2794, their seating preferences 27100 and 27102, their allergies 2796 and dietary requirements 2798 and their last visit 27104. The staff member may also request more detailed information about their booking history by selecting button 27106 or edit the guest's CRM entry using button 27108. [0391] Referring to Figure 27g, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. The staff member can click the booking information tab 271 10 and view information regarding the customer and the booking in pane 271 12, including contact details at pane 27134 and any concierge services ordered at pane 27136. The staff member may also edit the booking information by clicking on the edit booking button 27138.

[0392] Referring to Figure 27h, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. By clicking on the menu tab, the staff member can add menu items to the order by guest and position number and can also review various options such as cooking instructions. For example, in Figure 27h, the staff member, upon selecting position number 2, as shown at 27144, can see the order 27142 and can also choose cooking instructions at 27146.

[0393] Referring to Figure 27i, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. In a similar manner to Figure 27h, in Figure 27i it can be seen that the staff member may also scroll down to view further modifications at 27148, vary the quantity 27150 by using the minus and plus sign icons (27152 and 27154 respectively) and also associate the menu item with a course at 27156. In some embodiments, the staff member may also make the item complimentary by clicking check box 27158 and can also view the additional price at 27160.

[0394] Referring to Figure 27j, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. As can be seen, by clicking the order summaries tab at 27162, the staff member can see the order for each position, selecting a position by using tabs 27164. In the example shown, the staff member can see that no first course was ordered at 27166, and that the second course 27168 had specific cooking instructions 27170 and an optional item 27172. The staff member can also see the total price 27174 and can elect to send the order to the kitchen by selecting button 27176.

[0395] Referring to Figure 27k, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. In another example of the manner in which a staff member may view the orders of the guests at a particular table, by electing the bill tab 27178, the staff member can then use tabs 27180 to select the manner in which the bill is viewed. In the example screen of Figure 27k, the product 27182, position of the guest 27184, course 27186, quantity 27188 and price 27190 are arranged in a table as shown. The staff member may apply discounts or promotions using button 27192 and may also elect to process payment for the bill by selecting button 27194.

[0396] Referring to Figure 27I, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. When the staff member scrolls down in the Figure of 27k, they are shown a subtotal 27196, any surcharges 27198 and a total 27200.

[0397] Referring to Figure 27m, there is shown an operator (venue) interface screen for a mobile device depicting an interface in accordance with an embodiment of the invention. Upon choosing to pay the bill, there is presented a bill frame including the bill total amount displayed in general area 27206. The user is presented with a large array of payment options, including credit card 27212, debit card 27214, cash 27216, placement on an internal account 27218, gift card 27220, loyalty points 27222, Alipay 27224, PayPal 27226, part payment 27228 and may also print the bill 27230, email the bill 27232 or void the bill 27234.

[0398] Referring to Figure 28a, there is shown a flow chart depicting an in-service table allocation and menu ordering methodology in accordance with an embodiment of the invention. The customer may arrive in one of two manners, either checking in through a self-seating kiosk 2800 or arriving at the restaurant at step 2802 and being recognised by facial recognition technologies at step 2804. Thereafter, the booking is marked as arrived at step 2806 and the customer is directed to their seat at step 2808. The customer sits at the table at 2810 and facial recognition is utilised to determine the seat position of each guest at step 2812 and subsequently their position is notified at step 2814.

[0399] Referring to Figure 28b, there is shown a diagrammatic representation of a system in accordance with an embodiment of the invention. The flow chart and method steps generally described at Figure 28a is depicted in Figure 28b with reference to physical items. Customers, such as customers 2816 approach a kiosk 2820 and make a booking request, inputting information into the kiosk in a conventional manner (e.g. by using a touch screen interface), after which the booking request is received by, and a booking is determined by, the table allocation system 2822 using the CRM database 2824 to produce a message 2818. The user sits themselves at the relevant seat 2836. Similarly, two other guests 2830 check in via the app 2831 which is also connected to the table allocation system 2822 and the CRM 2824. Cameras 2832 capture images and provides the images to the table allocation system to allow the system to identify the guests, such that they may be seated at table 2838.

[0400] Referring to Figure 28c, there is shown a diagrammatic representation of a system in accordance with an embodiment of the invention. Figure 28c in particular shows an in-service use of the ordering system. A user has a device 2840, which is connected via the cloud to the menu ordering app 2844, which in turn is in communication with the table allocation system 2846 and in turn is connected to the POS and transactions system 2848 which is in communication with the menu database 2850. The device 2840 is arranged to receive notifications such as the notifications shown at boxes 2842 and 2843. Users may also be recognised utilising a recognition system such as cameras 2852, which are arranged to communicate information to the table allocation system, to provide additional or ancillary information to the table allocation system as required.

[0401] Referring to Figure 28d, there is shown a flow chart depicting a facial recognition methodology in accordance with an embodiment of the invention. In the flowchart, as a first step 2862, facial recognition technology identifies the customer, after which, at step 2864 the image recognition utilises markers to identify specific spaces within the venue and associate the customer with the specific space, such that the customer movement in a restaurant space may be tracked. The customer(s) will seat themselves at an allocated table at step 2866 and the system will identify which customer is seated at each particular seat at the allocated table at step 2868, sending the identified seat to the table allocation system at step 2870. If required, the table allocation system can then update all relevant databases and provide updated reporting (such as to the kitchen) at step 2872. If all customers are not yet present, the booking status is marked as arrived at step 2876 Alternatively, if all customers have arrived, the booking status is changed to seated at step 2878. If one or more customers switch positions at step 2880, then the image recognition system sends updated seating position information to the booking allocation system at step 2882 and the booking system updates all relevant modules at step 2884. In this manner, correct orders using correct position numbers can always be taken by the system at step 2886.

[0402] Referring to Figure 28e, there is shown a flow chart depicting an in-service menu notifications methodology in accordance with an embodiment of the invention. In the flowchart, as a first step 2888, a customer sends an order for a course via the menu ordering app, and the order, at step 2890, appears on the kitchen or bar docket and are subsequently communicated to the kitchen or bar at step 2892. The food, once prepared, is delivered to the customer at step 2894. Facial recognition technology is utilised to track and identify a customer consuming their order at step 2896 and period checks are made at step 2898 to determine whether the customer has consumed their course and/or meal at step 2898. If not, the system loops back to step 2896. If the meal is finished, the status is communicated at step 28100 to the booking system. If the course is the last course for the booking as determined at step 28102, the booking allocation system contemporaneously sends specific instructions to the waiter to clear the table at step 28104 and sends a payment prompt to the customer at step 28106. The customer may then finalise payment at step 28108. Alternatively, if it is not the last course, the booking allocation system contemporaneously sends specific instructions to the waiter to clear the table at step 281 10 and sends a prompt to the customer to order their next course at step 281 12. The customer may then start ordering their next course via the app at step 281 14.

[0403] Referring to Figure 28f, there is shown a diagrammatic representation of a system in accordance with an embodiment of the invention. Figure 28f in particular shows an in-service use of the progress of a meal and/or service. A user has a device 2882, which is connected via the cloud to the menu ordering app 28122, which in turn is in communication with the table allocation system 28120 and in turn is connected to the POS and transactions system 281 18 which is in communication with the menu database 281 16. The device 2882 is arranged to receive notifications such as the notification shown at box 28124. A camera (28125) is able to track the progress of a meal which communicates to the table allocation system 28120, which in turn may send notifications such as 28126 to devices such as 28127. Similarly, the cameras such as 28123 can track other meals such as 28128 and send notifications to other phones associated with the other meals, such as phone 28130.

[0404] Referring to Figure 29a, there is shown a diagrammatic representation of a system in accordance with an embodiment of the invention. In one embodiment, the ordering system (in-service or pre-ordering) can work across multiple devices and synchronise an order such that the restaurant receives a single order from multiple parties. In the example of Figure 29a, four devices 2900, 2912, 2918 and 2924 utilised by four different users synchronise an order. This is achieved by having a primary or master device 2900 which has an ordering app 2901 which allows the primary user to invite secondary users at step 2902, select their own order at 2904, review secondary orders and approve or reject them at 2906, and submit the consolidated or synchronised order at 2908 after which the process ends at 2910. Each of devices 2, 3 and 4 (2912, 2918 and 2924 respectively) have an instance of an ordering app (2913, 2919 and 2925 respectively) which allows the user to accept the invitation (2914, 2920 and 2926 respectively) and select and finalise an order (2915, 2922 and 2927 respectively), before the order summary is sent to the primary user at 2930. [0405] Referring to Figure 30a, there is shown a dashboard (venue) interface screen depicting a dashboard interface in accordance with an embodiment of the invention. Figure 30a shows a dashboard 3000 which includes a view menus button 3002.

[0406] Referring to Figure 30b, there is shown a dashboard (venue) interface screen depicting a dashboard interface in accordance with an embodiment of the invention. When the staff member clicks the view menus button 3002 of Figure 30a, they are presented with a pop up screen 3004 which includes one or more menus 3010, including number of courses 3012, the relevant classes 3014 and the availability by time 3016. The staff member can close the pop up using cross icon 3006 or see more detail about the menu by clicking the open menu button 3008.

[0407] Referring to Figure 30c, there is shown a dashboard (venue) interface screen depicting a dashboard interface in accordance with an embodiment of the invention. When the staff member clicks the open menu button 3008 of Figure 30b, they are provided with the pop up window shown at 3018, which is the menu. The staff member can view the menu as the customer would view the menu (i.e. the same layout including headings 3022 and menu items 3024) but is able to turn "on or off specific menu items by using toggle switches such as toggle switch 3026, and is also able to add specials such as 3028 by selecting the add special button 3020 and remove specials by selecting the remove specials button 3030.

[0408] Referring to Figure 30d, there is shown a dashboard (venue) interface screen depicting a dashboard interface in accordance with an embodiment of the invention. When the staff member selects the add special button 3020 of Figure 30c, they are presented with the add special screen 3032. The staff member may filter by product group by selecting a product group from pull down menu 3034, with products from the group being displayed in column 3036, with associated prices for different product sizes (where applicable) being provided in columns 3038 and 3040. Upon selecting a special, information regarding the special is displayed in area 3042 with price being displayed at 3044 (including the ability to override the price). Moreover, the staff member can select under which heading the special is to appear by using pull down menu 3046. Once the staff member has selected all relevant options, the staff member can save the selection using save button 3048.

[0409] Referring to Figure 30e, there is shown a dashboard (venue) interface screen depicting a dashboard interface in accordance with an embodiment of the invention. If the user selects the override price link 3044 of Figure 30d, a pop up window 3052 appears within the add special pop up 3050, which allows the staff member to enter a PIN or other authorisation code or password at text box 3054, and select the enter button 3056 to add the special.

[0410] Referring to Figure 30f, there is shown a dashboard (venue) interface screen depicting a dashboard interface in accordance with an embodiment of the invention. If the staff member successfully entered their PIN as per Figure 30e, a pop up box is displayed within the general add special pop up box 3058, which confirms the special information at 3060, displays the original price at 3062 and allows the staff member to apply a new price by using text box and button 3064.

[0411] Referring to Figure 30g, there is shown a dashboard (venue) interface screen depicting a dashboard interface in accordance with an embodiment of the invention. Once the staff member has proceeded through the steps and screens of Figures 30e and 30f, the staff member is returned to screen 3066, where the standard price is shown at 3068 and the override price also is shown at 3070.

[0412] Referring to Figure 30h, there is shown a dashboard (venue) interface screen depicting a dashboard interface in accordance with an embodiment of the invention. If the staff member wishes to view information regarding a specific table, the staff member selects the table as shown the floor plan and is presented with the pop up 3072 generally shown in Figure 30h. The pop up includes a representation of the table including table number 3086, a representation of each chair as shown, for example, by 3084, and information regarding the table at 3076 (table class), 3078 (special conditions), 3080 (transaction type) and 3082 (available menus). Such information provides the staff member with a quick but useful overview of the table and constraints associated with the table. The staff member may allocate a booking directly to the table (i.e. manually) by selecting the new booking button at 3074.

Advantages

[0413] The embodiment and broader invention described herein provides a number of advantages:

[0414] Firstly, the embodiment provides a structured and fundamentally different way to create menus, by being within or attached to a booking allocation system, and with the menus being treated as part of an accounting or transaction system.

[0415] Secondly, the embodiment provides a means to provide individualised menus specific to users by offering alternate and alternatively described menu items to cater for allergies, dietary requirements and dietary preferences, permitting the offering of alternate menu items which can be integrated as part of a transaction system or a stock control system or purchasing system.

[0416] The embodiment also provides for an interactive booking process which includes personalised interactive menus, menu selections and the menu items selected as constraints within the booking allocation process, such that duration times and other menu information can impact the booking allocation process.

[0417] The embodiment provides, after the booking allocation process, a menu pre-ordering process whereby menu pre-order selections can be made, or existing menu pre-order selections can be changed, whereby those changes may or may not modify the original booking allocation and/or duration and/or its associated constraints and details.

[0418] The embodiment also provides for pre-ordered menu items to be stored within the booking allocation system and diary as more than just notes or text within the booking system, but as information that is integral to the financial systems within the accounting systems of a venue.

[0419] The embodiment also provides for the booking allocation system and diary to keep and store menu selections and payment information within it, such that there is no need to transfer this information to a point of sale system until a user is seated at a table, or for the processing of further transactions after a person is seated at a table within the booking allocation system and diary, whereby the booking allocation system undertakes the processes associated with finalising the transaction. [0420] The embodiment also permits the linking of the stock level of the ingredients to the menu items, such that where the levels of ingredients within a menu decrease to zero, the respective menu items are removed from the electronic menu automatically.

[0421] The embodiment also permits the linking of the status of cooking equipment or other equipment impacting menu choice selection, such that if a piece of cooking equipment is out of order, any associated menu items are removed from the personalised menu selection offered to the user/customer.

[0422] The embodiment is not limited to traditional menu items offered by a dine-in restaurant, but also includes other additional items such as the provision of flowers (that can be taken away at the end of the dining process, a personal waiter, entertainment, etc.), that are also linked to the booking allocation process and may also impact the duration time applied to the booking.

[0423] The use of the computer-enabled method, system and computer program disclosed herein has provided examples within the restaurant industry, however, they are equally applicable within other industries and businesses such as airlines, accommodation, hotels, travel, cruise ships, car rentals, clubs, pubs, gyms, hairdressers, workspaces, and the provision of advice and consulting services.

Disclaimers

[0424] Throughout this specification, unless the context requires otherwise, the word "comprise” or variations such as "comprises” or "comprising”, will be understood to imply the inclusion of a stated feature or group of features but not the explicit exclusion of any other feature or group of features.

[0425] Those skilled in the art will appreciate that the embodiments described herein are susceptible to obvious variations and modifications other than those specifically described and it is intended that the broadest claims cover all such variations and modifications. Those skilled in the art will also understand that the inventive concept that underpins the broadest claims may include any number of the steps, features, and concepts referred to or indicated in the specification, either individually or collectively, and any and all combinations of any two or more of the steps or features may constitute an invention.

[0426] Where definitions for selected terms used herein are found within the detailed description of the invention, it is intended that such definitions apply to the claimed invention. However, if not explicitly defined, all scientific and technical terms used herein have the same meaning as commonly understood to one of ordinary skill in the art to which the invention belongs.

[0427] Although not required, the embodiments described with reference to the method, computer program, computer interface and aspects of the system can be implemented via an Application Programming Interface (API), an Application Development Kit (ADK) or as a series of program libraries, for use by a developer, for the creation of software applications which are to be used on any one or more computing platforms or devices, such as a terminal or personal computer operating system or a portable computing device, a smartphone or a tablet computing system operating system, or within a larger server structure, such as a‘data farm' or within a larger computing transaction processing system.

[0428] Generally, as program modules include routines, programs, objects, components and data files that perform or assist in the performance of particular functions, it will be understood that the functionality of the method, computer program and computer interface defined herein may be distributed across a number of routines, programs, objects or components to achieve the same functionality as the embodiment and the broader invention claimed herein. Such variations and modifications are contemplated by the inventor and are within the purview of those skilled in the art.

[0429] It will also be appreciated that where methods and systems of the present invention and/or embodiments are implemented by computing systems or implemented across multiple computing systems then any appropriate computing system architecture may be utilised without departing from the inventive concept. This includes standalone computers, networked computers and dedicated computing devices that do not utilise software as it is colloquially understood (such as field-programmable gate arrays).

[0430] Where the terms "computer”, "computing system”, "computing device” and "mobile device” are used in the specification, these terms are intended to cover any appropriate arrangement of computer hardware for implementing the inventive concept and/or embodiments described herein.

[0431] Where the terms“software application”,“application”,“app”,“computer program”,“program” and "widget” are used in the specification when referring to an embodiment of the invention, these terms are intended to cover any appropriate software which is capable of performing the functions and/or achieving the outcomes as broadly described herein.

[0432] Where reference is made to communication standards, methods and/or systems, it will be understood that the devices, computing systems, servers, etc., that constitute the embodiments and/or invention or interact with the embodiments and/or invention may transmit and receive data via any suitable hardware mechanism and software protocol, including wired and wireless communications protocols, such as but not limited to second, third, fourth and fifth generation (2G, 3G, 4G and 5G) telecommunications protocols (in accordance with the International Mobile Telecommunications-2000 (IMT-2000) specification), Wi-Fi (in accordance with the IEEE 802.1 1 standards), Bluetooth (in accordance with the IEEE 802.15.1 standard and/or standards set by the Bluetooth Special Interest Group), or any other radio frequency, optical, acoustic, magnetic, or any other form or method of communication that may become available from time to time.