AU2021201972A1

AU2021201972A1 - A computer-enabled method, system and computer program for the management of a multi stage transaction including management of a booking and service delivery process

Info

Publication number: AU2021201972A1
Application number: AU2021201972A
Authority: AU
Inventors: Peter Petroulas
Original assignee: Grand Performance Online Pty Ltd
Current assignee: Grand Performance Online Pty Ltd
Priority date: 2019-04-29
Filing date: 2021-03-30
Publication date: 2021-04-29
Also published as: WO2020220073A1; AU2020200615A1

Abstract

An embodiment of the present invention provides a computing system for processing a plurality of variable transactions associated with a booking including the allocation of a space within a venue and a provision of one or more products and services utilising a volumetric space/time self-reconciling allocation framework over a future time period, the system comprising: a processor arranged to execute a booking allocation software module, the booking module being in communication with a product database including product information relevant to a plurality of products and services, the product and service information for each one of the plurality of products and services having an associated capacity and value within the volumetric space/time self-reconciling allocation framework, the booking module being arranged to request product constraint information related to one or more constraints provided by a booking requestor and retrieve associated product and service capacities and values from the database, and utilise the product and service capacities and values associated with the volumetric space/time self-reconciling allocation framework to determine product and service availability and a purchase price for the product and service in response to the constraints provided by the booking requestor and a user interface arranged to interact with the booking requestor and provide additional product information and additional information regarding one or more attributes to the booking requestor, wherein, if the booking requestor accepts the one or more additional attributes and requests allocation of the booking to the space on the basis of acceptance of the one or more additional attributes, the booking allocation module proceeds to allocate the booking to the space and provide a multi-payment module capable of receiving and reconciling multiple payments from multiple sources across a period of time, wherein the product, service and transaction information associated with a booking is associated with the booking information independently of the space to which the booking is allocated, wherein, the products, services and transactions associated to a booking self-reconciles all orders and all payments and presents a final account to the booking requestor or an authorised person.

Description

A COMPUTER-ENABLED METHOD, SYSTEM AND COMPUTER PROGRAM FOR THE MANAGEMENT OF A MULTI STAGE TRANSACTION INCLUDING MANAGEMENT OF A BOOKING AND SERVICE DELIVERY PROCESS

Cross Related Application

This application is a divisional application of Australian Patent Application No. 2020200615, filed on 29 January 2020, the content of which is incorporated herein by reference in its entirety.

Technical Field

[0001] The present invention relates to a system, method, computer program and data signal for managing one or more terms and conditions related to a payment process as part of a multi-faceted transaction involving one or more people acting independently or as part of a group or collective.

[0002] In one embodiment, the invention is directed to an online restaurant booking system and the payments that may be due and payable.

[0003] In one embodiment, the invention is directed to an on-line booking system and the person making the booking with the restaurant and the one or more people that have been invited to be part of the booking, and more specifically to the monetary interaction and relationship between the party who makes the booking request and the invited guests such that the system can take part payments, individual payments up until the time of the booking time and then after the booking time until the reservations is complete and the final payment is made.

[0004] In one embodiment, the transaction management system for managing one or more different terms and conditions related to individual constraints (in a restaurant context these can include; menu selected, courses selected, booking time, booking duration, table selected, area selected, group size, seating, service, day, customer details, etc.,) to determine the terms and conditions including payment terms to be applied to that specific transaction.

[0005] In one embodiment, the invention is directed to an online restaurant booking and management system that optimises the use of space and the operation of a restaurant through the use of one or more allocation methodologies la and algorithms.

[0006] In one embodiment, transaction management systems and methods that permit the alternate payment systems such as "after pay", "gift certificates, vouchers or cards" and techniques for any one or more payment due during the overall transaction process.

[0007] Embodiments of the system are directed the fields of online (e.g. web based) interactive systems, applications for mobile devices ('apps"), and/or software applications for transactions management

[0008] Embodiments of the invention are directed to the autonomous reconciliation of deposits, part-payments, and/or further payments made prior to the time that a multi-stage transaction is finalised.

Background - Transaction Management

[0009] To better understand the inventive concepts and embodiments of the invention described herein, an abridged history and of the restaurant industry and known booking systems may be found in an earlier filed PCT application PCT/AU2018/051168 (and co-pending PCT application PCT/AU2018/051169, PCT/AU2018/051170 and PCT/AU2018/051171), as well as in Australian provisional application AU2019/900128.

Background - Point of Sales Systems

[0010] Traditionally retail transactions have been handled at one point in time and at one location hence why the term "point of sale" was created. Traditionally, in a retail environment it was at a counter where a transaction was effected. At as time progressed, the pencil and paper to list the items selected and to calculate the payment due was replaced by a cash register

[0011] With the invention of the computers, and as computers have become more affordable the cash registers have been replaced by computers and these computers were called "point of sale systems".

[0012] Correctly, these new "cash registers" are referred to as "point of sale systems", as these "point of sales systems" were developed and expanded such that they became a core accounting and control system:

a) Product lists were created and stored within the computer as well as prices for each product so that individual products did not need to have the price displayed

b) Stock control was created through a process of adding stock purchased into the system. With this the system could then decrement stock, meaning that it knew how much stock was on hand at any point in time, this then permitted they were also the development of stock reorder quantities and purchasing modules, as well as the development of accounts payable modules within "point of sales systems"

c) As part of the expansion of the "point of sale systems" to stock and accounts payable the next process was the integration of point of sale systems into other financial accounting and management accounting modules such as an accounting "general ledger", the calculation of gross profit margins and revenue analysis from the sales information within the "point of sales systems".

[0013] With the growing importance of these point of sales systems and a recognition of the importance of regular customers, loyalty programs were built into these points of sales systems through an understanding and recognition that these points of sales systems represented the first time a customer made contact with a business and hence it was at this first point of contact that a business's loyalty program needed to be located. That point of contact being when a person went to a cash register located at a counter to pay for a transaction or went to a bar to order something such as the purchase of a drink.

[0014] With the incorporation of loyalty programs within point of sales systems and the recognition of customer loyalty and retention limited special pricing features were developed and incorporated such as member discounts, happy hour discounts, and package pricing. However, all these pricing structures were developed as simplistic discounts not as systems to assist with or permit product differentiation.

[0015] Point of sales systems have therefore grown from their original concept and application for the replacement of a cash register to one of the most important systems of any retail establishment, including restaurants, bars, fast food outlets, supermarkets, fashion, airlines, travel and hotels.

Background - Point of sales systems and the internet

[0016] With the introduction and growth of the internet many transactions are being conducted over the internet and these transactions simply been integrated into point of sales systems such that point of sales systems are still the fundamental sales systems.

[0017] With restaurants a major change has been the creation online booking systems which commenced from about 1998 with the Open Table system and from a systems perspective these restaurant online booking systems simply focused on integrating the booking information captured by these online booking systems into point of sale systems and these points of sales systems have maintained their position as the core sales system, loyalty system and customer recognition system.

[0018] This approach by the prior art of simply attempting to integrate online booking systems is completely incorrect as it fails to understand and appreciate the subtle changes that the internet has created. Specifically, and despite these online restaurant booking systems having been in existence since at least 1998 with the formation of Open Table, all prior art fails to recognise and fails to account for the following:

a) The prior art point of sale systems or any other prior art system cannot account for the fact that the first point of contact is now the internet and the online booking system and not the point of sale system located at a counter.

b) The prior art point of sales systems or any other prior art can not recognise a customer at the time a customer makes contact online to make a booking so that the customers details can be used in the booking allocation process.

c) The prior art point of sales systems and any other prior art can not recognise a customer at the time a customer makes contact online to make a booking so as to be able to recognise and apply any loyalty benefits, special terms and conditions or other information that can be used to personalise the online booking experience for the customer.

d) The prior art point of sales systems and any other prior art system cannot properly and effectively recognise pre-orders such that such items can be included within the sock control, re-order, purchasing and planning systems.

e) The prior art point of sales systems and any other prior art can not properly and effectively assist in the recognition of differentiating products so as to be able to recognise and apply dynamic pricing and are limited to simple discounting pricing policies.

f) Prior art point of sales systems and other prior art can only account for pre-payments, deposits, part payments and other prepayment financial transaction by "opening" accounts for such transactions to be applied to using complex reference numbers which need to manually tracked. These accounts can be referred to as "unearned revenue accounts". These unearned revenues and the amounts within them have to be applied consolidated and applied together with the last transaction within a group of transactions so that the item, booking, overall transaction can be finalised. This is a complex and cumbersome, manual and static process.

g) The prior art point of sales systems requires the detailed management and

h) Prior art point of sales systems and any other prior art do not appreciate the transactional changes in the dynamics that have been brought by the internet. For example, that a transaction is no longer focused at occurring at one location or at one point in time. Further, point of sales systems cannot properly account for the fact that a number of payment or financial transactions may occur prior to a final transaction being put through a point of sale system. From a restaurant perspective a person can request a booking be charged a deposit, then they can reorder and make a further payment before arriving at the restaurant at which time they can make further purchases. In this example, it can easily be seen that point of sales systems have gone from being the first point of contact with a customer to potentially being the last point of contact with a customer and if the customer has pre-ordered and prepaid their meal (food and beverage) the point of sale system would have nothing more to do than simply request dockets or messages for the food and beverages to be prepared.

[0019] As can be seen from the above that the scope, purpose and need of point for sales systems and other traditionally structured systems is no longer the same and in fact they represent a huge impediment in the creation of systems, methods and procedures to better handle pre-payments, pre-orders, part payments, consolidation of payments, split payments so as to support the new challenges brought about by the internet and the need to offer customers a more tailored experience not only from a payments perspective but also from a customer relationship management perspective, a stock control and re-order perspective, a revenue management and revenue analysis perspective, a forecasting perspective and an artificial intelligence perspective.

[0020] The prior art uses a double entry transaction and accounting system whereby each transaction is recorded using a debit and credit with both the debit and credit recorded on the same day at the same time to keep the integrity of the of the traditional double entry accounting system.

[0021] Further POS systems are designed to only record sales transactions on the day they occur and cannot account for the automatic reconciliation of pre payments of deposits and or part- payments. For example, the automatic reconciliation of the deposit paid during an on-line booking process when the customer completes their dining experience and the final account needs to be finalised.

[0022] Specifically, the use of the double entry accounting system for the payment of a deposit during an online booking process for a restaurant reservation requires the following steps to be undertaken. First the deposit or pre-payment for a restaurant reservation during the online booking process requires the following transactional steps to be processed. First the online booking is made and the booking requestor is advised of the requirement for a deposit to be paid with the following steps recorded:

a. The payment is processed, a receipt is issued to the booking requestor, b. The booking is recorded within the booking allocation system and any pre payment, pre-order or other item may be recorded as a note or as information within the booking allocation system. Deposits, prepayments and other booking details and pre-orders are all noted within the booking allocation systems as "information" and all "information" is not treated as part of the transactional information capable of audit, reconciliation and not part of the accounting records of the venue, c. The cash is subsequently transferred to the venues bank account, d. The venue recognises this transaction within its "general Ledger" by manually debiting the bank account with the amount of the cash and then crediting an account such as "deposits or payments received in advance". The details of the deposit may then be also manually be entered into a traditional POS system in another account of a similar name as that of the "General Ledger" for example "deposits or payments received in advance" such that the POS system is used as the transactional system for which to balance the General Ledger, e. When the booking requestor subsequently arrives for their reservation a "table account" is opened within the traditional POS for the transaction to be continued with additional items ordered. Then separately a person is required to manually search within the "deposits or payments received in advance" account within the traditional POS system and transfer any deposit or payment information to the "table account" so that on completion of the dining experience the "table account" can subtract any prepayments form any final payment requested.

[0023] As can be seen from the above process and steps there is significant manual intervention required within traditional accounting systems for the processing of payments received in advance. The process described above applied not only to deposits and pre-payments for restaurant reservations but also for many other deposits, and pre-payments for many other industries.

[0024] It can therefore be seen that the prior art is manual intensive and does not support the autonomous reconciliation of deposits and pre-paid accounts. A system which could support the autonomous creation of transactions and the autonomous reconciliation of account involving deposits, pre-payments etc., is long called for. To highlight the problem of the prior art in a different way POS system have been designed to process transactions at one Point In Time and hence why they have been called Point Of Sale Systems. These points of sales systems were never developed to be able to seamlessly account for multiple transactions related to one item or service. To cater for the transactional flexibility permitted by modern systems and the internet that necessitate the proper and efficient account of multiple transactions and multiple payments including split pre payments and subsequent payments and split payments, etc.

Summary

[0025] In a first aspect, the invention provides a computing system for processing a plurality of variable transactions associated with a booking including the allocation of a space within a venue and a provision of one or more additional products and services utilising a volumetric space/time self-reconciling allocation framework over a future time period, the system comprising: a processor arranged to execute a booking allocation software module, the booking module being in communication with a product database including product information relevant to a plurality of products and services, the product and service information for each one of the plurality of products and services having an associated capacity and value within the volumetric space/time self reconciling allocation framework, the booking module being arranged to request product constraint information related to one or more constraints provided by a booking requestor and retrieve associated product and service capacities and values from the database, and utilise the product and service capacities and values associated with the volumetric space/time self-reconciling allocation framework to determine product and service availability and a purchase price for the product and service in response to the constraints provided by the booking requestor and a user interface arranged to interact with the booking requestor and provide additional product information and additional information regarding one or more attributes to the booking requestor, wherein, if the booking requestor accepts the one or more additional attributes and requests allocation of the booking to the space on the basis of acceptance of the one or more additional attributes, the booking allocation module proceeds to book the space and provide a multi-payment module capable of receiving and reconciling multiple payments from multiple sources across a period of time, wherein the product, service and transaction information associated with a booking is associated with the booking information independently of the space to which the booking is allocated, wherein, the products, services and transactions associated to a booking self-reconciles all orders and all payments and presents a final account to the booking requestor or any other authorised person.

[0026] In one embodiment, the system is arranged to interface with an accounting module to provide transaction information to an accounting system.

[0027] In one embodiment, the booking module utilises qualified product information to determine table availability using the classification of tables into categories.

[0028] In one embodiment, the booking module utilises the qualified product information to determine table availability within a space comprising one or more spaces.

[0029] In one embodiment, the booking module utilises the qualified product information to determine the table availability to effect an optimised condition.

[0030] In one embodiment, if the product request is not confirmed then the booking requestor is provided with at least one alternative determined utilising the constraint information.

[0031] In one embodiment, a product is one or more of the number of courses associated with a menu, a food item, a beverage item or a combination thereof.

[0032] In one embodiment, product attributes include a:

a. specific service; b. specific booking time; c. specific duration time; d. specific day of the week; e. specific date; f. specific group size; g. specific occasion; and h. specific booking duration.

[0033] In one embodiment, the product information includes constraint information regarding supplementary items including:

a. extended duration times; b. locations within a venue; c. classes of tables within a venue; d. specific types of table; e. specific tables within a venue; and f. specific levels of service.

[0034] In one embodiment, the price is dynamically set according to:

a. Price by product; b. Price by product by time; c. Price by product group size; d. Price by occasion; e. Price by period of extended duration time; f. Price by peak and off-peak times; g. Price by table based on table utility and table location characteristics; h. Booking fees; i. Price by additional services; and j. Discounts, promotions during less popular times.

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

[0036] In one embodiment, the database includes menu constraint information regarding menus available dependant on the time period constraint information provided by the user, whereby the user can select to accept the additional restraint information or can alter their request dependent on the menu constraint information.

[0037] In one embodiment, the database includes menu constraint information regarding the number of courses provided in a menu based on the at least one request.

[0038] In one embodiment, the database includes time and/or date constraint information regarding at least time and/or date that a space is available to be allocated wherein each time and/or date includes an indicator arranged to allocate a relative rating to the time and/or date, wherein the rating is utilised as a constraint condition, wherein the user is required to pay a particular charge depending on the rating with the time and/or date.

[0039] In one embodiment, the user interface provides a means for the user to select at least one item from at least one menu to be had during the use of the space and pay for the use of the space in advance of using that space.

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

[0041] In one embodiment, the user interface is configured to enable a first remote user to invite a second remote user to use the user interface.

[0042] In another aspect, the invention provides a computer-enabled method for managing a transaction booking allocation system, comprising the steps of, utilising a volumetric space/time framework including defining a plurality of spaces that comprise a venue, each space including a series of attributes, the attributes ascribing characteristics to the space to allow differentiation between the plurality of spaces, utilising a product tree, the product tree including a plurality of products arranged to be groupable into categories of products, the categories of products being associated with each one of the plurality of spaces, whereby each category of products are arranged to have different prices associated with each product in the category of products, whereby a booking requestor, upon allocation of a booking to a space, selects products within the category of products and a transaction is created, the transaction being associated with the space, whereby any selected products are associated with the space until the service and products have been provided and the service is concluded.

[0043] In one embodiment, each space in the plurality of spaces is associated with a unique identifier, whereby the transaction is associated with the unique identifier.

[0044] In one embodiment, a pre-payment made by the booking requestor is associated with the transaction.

[0045] In one embodiment, the method includes the step of providing an additional user interface, the additional user interface allowing the booking requestor and other parties associated with the allocated booking with an interface to select further products, the further products being associated with the transaction.

[0046] In one embodiment, upon the booking requestor's arrival at the venue, the transaction is activated, whereby all information including products selected and pre-payments are allocated to the space.

[0047] In one embodiment, all further transactions occurring during the booking process are ascribed to the transaction allocated to the space.

[0048] In one embodiment, the venue is a restaurant.

[0049] In one embodiment, the categories of products are menus and the products are menu items.

[0050] In one embodiment, the products include sub-groupings of differentiated products, each of the differentiated products in the sub-grouping being similar products but functionally separate from each other.

[0051] In one embodiment, the sub-groupings of products are menu items that share ingredients, but where each of the products within the sub-grouping omit one or more ingredients.

[0052] In one embodiment, each menu item is associated with a plurality of ingredients, each ingredient being linked to a product tree ofingredients.

[0053] In another aspect, the invention provides a computer-enabled method for managing a transaction booking allocation system, comprising the steps of, utilising a table and table combination structure that defines the seating capacity of a venue, each one of the tables and table combinations including a series of attributes, the attributes ascribing characteristics to the each one of the tables and table combinations to differentiate between the plurality of tables and table combinations, utilising a product tree, the product tree including a plurality of products arranged to be groupable into categories of products, the categories of products being associated with each one of the plurality of table and table combinations, whereby each category of products are arranged to have different prices associated with each product in the category of products, whereby a booking requestor, upon allocation of a booking to one or more of a table and table combination, selects products within the category of products and a transaction is created, the transaction being associated with the one or more allocated tables and table combinations, whereby any selected products are associated with the one or more allocated tables and table combinations until the service and products have been provided and the service is concluded.

[0054] In another aspect, the invention provides a computer-enabled method to process a multi-stage transaction in an integrated autonomous on-line booking system for a restaurant, utilising a volumetric space/time framework including menu pre-orders comprising the steps of: providing the volumetric space/time frame work including the ability to add or remove tables during the booking allocation process whereby when the volumetric space/time framework adds or removes tables, unique table numbers are maintained within the volumetric space/time framework and unique seating position numbers for all tables, providing one or more menu items selectable within a classification system or reference system such as a product tree whereby menus are created directly from the product tree or classification system to create permutation menu items that are linked to existing menu items such that the permutation menu items replace the original menu items, providing to the booking requestor at least one menu from the selection of each of the one or more menu items whereupon prices are applied for each one or more menu items to the specific menu created, and the at least one menu being associated with time duration allocations, whereby the volumetric space/time framework allows for the posting of the one or more menus to one or more physical attributes by time.

[0055] In one embodiment, the volumetric space/time framework may post utilising one or more further constraints including day, date, service, booking time, table, class of table, utility, occasion, group size, payment terms and conditions together with one or more further constraints accessed by the booking allocation system as part of the booking allocation process such as, user membership details, user CRM details and user transaction history.

[0056] In one embodiment, the booking allocation system records all transactional information in complete detail within the booking diary and the volumetric space/time framework.

[0057] In one embodiment, online menus presented to users as part of the booking process, subsequent to the booking process but prior to the arrival at the restaurant are stored within the volumetric space/time framework utilising the individual transactional information, such that all information stored is capable of further integration and completely auditable from an accounting perspective as a core accounting system and not as a booking or diary repository of non-integrating text and information not in a financial information format.

[0058] In one embodiment, variations to the booking information pre-order selections, invitations to pre-order are undertaken through transaction systems and through the booking allocation process such that any appropriate booking allocation changes, duration changes can be recorded and stored together with any previous booking information within the volumetric space/time framework.

[0059] A computer-enabled method in accordance with claim 34, whereby all the transactions associated with a booking are fixed to a table at some point either before the arrival of a booking requestor and their guests or on arrival to the restaurant and one that table is opened that table form part of the referencing detail of the booking information to which further transactions can be added to and from which the final account can be settled.

[0060] In another aspect, the invention provides a computer-enabled method for the integration or replacement of a two-dimensional real-time product price framework within a Point of Sale (POS) system with a volumetric space/time framework, comprising a module arranged to provide menu and product information and associated and pricing structures by time including future time periods.

[0061] In one embodiment, future period transactions are constrained by the posted constraints, including at least one of a threshold and trigger arranged to activate actions, including but not limited to payment collection.

[0062] In one embodiment, the method further includes an interface arranged to post to future periods in a third party point of sale system.

[0063] In another aspect, the invention provides a computer-enabled method for the integration or replacement of a two-dimensional product price framework within a third party system with a volumetric space time framework to permit the posting of additional or further information including one or more of payment terms and conditions, including prepayments, and deposits.

[0064] In one embodiment, transactions for a future period are constrained by the posted constraints.

[0065] In another aspect, the invention provides a computer-implemented method for accounting for future transactions in a venue arranged to provide a service and arranged to receive bookings, comprising the steps of, upon a deposit being paid into an account associated with a venue, creating a debit entry in a ledger associated with a bank account of the venue, creating a credit in an advance deposit and payments received account, creating an accounting transaction entry within a reservations diary associated with the venue, including the transaction date, whereby, upon a space being allocated to the booking, allocating the transaction entry to the booking, whereby on completion of the transaction, the advance deposit and payment is deducted from the final amount requested, whereby, on completion of the transaction, all entries are updated in a general ledger in an accounting system.

[0066] In another aspect, the invention provides a computer-implemented method for managing transactions in a venue, comprising the steps of, transferring a real time representation of a floor plan of a venue including tables and seats associated with one or more bookings to a point of sale system, whereby tables and seats provided on the real time representation are associated with transactions for products and/or services associated with the tables and seats.

[0067] In one embodiment, the floor plan is associated with a calendar, the floor plan further being associated with future prospective transactions.

[0068] In another aspect, the invention provides a computer-implemented system comprising a volumetric space/time framework arranged to process financial transactions, whereby the transactions are associated with at least one of a future event, threshold and trigger.

[0069] In one embodiment, the transactions are multi-stage transactions of a future event.

[0070] In another aspect, the invention provides a volumetric framework for an online booking system to be the primary restaurant system and incorporating CRM, product differentiation, dynamic pricing, ancillary products and upselling, revenue management and revenue customer and booking analysis capacity determination, capacity adjustment and reallocation, within an underlying product identification and classification system, transaction management and docket printing or message transmission without the need for a traditional point of sale system which cannot offer the product differentiation and dynamic pricing opportunities offered by the volumetric framework and without the need for manual intervention and manual reconciliation of traditional point of sale systems. In one embodiment, the current invention has developed a system for the online bookings for restaurants.

[0071] In another aspect a full and complete integration with traditional Point of Sale (POS) systems such that the creation of manual pre-paid accounts and the manual transfer of these amounts is no longer required with the enabling of autonomous reconciliation of pre-paid amounts with any further amounts payable during the dining process.

1. Transaction Reference

[0072] In one embodiment, the unique transaction reference includes the time, seating, service, date and table, seat (or stool) allocation. As can easily be understood this process is only possible if table numbers and position seating numbers can be maintained and remain unique.

[0073] In one embodiment, the transaction reference can determine if the amounts received are "earned revenue" or "unearned revenue" based on the time and date which can determine if a transaction has been completed as planned and without the need for the creation of separate accounts.

[0074] In one embodiment, the total transaction reference can apply to a table that is allocated by the online restaurant booking system.

[0075] In one embodiment, subsets of the total transaction can apply to table numbers it can apply to both a table and to chairs or position numbers that is allocated by the online restaurant booking system.

[0076] In one embodiment, any deposits, prepayments, part payments, pre orders, group payments, individual payments made prior to arrival at a restaurant are applied and referenced against the booking details.

[0077] In one embodiment, a person who made the booking arrives or a guest arrives and the guests are sat the transactions are visible as part of any "run sheet" or booking details within the restaurant reservations system.

[0078] In one embodiment, all transactions are recorded in the detail that they were created including selections and each individual payment made.

2. Transaction Management System

[0079] In one embodiment, all payment and order details are integrated and available within a transaction management system.

[0080] In one embodiment the as soon as a booking arrives and is seated then all the payment and order details are made available in the transaction management worksheet area and calculation module

[0081] In one embodiment, the transaction management system is linked to one or more additional systems including the booking allocation system, the CRM (Customer Relationship Management) system, the yield management and dynamic pricing system, the revenue system, the stock system or module, the purchasing system, the accounts payable system, the revenue analysis system, the forecasting system and the artificial intelligence system.

[0082] In one embodiment, items ordered can be communicated in the kitchen and bar through printers or messages on monitors.

[0083] In one embodiment, the kitchen and bar devices can send messages back to advise the status of the food and beverage items.

[0084] In one embodiment the transaction management system is integrated to an ordering system such that a person can see the items ordered and their status by position number and table.

[0085] In one embodiment, final payments can be made by position number, individual or by table number.

[0086] The present invention provides for the development of processes and procedures for what the present invention refers to as the triple entry accounting system or a double entry

[0087] In one embodiment, using the restaurant online booking process referred to above an aspect of the present invention records the three entries when a transaction occurs. The recording of the three entries involves the steps of:

a) Firstly, a debit in the bank account ledger of the restaurant, b) Secondly, a credit in the "deposits and payments received in advance" ledger, c) Thirdly, an entry as an accounting transaction entry attached to the booking within reservation diary incorporated as part of the booking allocation process, including the date the transaction was made, such that table allocations operate in an analogous manner to the "table accounts" ledger within a POS systems, d) Fourthly, all of the above entries, for each table and/or booking are associated with the same unique reference.

[0088] In one embodiment when a person arrives for their booking, the booking has been allocated to a table or is allocated to a table and as all previous deposits part payments and other transactions information is already attached to the table together with all other booking information. Further, transactions can therefore also be attached to the table account that has been "opened" autonomously through the use of self-seating kiosks, or sensors or manually and on completion of all further transactions and the customers are ready to settle the account all deposits, prepayment and other information is already on the account so those amounts can be deducted from the final amount payable.

[0089] In a further embodiment when the table account is finalised the table account can be integrated to the "General Ledger" account "deposits and payments received in advance" and those amounts could be offset through the creation of corresponding debits when the table account is finalised and any final payment made and the revenue is recorded.

[0090] Embodiments of the current invention include the process of including the above invention and incorporating the same processes and approach to integrate traditional POS systems within any situation where deposits, pre payments or multiple financial transactions occur.

Brief Description of the Drawings

[0091] 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 the accompanying drawings in which:

[0092] FIG. la 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;

[0093] FIG. lb 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;

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

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

[0096] FIG 3a 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;

[0097] FIGs 4a-f are diagrams illustrating a prior art transaction process and a transaction process in accordance with an embodiment of the invention;

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

[0099] FIGS 6a-f are flowcharts illustrating a ordering and payment process and a product setup process in accordance with an embodiment of the invention;

[0100] FIGs 6g-I are screenshots illustrating a menu pre-ordering process in accordance with an embodiment of the invention;

[0101] FIGS 7a-h are flowcharts illustrating a booking process in accordance with another embodiment (hair salon) of the invention; and

[0102] FIG. 8a is a modular representation of the data constructs and the modules utilised to process a booking request in accordance with another embodiment of the invention.

Detailed Description of the Preferred Embodiments

[0103] One embodiment of a computing system arranged to carry out the method steps of the embodiment is shown at FIG. la.

[0104] In FIG. la 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.

[0105] With reference to FIG. la, 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 110 (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.

[0106] The computing system 100 includes instructions that may be installed in ROM 104, RAM 106 or disc drives 112 and may be executed by the processor 102. There may be provided a plurality of communication links 114 which may variously connect to one or more user devices 110, 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.

[0107] In one particular embodiment the device may include a database 116 which may reside on the storage device 112. 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 116 may reside on a single physical storage device or may be spread across multiple storage devices, either locally or remotely.

[0108] 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 116 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.

[0109] 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 110 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 110 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 110 may also be provided as a mobile application or "app" present on the user device, such as a tablet or smart phone.

[0110] The at least one user interacts with the user interface 110 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.

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

[0112] 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 110 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.

[0113] 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 110 via any number of different devices.

[0114] Referring to Figure lb 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.

[0115] Referring now to FIGs. 1c-f, there is shown a conceptual illustration (with reference to a cartesian framework) for the underlying geometric and mathematical concept embodied in the embodiment of the invention described in more detail hereinbelow. As previously described, the embodiment described and defined herein is broadly directed to a system capable of developing, managing and utilising a floor plan for a space to allocate bookings and provide personalised service to customers, in addition to assisting in the operation of the space.

[0116] Broadly, referring to FIG. 1c, the operation of the method and system described herein 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. 1d.

[0117] Referring to FIG. 1d, 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 174 and a second dimension 176.

[0118] Referring to FIG. le there is described a practical application of the concept of FIG. 1d where the framework 186 with dimensions x 188, y 182 and z 184 are located within the context of a posting calendar, which is arranged to interact with a user-defined reporting calendar 190. This reduction to practice is further described with reference to FIG. 1f, where a restaurant floor plan is overlaid on the three-dimensional framework. In more detail, a floor plan creation module 194 is utilised to create a floor plan 192 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 196 within the calendar 197, 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 overtime. The z axis is controlled by a time constraint module 193 which includes time constraints 195 such as opening hours, seating periods, etc.

[0119] 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).

[0120] 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/051168 (and co-pending PCT application PCT/AU2018/051169, PCT/AU2018/051170 and PCT/AU2018/051171) 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 11 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.

[0121] Table 1:

Title of related applications Shorthand A computer-enabled method, system and computer Space 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 A computer-enabled method, system and computer Widget program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service A computer-enabled method, system and computer Yield Management program for dynamically altering constraints utilised in the management of a space, furniture, equipment or service A computer-enabled method, system and computer POS Transactions program for the management of a multi stage transaction (The present including management of a booking and service delivery application) process

A computer-enabled method, system and computer Rosters program for providing an intuitive user interface and algorithm arranged to create a dynamic roster utilising an allocation algorithm to perform the task of the allocation of staff to tasks in a workplace A computer-enabled method, system and computer Operations program for providing an intuitive user interface arranged to create a dynamic floor plan utilisable by an allocation algorithm to perform the task of organising and operating a provision of a service A computer-enabled method, system and computer Menus 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 A computer-enabled method, system and computer Functions program for providing an intuitive user interface arranged to create a dynamic floor plan utilisable by an allocation algorithm to perform the task of managing a function or event A computer-enabled method, system and computer Ordering and program for autonomously allocating and managing a Allocation space, furniture, equipment and/or a service via an Integration electronic device A computer-enabled method, system and computer Exchange program for managing the exchange between third parties of service contracts for the provision of a restaurant booking or other analogous service A computer-enabled method, system and computer Gaming program for monitoring a plurality of gaming machines and other games of chance, and providing a booking and monitoring service for gaming enthusiasts and gaming venues An autonomous, integrated computer-enabled method, Artificial Intelligence system and computer program utilising an artificial intelligence engine for dynamic allocation and optimisation of space, furniture, equipment and/or services (AU2019/900128) PCT/AU2018/051168 (and co-pending PCT application PCT Applications PCT/AU2018/051169, PCT/AU2018/051170 and PCT/AU2018/051171)

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

[0123] 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

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

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

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

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

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

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

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

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

[0132] 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

[0133] 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

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

[0135] 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

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

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

[0138] 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 T1 and T2 and a combined table T1+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 T1+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.

[0139] 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 Table 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

11. Artificial Intelligence - as described in Table 1

12. PCT Applications - as described in Table 1

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

[0141] 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

[0142] 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).

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

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

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

[0146] 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 than 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.

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

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

[0149] 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

[0150] 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

[0151] 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

[0152] 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

[0153] 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

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

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

[0156] 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 Table 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

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

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

[0159] 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

[0160] 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

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

[0162] 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

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

[0164] 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 Table 1

23. Yield management - as described in Table 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

[0165] 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).

[0166] 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

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

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

[0169] 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:

[0170] 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)

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

[0172] 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

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

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

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

[0176] 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).

[0177] 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

[0178] 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

[0179] 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

[0180] 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

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

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

[0183] 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

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

[0185] 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

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

[0187] 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

[0188] 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

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

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

[0191] 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

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

[0193] 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 la to 1v above:

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

[0195] User, in one embodiment (255)

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

[0197] 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)

[0198] 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)

[0199] 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)

[0200] 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)

[0201] Payment/Deposit Confirmation (267)

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

[0203] 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)

[0204] 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)

[0205] 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)

[0206] Strategy-Related Booking Optimisation: An ambience re allocation: if restaurant is not expected to fill up or other parameters apply. (277)

[0207] 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)

[0208] 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)

[0209] 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)

[0210] 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)

[0211] 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)

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

[0213] 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)

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

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

[0216] 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:

[0217] Prior Art (223)

[0218] User(2000)

[0219] Access Channels (2002)

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

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

[0222] 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).

[0223] Payment/Deposit Confirmation (2010)

[0224] 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)

[0225] Dashboard: Static Floor Plan (2014)

[0226] Payments (2016)

[0227] 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:

[0228] 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)

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

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

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

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

[0233] Moreover, there is described below a series of algorithms, which for convenience, are numbered. However, 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.

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

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

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

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

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

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

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

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

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

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

[0244] Referring to 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".

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

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

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

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

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

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

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

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

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

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

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

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

[0257] 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, which 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.

[0258] Referring to Figure 3a, 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 300 and opening hours information 301 and 303, floor plan information 302, menu information 304, promotion information 306 including reduced price promotions 307, backfill promotions 313 and follow on promotions 311, plus booking fee information 308, extended duration information 309, concierge service item information 310, allocation rules 312, widget configuration rules 334 and email configuration data 335, all information is posted to the posting calendar 314 which includes table allocation logic 316 and transaction details 318 and interacts with the booking widget 336 which receives booking request 338 from customer 1 (340) to create a seating process 320 which is then posted to the POS system within the volumetric framework 322, which is arranged to interact with the floor staff ordering app and databases 326. The floor staff ordering app is in communication with the printer integration manager 328 and a kitchen printer 330, and a till 332.

[0259] The email configurator 335 communicates with the customer via emails 346 which include the ability to edit bookings 348 and cancel bookings 350 an also pre-order 352, which connect with the menu ordering app 342 or the menu ordering widget 344. Similarly, customer 2 (354) may interact directly with kiosk 356 which has a cloud connection to the calendar 358. The operator/owner/manager 331 may also have a cloud connection 333 to the diary and dashboard reporting system.

[0260] Referring to Figure 4a there is shown a prior art Point of Sale (POS) system. A conventional POS system includes a product tree 400 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 402 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 404. Where changes are required to the static key map, a new product and key map is developed at step 408 and the developed product and key map is "posted" to the till 406. 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.

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

[0262] Referring to Figure 4c there is shown a volumetric framework as applied to a series of products and prices over time. The volumetric framework 418 is three dimensional. This allows products and pries to vary over time. This further allows the framework 418 to interact with a plurality of menus 420, such that the menus can be associated with each table, wherein the volumetric framework 422 includes a space volumetric framework 424 where the space volumetric framework is associated with the location and size of tables 428, and the volumetric framework of products is overlaid in a posting calendar 426 such that it is integrated with the reporting calendar 430. This in turn allows all devices to show a live, dynamically changeable (over time) menu 434. 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 4d.

[0263] Referring to Figure 4d there is shown a Space and Volume Point of Sale System. As described previously, the product tree 400, menu sets 436 and menu sets as associated with the volumetric framework 438 are posted to a volumetric framework 424 within a posting calendar 426 which varies over time 428, and integrates with a user defined calendar 430 and therefore with a till 440. 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.

[0264] Referring to Figure 4e, 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 442 which includes an ordering system 444. This is passed to 446 Point of Sales System, which contains a pre-order transaction module 448 and upon a guest arriving at 450, a table is opened for the guest and information is manually transferred at step 451 from the pre-order transaction system to the point of sale system and the transaction is completed at step 452.

[0265] Referring to Figure 4f, 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 454 which includes an ordering system 456 which transfers the order to a space and volume sale and transaction system 458. The pre-order transaction is loaded at 460 into a volumetric framework, such that, when the guest arrives at step 462, the pre-order is automatically applied to a table as a result of the guest being seated and the transaction then completes automatically at step 464 when the guest leaves the restaurant.

[0266] Referring to Figures 5a-d, there is shown an aspect of the dynamic floorplan which utilises links into the product tree so that an operator may utilise the dynamic floor plan to add products to a table by seat position number. An operator may select a specific table, as shown in FIG 5a in screenshot 502, wherein the selected table will be shown in a popup screen 504. Upon selecting a seat on the table, a full menu 506 is shown, including different courses 508, 510, 512 and 514. At Fig 5b, the menu is specific to the type of booking. There is also provided a facility to add to the order, by using tabs 520, 524, 526 and 528. As can be seen, each seat is shown 530 (and 538), and an operator can cancel an item on an order 534 or send to kitchen 536. Also, the operator can send all orders for a course to the kitchen 540. In this manner, the operator can efficiently change orders, send orders to the kitchen, or cancel orders easily.

[0267] Referring to FIG. 5c-d, by clicking the order summary tab 518, the operator can view a summary of payment and promotion details 542 and a summary of the entire meal 544, including costs. The operator can also select an option to pay the bill for the customer at 548. Summary information for other customers on the table can also be shown, as seen at 550.

[0268] Referring to Figure 6a, there is shown a flowchart illustrating a menu pre-payment process. At step 600, a customer accesses the menu pre-ordering widget. The customer is identified at step 602, after which an interactive display illustrating the relevant table and chair position numbers for the booking is displayed at step 604. The customer assigns guests at step 606 to each chair position, and thereafter, an interactive menu is displayed at step 608. The customer selects items at step 610, and at step 612, an order summary is displayed.

[0269] Thereafter, pre-payment options are displayed at step 614, and the customer prepays for selected items at 616. The transactions are subsequently added to the customer's account at step 618. After prepayment and menus selection, then at step 620 the transaction is added to a specific table when at a specific time before service, bookings are allocated to tables at step 622, all booking information including menus are associated with the stable at step 624, such that when the customers arrive at step 626, they are seated, and if all orders have been pre-paid and pre-ordered, then at step 628 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.

[0270] Referring to Figure 6b, there is shown the interaction between the device (customer device or kiosk) 630 and the database 644. The device 630 is capable of executing a widget 632 in accordance with an embodiment of the invention. The interface of the widget 632 allows the customer to input an identifier 634, which is then used by the widget (at 643) to request CRM information from the client database 644. Returning to the widget, once the CRM information is identified, the information is sent to the widget at step 662 and is customised at step 664, in order to display on the user interface of the widget 632 specific promotions 636, menu-related constraints 638, and to hide or show specific fields based on constraint information as shown at 640. The customer completes and submits the pre-order at 642.

[0271] Returning to the client database 644, included in the database is a CRM 646, the CRM including customer records such as Customer'A' record 648 which includes a customer ID 650, booking history 652, membership information 654, customer preference data including dietary preferences, etc. 656, customer behaviour information 658, wherein the record 648 is also associated with relevant promotions 660. (Forgot to mention 661)

[0272] Referring to Figure 6c, there is shown a flowchart illustrating a product setup to enable menu configuration for the menu pre-ordering widget. At step 666, the operator selects a product setup and at step 668, the operator selects a new product option. Subsequently, the operator selects a product group to assign the new product to at step 670, and the operator inputs the full name of the product at 672 and the product description at 674. The operator then inputs the PLU barcode number for the product at 676 and subsequently elects a restaurant to assign the product to at 678. The operator then inputs a product price at 680, and a display name (for display on the widget) at 682. The operator selects a relevant product supplier at 684 and a product price calculation type at 686. The operator then enables the product as an active menu item at 688 and then selects the variation button at 692 to access the setup interface for product variations. At step 694 the operator selects items from stock to add to the product ingredients list and at 696 the operator inputs preparation time and cooking time.

[0273] At step 698 the operator inputs the method of preparation and cooking. Optionally, at step 6102, the operator adds an alternative product. At step 6104 the operator selects an alternative product description, and at 6106 the operator selects appropriate allergy and or dietary requirement categories. The operator modifies the ingredients for the alternative product at 6108 and (Forgot to mention 6110) the operator saves the alternative product details at 6112. The operator then saves all product details at 6114. 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.

[0274] Referring to Figures 6d to 6f, there are shown screenshots which display the input screens associated with the process flow described with reference to Figure 6c. Firstly referring to Figures 6d, there is shown a product setup screen 6116, which is generally under the admin section of the ResButler interface, as indicated by pathway 6117. The operator can select a product group 6118, input a name 6120, input a description 6122, enter a barcode 6124, associate the product with a restaurant 6126 and enter one or multiple sale prices by menu6125. If the product is to be visible, the operator can attach a display description 6132, can select a supplier 6134, can choose one of a number of price calculation mechanisms, and can enable the whole product at 6138. The operator can also add recipes and product variations by clicking button 6140, add cooking instructions by clicking button 6142 and add associated condiments by clicking button 6144. The operator can then save the input information by clicking the save button 6146.

[0275] Referring to Figure 6e, if the operator clicks the recipe button 6140, the operator is provided with the input screen 6150 shown at Figure 6e. The operator is presented with 6152, a stock item, from which the user can add items using add item buttons 6155. If added, the items are displayed in selected ingredients screen 6156 and the operator can add a quantity as shown generally at 6158. The operator can delete items from the ingredients list by using button 6159. The operator can add a preparation time at 6160 and a cooking time at 6116. The operator can also add cooking instructions at 6162 and can enter variations (alternative products) at area 6164. The user can add an alternative product description at 6166, select relevant allergies at 6168 and relevant dietary requirements at 6170 and is provided with a modified ingredients list at 6172, where the operator can add an ingredient using button 6174 and remove ingredients using button 6176 or substitute ingredients using button 6178.

[0276] Referring to Figure 6f, there is shown a continuation of Figure 6e. The operator can add a different preparation time at 6180, a different cooking time at 6182 and a different recipe or cooking method at 6184. Once finished entering information, the operator can save the iteration of recipe inputs at 6146.

[0277] Referring to Figures 6g-1, there are shown various screenshots of an ordering widget which utilises the menu and product items created with reference to Figures 6c-e. At Figure 6g, there is shown a first screen 6188 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 6186 or may be displayed to the customer in some other manner. The booking widget 6188 includes the restaurant name 6189, the number of guests 6190, the date of the booking 6191 and the time of the booking 6192. The display also includes the name of the customer who booked the space 6193 and a unique reference for the booking 6194. Using various buttons, the customer can edit a booking using button 6196, cancel a booking using button 6197, pre-order from the menu using button 6198 or view promotions using button 6199.

[0278] 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 6200 which includes instructions 6202, where the customer can enter a booking reference number 6204 is known, or alternatively enter an email address 6206 and a booking date 6208 before clicking the continue button 6210.

[0279] Referring to Figure 6h, there is shown a subsequent screen 6212 which is displayed once the customer is identified and elects to pre-order their meal. At screen 6212 there is shown a welcome message 6214, a descriptor of the person logged in at 6213, and a general area 6215 which includes information about the booking 6218, a logo 6216, a link to view the table booked 6220, a link to view existing orders associated with the booking 6222, a listing of guests 6224 including each guest name 6226 and a facility to edit the guest name 6228. 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 6231.

[0280] There is further provided a series of tabs in area 6232, such as tab 6234 which corresponds to a specific guest, and tab 6235 which corresponds to the table. There is also shown the menu generally denoted by 6236, with various menu items (such as 6238) grouped under headings 6237 and 6242. There are also shown prices 6239 and the ability to add an item using add button 6240.

[0281] Referring to Figure 6i, if the customer selects the table booked view button from Figure 6h (6220) a screen 6244 is displayed including a representation of the table 6246, a representation of chairs 6243 and 6245, where the selected chair is coloured differently (6245), and a tab representing each guest 6248, 6249, 6251 and 6253. Each guest tab allows a first name 6250 to be input, a last name 6252 to be input, an email address 6254 to be input, a mobile number 6256 to be input, an allergy to be optionally selected 6258 and a dietary requirement 6260 to be selected. All information input can be saved using button 6146 or cancelled using 6262.

[0282] Referring to Figure 6j, there is shown a closeup of a portion of the screen 6264, for a particular tab 6234 (of a series of guest tabs 6235, 6237, 6239 and 6235) where a popup screen for a selected menu item is displayed. There is provided an image of the item 6216, the name of the menu item 6266, the price 6268, the ingredients 6270, an option to select condiments 6272, an option to vary cooking instructions 6274, a button to add to the order 6276 and a cancel button 6262.

[0283] Referring to Figure 6k, there is shown a variation of the closeup of Figure 6j, where guest 4 (6239) has provided information regarding allergies 6282 and dietary requirements 6284 which results in the ingredients 6286 being changed, and optionally the condiments 6288 may also be varied, as may the cooking instructions 6290.

[0284] Referring to Figure 61, once each customer has placed their order, there is shown a total screen 6292, which, for each guest, such as guest 6296 and guest 6304, there is shown an order 6294 including selected menu items 6298, 6399, 6300, 6301 and 6302, associated prices such as 6305, including sub-totals 6307 and a total 6308, and the ability to delete items using cross 6306. The customer can also proceed to payment by clicking button 6311.

[0285] Referring to Figure 7a, there is shown a flowchart for booking a service in a salon in accordance with an embodiment of the invention. At step 700, a customer views a series of salon options, and at 702 the customer selects a salon. Appropriate service items are displayed at 704 and at 706 the customer selects the desired service items (which may include promotional offers).

[0286] The customer is subsequently given four options to select from. Availability by time, availability by date, availability by stylist and availability by stylist level. If the customer selects availability by time at step 708, available times are displayed at 710 and the customer selects a time at step 712, before the process continues along arrow A. If the customer selects availability by date at step 7112, available dates are displayed at 7114 and the customer selects a date at step 7116, before the process continues along arrow B. If the customer selects availability by stylist at step 7156, available stylists are displayed at 7158 and the customer selects a stylist at step 7160, before the process continues along arrow C. If the customer selects availability by stylist level at step 7172, available stylist level are displayed at 7174 and the customer selects a stylist level at step 7176, before the process continues along arrow D.

[0287] Referring to Figure 7b, there is shown a continuation of the process along arrow A from Figure 7a. The customer is subsequently given three options to select from. Availability by date, availability by stylist and availability by stylist level. If the customer selects availability by date at step 714, available dates are displayed at 716 and the customer selects a date at step 718, before the process continues along arrow Al. If the customer selects availability by stylist at step 788, available stylists are displayed at 790 and the customer selects a stylist at step 792, before the process continues along arrow A2. If the customer selects availability by stylist level at step 798, available stylist levels are displayed at 7100 and the customer selects a stylist at step 7102, before the process continues along arrow A3.

[0288] There is also shown in Figure 7b a continuation of the process along arrow B from Figure 7a. The customer is subsequently given three options to select from. Availability by time, availability by stylist and availability by stylist level. If the customer selects availability by time at step 7118, available times are displayed at 7120 and the customer selects a time at step 7122, before the process continues along arrow B1. If the customer selects availability by stylist at step 7130, available stylists are displayed at 7132 and the customer selects a stylist at step 7134, before the process continues along arrow B2. If the customer selects availability by stylist level at step 7140, available stylist levels are displayed at 7142 and the customer selects a stylist at step 7144, before the process continues along arrow B3.

[0289] Referring to Figure 7c, there is shown a continuation from Figure 7b of arrows Al, A2 and A3. Following from arrow Al, the customer is subsequently given two options to select from. Availability by stylist and availability by stylist level. If the customer selects availability by stylist at step 720, available stylists are displayed at 722 and the customer selects a stylist at step 724, before the process continues along arrow E. If the customer selects availability by stylist level at step 721, available stylist levels are displayed at 723 and the customer selects a stylist level at step 725, then available stylists are displayed at 727 and the customer selects an available stylist at 729 before the process continues along arrow E.

[0290] Following on from arrow A2, if the customer selects available dates at step 794, a date is selected at step 796 and the process continues along arrow E.

[0291] Following on from arrow A3, if the customer selects availability by stylist at step 7104, available stylists are displayed at 7106 and the customer selects a stylist at step 7108, then available dates are displayed at 7110 and the customer selects an available date at 7112 before the process continues along arrow E. If the customer selects availability by date at step 7103, available dates are displayed at 7105 and the customer selects a date at step 7107, then available stylists are displayed at 7109 and the customer selects an available stylist at 7111 before the process continues along arrow E.

[0292] Referring to Figure 7d, there is shown a continuation from Figure 7b of arrows B1, B2 and B3. Following from arrow B1, the customer is subsequently given two options to select from. Availability by stylist and availability by stylist level. If the customer selects availability by stylist at step 7124, available stylists are displayed at 7126 and the customer selects a stylist at step 7128, before the process continues along arrow E. If the customer selects availability by stylist level at step 7121, available stylist levels are displayed at 7123 and the customer selects a stylist level at step 7125, then available stylists are displayed at 7127 and the customer selects an available stylist at 7129 before the process continues along arrow E.

[0293] Following on from arrow B2, if the customer selects available times at step 7136, a date is selected at step 7138 and the process continues along arrow E.

[0294] Following on from arrow B3, if the customer selects availability by stylist at step 7146, available stylists are displayed at 7148 and the customer selects a stylist at step 7150, then available times are displayed at 7152 and the customer selects an available time at 7154 before the process continues along arrow E. If the customer selects availability by time at step 7145, available times are displayed at 7147 and the customer selects a time at step 7149, then available stylists are displayed at 7151 and the customer selects an available stylist at 7153 before the process continues along arrow E.

[0295] Referring to Figure 7e there is shown a continuation of the process along arrow C from Figure 7a. The customer is subsequently given two options to select from. Availability by time and availability by date. If the customer selects availability by date at step 7162, available dates are displayed at 7164 and the customer selects a date at step 7166, then available times are displayed at 7168 and the customer selects an available time at 7170 before the process continues along arrow E. If the customer selects availability by time at step 7171, available times are displayed at 7173 and the customer selects a time at step 7175, then available dates are displayed at 7177 and the customer selects an available date at 7179 before the process continues along arrow E.

[0296] There is also shown in Figure 7e a continuation of the process along arrow D from Figure 7a. The customer is subsequently given three options to select from. Availability by date, by time and availability by stylist. If the customer selects availability by date at step 7178, available dates are displayed at 7180 and the customer selects a date at step 7182, before the process continues along arrow D1. If the customer selects availability by time at step 7194, available times are displayed at 7196 and the customer selects a stylist at step 7198, before the process continues along arrow D2. If the customer selects availability by stylist at step 7210, available stylists are displayed at 7212 and the customer selects a stylist at step 7214, before the process continues along arrow D3.

[0297] Referring to Figure 7f there is shown a continuation of the process along arrow D1 from Figure 7e. The customer is subsequently given two options to select from. Availability by time and availability by stylist. If the customer selects availability by time at step 7184, available times are displayed at 7186 and the customer selects a time at step 7188, then available stylists are displayed at 7190 and the customer selects an available stylist at 7192 before the process continues along arrow E. If the customer selects availability by stylist at step 7183, available stylists are displayed at 7181 and the customer selects a stylist at step 7185, then available times are displayed at 7187 and the customer selects an available time at 7189 before the process continues along arrow E.

[0298] Returning to Figure 7f there is shown a continuation of the process along arrow D2 from Figure 7e. The customer is subsequently given two options to select from. Availability by date and availability by stylist. If the customer selects availability by date at step 7200, available dates are displayed at 7202 and the customer selects a date at step 7204, then available stylists are displayed at 7206 and the customer selects an available stylist at 7208 before the process continues along arrow E. If the customer selects availability by stylist at step 7201, available stylists are displayed at 7203 and the customer selects a stylist at step 7205, then available dates are displayed at 7207 and the customer selects an available date at 7224 before the process continues along arrow E.

[0299] Returning to Figure 7f there is shown a continuation of the process along arrow D3 from Figure 7e. The customer is subsequently given two options to select from, availability by time and availability by date. If the customer selects availability by time at step 7216, available times are displayed at 7218 and the customer selects a time at step 7220, then available dates are displayed at 7222 and the customer selects an available date at 7224 before the process continues along arrow E. If the customer selects availability by date at step 7215, available dates are displayed at 7217 and the customer selects a date at step 7219, then available times are displayed at 7221 and the customer selects an available time at 7223 before the process continues along arrow E.

[0300] Referring to Figure 7g there is shown a continuation of the process along arrow E (from Figures 7 c, d, e and f). At step 726, the information gathered in the previous steps is sent to the allocation system via an API link. At step 728, the optimisation algorithm processes the booking request. If the booking request is allocated, the process continues along arrow F which is described in more detail in Figure 7h. If the booking request is not allocated, as shown at step 730, the optimisation algorithm determines possible alternatives at step 732, and a popup containing the alternatives is provided to the customer on their user interface at step 734. At this point, the customer has three alternatives. If the customer selects an alternative time at step 736, an edited booking request is sent 738 to the system and at step 740 the optimisation algorithm processes the booking request, before returning to one of arrow F or step 730.

[0301] Alternatively, the customer may choose to join a waitlist at step 742, and inputs contact details at step 7444. The contact details are submitted at step 746 and a waitlist request is sent to the allocation system at step 748. A waitlist booking is created at step 750, and the information is communicated to the customer at step 752 before the process ends at step 754.

[0302] In a third alternative, the customer may cancel the booking request at step 756, after which the widget closes at step 758 and the process ends at step 760.

[0303] Referring to Figure 7h, there is shown a continuation of the process along arrow F of Figure 7g. At step 762, the booking request is temporarily allocated and at step 764 the contact detail inputs are displayed. The customer inputs their details at step 766 and relevant payment options are displayed at step 768. A payment option is selected by the customer at step 770, and the selected payment option is displayed to the customer at step 772. Payment details are submitted at step 774 and an option to join a mailing list, plus the display of terms and conditions, occurs at step 776. Terms and conditions are agreed to at step 778 and if payment details are not processed at step 780, the process returns to step 772. Alternatively, if payment is processed successfully at step 782, the booking confirmation is displayed and a receipt is sent to the customer at step 784, before the process ends at 786.

[0304] Referring to Figure 8a, there is shown a modular chart depicting the various hardware and software components of the ordering system and widget in accordance with another embodiment of the invention (a hair salon). Utilising the product tree 800 and opening hours information 802 and 804, floor plan information 806 (which includes specific equipment and areas 808, 810, 812, 814 and 816), service item information 818 (including various items such as 820, 822 and 824), tactical promotion information 826 (including reduced price promotions 828, backfill promotions 830 and follow on promotions 832), plus booking fee information 834, allocation rules 836 (including rule sets such as 838, 840 and 842), widget configuration rules 870 and email configuration data 871, all information is posted to the posting calendar 843 and 844 which includes service and stylist allocation logic 846 and transaction details 848 and interacts with the booking widget 872 which receives booking requests 874 and 875 from customer 1 (867 and 877) (875 is not found in diagram.) to create a seating process 850 which is then posted to the POS system within the volumetric framework 852, which is arranged to interact with the databases 856 (including CRM system 858, revenue system 860 and diary 862). The POS system 852 is in communication a till 854.

[0305] The email configurator 871 communicates with the customer via emails 878 and 879 which include the ability to edit bookings 880 and cancel bookings 882, which connect with the booking widget 872. The operator/owner/manager 863 and 864 may also have a cloud connection 866 to the diary and dashboard reporting system.

[0306] Referring now to Figure 9a, there is shown a novel ledger and payment processing system integral to the ResButler system described herein, although it will be understood that the ledger and payment processing system may be a standalone module arranged to be integrable into an existing payment or Point of Sale (POS) system, or integrable into an embodiment in accordance with the present invention, which in Figure 9a, is a booking widget 900. The booking widget 900 includes the facility for a customer to request a booking (902) which includes payment details 904. The third party gateway transaction is facilitated by a third party gateway 920 which provides information on whether the transaction is successful (922).

[0307] The third party gateway 920, in order to process the transaction, connects with a bank 924 where payment is recorded 926 to produce a payment record 928 including amounts 930 (e.gg. amounts 934 and 936) and also associated reference numbers 932. Where necessary, a chargeback mechanism may be provided at 938. It will be understood that the chargeback mechanism is also integrated into the system described herein, in the manner such that any chargeback entry generated by the bank is processed in a manner identical to any payment entry generated. In turn, the creation of a bank record 928 results in a journal entry940 in a general ledger associated with the venue/restaurant, which is shown in more detail at 942. The general ledger 942 includes a bank account ledger 944 including entries (such as 966 and 968) that include the date 946, a description 948, 3 rd party gateway information 950, and debit and credit information 952 and 954 respectively. There is also provided a deposits ledger 946 including entries (such as 970 and 972) that include the date 956, a description 958, 3rd party gateway information 960, and debit and credit information 962 and 964 respectively.

[0308] Returning to the booking widget, the submission of a booking request 902 and payment details 904 results in the creation of a payment record file 906 which includes an item type 908 (in this example the item type is a deposit 918), an allocation identifier 910, a reference number 912, an amount 914 and a 3rd party gateway transaction reference number 916. The aforementioned information is captured in order to uniquely identify the transaction.

[0309] Once the record 906 is created, the record is saved at 996 and used to populate a volumetric framework database 974 (described earlier herein). A payment record 976 is generated, which may be one of many payment records such as 978 and 980. Each instance of a payment record includes an item type 982 (in this case deposit 994), an allocation number 984, a transaction number 986, a third party reference number 988, and unearned and earned columns 990 and 992. The journal entry 940 is posted to the volumetric framework as shown at 940. In this manner, a complete record of all transactions is kept, and future events may be accounted for in both the ledger and at the point of sale.

[0310] A similar process occurs when the menu widget is utilised. Referring to Figure 9b, there is shown a menu widget 999. At 903 the customer opens the widget via an email 901 and submits an order which includes payment details. The third party gateway transaction is facilitated by a third party gateway 919 which provides information on whether the transaction is successful (921).

[0311] The third party gateway 919, in order to process the transaction, connects with a bank 923 where payment is recorded 925 to produce a payment record 927 including amounts 929 (e.g. amounts 933 and 935) and also associated reference numbers 931. Where necessary, a chargeback mechanism may be provided at 937. In turn, the creation of a bank record 927 results in a journal entry 939 in a general ledger associated with the venue/restaurant, which is shown in more detail at 941. The general ledger 941 includes a bank account ledger 943 including entries (such as 967 and 969) that include the date 947, a description 949, 3rd party gateway information 951, and debit and credit information 953 and 955 respectively. There is also provided a deposits ledger 945 including entries (such as 971 and 973) that include the date 957, a description 959, 3rd party gateway information 961, and debit and credit information 963 and 965 respectively.

[0312] Returning to the menu widget, the submission of a booking request 903 and payment details results in the creation of a payment record file 905 which includes an item type 907 (in this example the item type is a pre-order 917), an allocation identifier 909, a reference number 911, an amount 913 and a 3rd party gateway transaction reference number 915. The aforementioned information is captured in order to uniquely identify the transaction.

[0313] Once the record 905 is created, the record is saved at 997 and used to populate a volumetric framework database 975 (described earlier herein). A payment record 977 is generated, which may be one of many payment records such as 979 and 981. Each instance of a payment record includes an item type 983 (in this case pre-order 995), an allocation number 985, a transaction number 987, a third party reference number 989, and unearned and earned columns 991 and 993. The journal entry 939 is posted to the volumetric framework as shown at 939. In this manner, a complete record of all transactions is kept, and future events may be accounted for in both the ledger and at the point of sale.

[0314] Referring now to Figure 9c, further orders may also be processed and payment provided on completion of a dining event. Utilising menu widget 9100, a customer may initialise a final payment sequence at 9102, such that any utilisable transactions are accessed at 9104. By accessing the volumetric framework 9106. The volumetric framework returns recorded transactions 9130 and the customer accepts the bill and the remaining balance at 9132. This causes the widget to access a third party payment gateway 9134 which provides confirmation of the transaction at 9136 such that the Resbutler payment record is populated at 9138. Alternatively, cash payment may be provided at 9123, in which case a cash payment is recorded at 9125. In either cash payment or third party payment, a bank transaction is recorded in a bank system 9142, including a payment record 9146 including an amount 9148 (in this example 9152) and a reference number 9150.

[0315] The resultant payment record is recorded as a journal entry in the general ledger 9154 as shown in more detail at 9158 which includes a bank account ledger 9156 and a deposits ledger 9160. The bank account ledger includes entries such as 9182 and 9184, including a date 9162, a description 9164, a third party gateway transaction reference number 9166 and debit and credit columns

9168 and 9170 respectively. Similarly, the deposits ledger 9160 includes entries such as 9186 and 9188, including a date 9172, a description 9174, a third party gateway transaction reference number 9176 and debit and credit columns 9178 and 9180 respectively.

[0316] The journal entries are also posted to a volumetric framework 9106, including a payment record 9108, an instance of which is shown at 9112. The payment record 9112 includes an item 9114, an identifier 9116, a reference number 9118, a third party reference number 9120, and unearned and earned columns 9122 and 9124 respectively. The item column 9114 includes deposit types 9126 and payment types 9128. The volumetric framework interfaces with an inventory system 9127, such that as transactions are recorded and inventory is decremented or ordered accordingly in appropriate ledgers (not shown).

[0317] Referring now to Figure 9d, there is shown a user interface screenshot in accordance with an embodiment of the invention. The screenshot provides a record of transaction for a user 9190, including a reference number 9192. The transaction 9196 has an identifier 9194 including a date 9103, a gateway reference number 9105, an association with a customer 9107, a payment method 9109 and a description 9111, plus information regarding items ordered 9113, quantities 9115, price 9117, the ability to provide a refund 9119, and a total amount 9121. Other transactions such as 9101 are also listed.

Advantages

[0318] The embodiment and broader invention described herein provides a number of advantages.

[0319] Firstly, the embodiment provider a volumetric framework for the referencing of transactions which is farm more flexible and permits a wider referencing framework for the autonomous consolidation and reconciliation of multiple transactions relating to the one overall activity, product or service.

[0320] Secondly, the volumetric framework permits greater product differentiation and dynamic pricing not possible with traditional P.O.S systems.

[0321] Thirdly, the use of a volumetric framework permits differential pricing within different areas, sub areas, classes, sections within a venue such as a restaurant.

[0322] Fourthly, the use of a volumetric framework permits differential products, menu items, menus and other goods and services by a third or further dimension not possible with the current two dimensional P.O.S systems.

[0323] Fifthly, the use of volumetric pricing and transaction framework within or integrated with a booking allocation system and diary permits the creation of a completely autonomous transaction payment and reconciliation system without the need for a traditional P.O.S system.

[0324] Sixthly, the use of a volumetric pricing and transaction framework integrated with a CRM system and booking allocation system will permit the provision of loyalty benefits and the recognition of customers not possible with traditional systems. For example, if a VIP customer is not seated at their preferred table during the booking allocation process that information could be utilised to provide the VIP customer a free glass of their favourite wine in recognition or as an apology that they were not allocated to their favourite or preferred table.

[0325] Lastly, 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.

[0326] Moreover, the incorporation of a triple entry accounting system for multiple payment payments reduces manual intervention, reduces errors, and is cheaper.

Disclaimers

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

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

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

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

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

[0332] 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).

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

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

[0335] 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.11 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.

Annexure 1 1. Prior Art - Performance Measures and Metrics

The following is an extensive list of the current theoretical revenue measures applied to restaurants. There are no prior art systems that can provide measures related to space, classes of tables, extended durations, by differentiated products etc., as such information is beyond the capture of existing systems and hence calculations and performance monitoring and adjustment is also beyond current systems. • RevPASH (Revenue Per Available Seat Hour) • CMPASH (Contribution Margin Per Available Seat Hour) • RevPASM (Revenue per Available Square Meter) • ProPASH (Profit per Available Seat Hour) • ProPASM (Profit per Available Square Meter) • RRM (Restaurant Revenue Management) Time Per Table Turn Times Table Turn Cancelled/No Show/Covers as a % of Reserved Covers Average revenue per person * Average revenue per table * Average revenue per chair

Notes: 1. To date the restaurant performance measures and metrics of the only known and placed reliance on a few single dimensional applied metrics such as table turns, average spend per customer and theoretical but not applied metrics such as revenue per available seat hour. These applied and theoretical measurements and metrics by themselves, do not offer any proper or significant guidance as to what decisions a restaurant should take. This has resulted in restaurants being limited to and merely focusing on discounting prices during low demand periods and systems that cannot be automated and for artificial intelligence to be applied.

2. The prior art use of single measures as shown above and applied to PASH and PASM do not offer information as to what inputs need to be changed, how they need to be changed or other information that would assist a person in their decision-making process or provide the necessary information that could be used within an artificially intelligent system for the autonomous changing of constraints. The reason that the prior art fails is that all prior art cannot distinguish between the inputs and variables that impact the simple measures such as PASH and PASM that have been measures identified by the prior art.

Annexure 2 2. Floor Plan Guidelines, Benchmarks, Rankings and Space Efficiency Measures for the Claimed Invention

1. Spatial Guidelines and Measures Floor Space Allocation * Total Floor Plan Area (100%) • Kitchen Floor Plan Area (30%) • Wash Up Store Room, Locker Room, Admin Floor Plan (10%) Area * Dining Room and Bar Plan Area (includes toilets and (60%) waiters' stations)

Dining, Bar and Customer Spaces (required to scale) • Dining Room Area 1 Floor Plan * Dining Room Area 2 Floor Plan (etc) • Private Dining Room Area 3 Floor Plan (etc) • Dining Room Subarea 1 Floor Plan (etc) • Dining Room Section 1 Floor Plan (etc) • Bar Area Floor Plan

Table Top Size Guide * Minimum recommended table top size 0.18 square meters per person * Minimum table top size (for two) 600mm by 600mm * Table Top Fine Dining (minimum) 750mm by 750mm * Table Top Full-Service Restaurant 700mm by 750mm Dining • Casual Restaurant Full-Service Dining 600mm by 700mm * Bar Area dining top 300mm by 500mm • Round Top 1 to 2 people diameter 600mm • Round Top 2 to 4 people diameter 800mm • Round Top 4 to 5 people diameter 1000mm • Round Top 5 to 6 people diameter 1200mm • Round Top 6 to 7 people diameter 1350mm • Round Top 7 to 8 people diameter 1500mm

Fixed and Flexible Seating Areas to scale including walkways * Number of Fixed tables within the floor plan * Number of Flexible Tables within the floor plan * Number of Fixed Tables to total tables * Percentage of Flexible Tables to total tables

Chair Size Guide * Minimum chair footprint 450mm by 450mm

Spacing between Tables (allowing for chairs and movement) • Space between rectangular tables 1250mm to 1550mm including chairs * Space between table to table with chair 1050mm only on one side * Space between back to back chairs for 460mm movement * Space between diagonal chairs 460mm * Space between tables in row seating 150mm to 700mm * Space between round tables 1350mm * Space allowed for chairs along a table 600mm * Walk way between table with no chairs 600 mm * Walk way fire egress depends on 1000mm regulations

Waiter Stations Size Guide • Waiter Stations small up to 20 0.50 to 1.00 square chairs/diners meters • Waiter Stations up to 60 chairs/diners 2.25 to 3.75 square meters

Bars Space and Bar stools Size Guide * Bar Area Floor Plan • Bar Stool seating Distances 510mm to 600mm

Area per Person Size Guide * Square meters per patron Fine Dining 1.70 to 1.90 square meters • Square meters per patron Full-Service 1.10 to 1.40 square Restaurant Dining meters • Square meters per patron Counter 1.70 to 1.90 square Service meters • Square meters per patron Fast Food 1.00 to 1.30 square Medium meters • Square meters per patron Table Service, 1.40 to 1.70 square Hotel/Club meters • Square meters per patron Banquet, 0.90 to 1.10 square Minimum meters

2. Area, Sub Area, Class, Section and Table and Stool rankings * Ranking of areas * Ranking of subareas within areas * Ranking of sections within areas * Ranking of classes

* Ranking of sections * Ranking of all individual tables within the venue * Ranking of all chairs within each table and location * Ranking by table characteristics; view, privacy, etc., by groups or classes

3. Table Analysis * Table size by day by time, seating, service, by area, by subarea, by section * Table size by occasion * Table size by product * Table size by duration * Table size by class * Quantity of tables (and chairs) by class and by area * Quantity of tables (and chairs) by utility * Requested tables (by all permutations) • Usage and Occupancy of Requested tables (by all permutations) • Rates of Requested tables versus other tables (by all permutations) • Revenue of Requested tables versus other tables (by all permutations) • Preferred Tables (by all permutations) • Usage and Occupancy of Preferred Tables (by all permutations) • Rates of Requested Tables versus other tables (by all permutations) • Usage of the fixed Tables versus total tables (by all permutations) • Usage of the Flexible Table versus total tables (by all permutations) • Usage of Alternate Floor Plans and Layouts (by all permutations) • Usage of additional Furniture by the optimisation algorithm (by all permutations) • Removal of Furniture shown on the Floor Plan by the optimisation algorithm (by all permutations) • Number of bookings that could not be accommodated by booking size and timing (by all permutations) • Revenue analysis of all tables by distribution channel (by all permutations)

4. Tables for Sale, Tables for Auction, Tables Dedicated to Specific Partners for distribution and or Channels * Tables for sale by partner (by all permutations) • Tables for sale by distribution channel (by all permutations) • Tables for auction (by all permutations) • Tables dedicated to specific channels (by all permutations) • Usage and occupancy of requested tables versus available capacity * Revenue comparisons of all table combinations (by all permutations) • Chair analysis similar to table analysis (by all permutations) 5. Location Analysis * Revenue by location by floor space (by all permutations) • Revenue by total floor space

6. Floor Space Efficiency

* Revenue per square meter by total productive floor space * Revenue per square meter by total floor space including non-productive floor space * Revenue by per square meter by different floor space sub-sets, classes, etc. (by all permutations)

Annexure 3 3. Capacity, Utilisation and Revenue Efficiency Measures for the Claimed Invention

The below measures and metrics must include additional tables and chairs added for a service and deduct the tables and chairs removed for a service. That is the use of one embodiment of the claimed invention and dynamic allocation process which permits which the addition and removal of tables from the capacity and inventory made available for the allocation of a booking. The concept of adding or removing tables and chairs from the available capacity during the booking allocation process is outside the scope (and beyond the prior art). Also refer to Annexure 7 for further details of this embodiment. 1. Revenue Yield

• AR (Actual Revenue) - Used by prior art to calculate RevPASH

* PR (Potential Full Revenue - all items sold and free items provided at RRP) • RY (Revenue Yield)

2. Seat Capacity (Production) and Utilisation Capacity • ASH (Available Seat Hours)- Capacity - Used by prior art to calculate RevPASH

Revenue • RSH (Revenue Seat Hours)- Equivalent to the prior art of RevPASH

Utilisation • SUF (Seat Utilisation Factor)

Efficiency * SEF (Efficiency Factor - Revenue Yield (RY) multiplied by (SUF))

Costs * Cost levels can be calculated by available seat capacity or revenue seat capacity

3. Table Capacity (Production) and Utilisation Capacity * ATH (Available Table Hours)

Revenue

• RTH (Revenue Table Hours)

Utilisation * TUF (Table Utilisation Factor)

Efficiency * TEF (Table Efficiency Factor)

Costs * Costs levels can be calculated by available table capacity or revenue table capacity

4. Units of Measure of Capacity Physical Constraints • NOR (Number of Restaurants) • NOT (Number of Tables) • NOS (Number of Seats)

Hours Open • HRO (Hours Restaurant Open) • HKO (Hours Kitchen Open)

Service Periods Open • SPO (Service Periods Open) • BPO (Breakfast Periods Open) • LPO (Lunch Periods Open) • DPO (Dinner periods Open) • SPO (Supper Periods Open)

Service Hours Open • BSHO (Breakfast Service Hours Open) • LSHO (Lunch Service Hours Open) • DSHO (Dinner Service Hours Open) • SSHO (Supper Service Hours Open)

Back of House (Kitchen) Hours * HKP (Hours Kitchen Preparation) • HKS (Hours Kitchen in Service) • HKC (Hours Kitchen Clean-up)

Front of House (Dining Room) Hours * HDRP (Hours Dining Room Preparation) • HDRO (Hours Dining Room Open) • HDRC (Hours Dining Room Clean-up)

Annexure 4 4. Booking Analysis for the Claimed Invention

1. Booking Requests Allocated Analysis * Booking requests by time, date, etc, made that could be accommodated by booking size by occasion, by service, by area, subarea, section, class, specific table

2. Booking Profile Analysis * Booking lead time profile * Booking group size * Booking occasion * Booking composition by adults, by children, by high chairs, by etc., * By duration * By menu * By time * By Butler Service • By table size * By table requested * By table preferred * By postcode/address

3. Booking Requests Rejected Analysis * Booking requests by time, date, etc, made that could not be accommodated by booking size by occasion, by service, by area, subarea, section, class, specific table * Booking requests by time, date, etc, made where a person took an alternate booking without an incentive by booking size by occasion, by service, by area, subarea, section, class, specific table * Booking requests by time, date, etc, made where a person took an alternate booking with an incentive by booking size by occasion, by service, by area, subarea, section, class, specific table • Booking Requests by time, date, etc, made that went on a waitlist by service by time by booking size by occasion, by service, by area, subarea, section, class, specific table • Booking Requests by time, date, etc, that went on a wait list that could be accommodated by service by time by booking size by occasion, by service, by area, subarea, section, class, specific table • Booking requests by time, date, etc, made that went on a wait list that could not be accommodated by service by time by booking size by occasion, by service, by area, subarea, section, class, specific table * Booking lead time profile * Booking source, by website, by third party, by app, by referral

4. Source of Booking Analysis

* Booking source (Source of Revenue), by website, by third party, by app, by referral * Cost of booking source and cost of referrals

Annexure 5 5. Duration Time Analysis for the Claimed Invention

1. Duration Time Analysis * Duration time by booking size compared to standard booking time * Duration time by booking size by menu compared to standard booking time * Duration time by booking size by menu by number of courses compared to standard booking time * Duration time by booking size by customer type compared to standard booking time * Duration time by booking size by day compared to standard booking time * Duration time by booking time interval by day compared to standard booking time * Duration times by booking size by menu, by time taken for each activity, being seated, taking food order, taking drink order, time taken for the first course to be prepared, time taken for the first course to be consumed, time taken for the second course to be delivered from time of seating and from time to being called away, time to consume the second course, time third course order taken, time before third course delivered, time to consume third course, other items ordered, time other items delivered, time bill given, time bill paid compared to standard booking times. • Duration times by occasion using the same metrics as booking size compared to standard booking time. • Table reset times by table type by day of the week by time compared to standard booking time

2. Extended Duration Time Analysis for the Claimed Invention

* Extended duration time by table, class of table, section, class, subarea, area, channel, booking partner * Increase in revenue comparing normal duration bookings with extended duration bookings

Annexure 6 6. Product Mix Analysis for the Claimed Invention

1. Food (by, time, by service, by day, by server or channel) A la Carte One Course Two Courses Three Courses Degustation Menu * Pre-Theatre Menu • Post Theatre Menu * Promotional Menus • Take away revenue * Home Delivery revenue

2. Beverage (by time, by service, by day, by server or channel) • Alcoholic Beverage Revenue * Non-Alcoholic Beverage Revenue * Soft Drink Revenue • Tea & Coffee revenue

3. Supplementary (by time, by service, by day, by server or channel)

• Window seat surcharge * Preferred booking time surcharge * Extended Time Surcharge * Booking Fee * Gift box * Chocolates * Roses • Other retail items, books, oil, * Room Hire Charges

The above analysis, similar to all other embodiments detailed within the submissions and within this annexure can be undertaken by area, subarea, class, table, distribution channel or any other definable input, constraint, or item within the scope of the claimed invention.

Annexure 7 7. Revenue and Customer Performance Analysis for the Claimed Invention

1. Revenue Analysis • RRSH (Revenue per Revenue Seat Hour) • RASH (Revenue per Available Seat Hour) • RRTH (Revenue per Revenue Table Hour) • RATH (Revenue per Available Table Hour)

• Revenue per Chair • Revenue per Table * Revenue Per Person * Revenue per person by courses, by class, by menu, by time booked, by booking duration * Revenue by area, subarea, section, class and by their respective square meters (also prorata over the whole restaurant) • Revenue by additional restaurant items, by area, subarea, section, class, table * Revenue by supplementary items, by area, subarea, section, class, table * Revenue by table type * Revenue by Table number * Revenue per Total Hours including prep and closing up * Revenue per Kitchen Hour (Kitchen Hours - Open Hours) • Revenue by Front of House Hours (Front of House Hours - Open Hours) • Customer Retention rate (Total Customers - Total New Customers) divided by total Customers * By time of Booking • By seating • By repeat versus new customers • By type of Customer * Revenue During peak Times * Revenue During Non-Peak times * Revenue During Shoulder Periods * Average spend per customer by all metrics * Times Tables Turn (total duration times divided by the number of people) • Function Revenue (also as a 5 of total revenue) • Home delivery as a % of total Revenue • Take Away as a % of total Revenue

2. Customer Analysis • Customers per Service * Customers by booking time, by service, by day * Customers by menu, by course, by class, by area, by subarea, by section, by day * Customers by occasion * Customers by group size

• Customers with Supplementary Items and by Supplementary items • Customers without Supplementary Items * Customers by duration booked prior to the service requested * Customers by booking source * Customers by promotion * Customers by Average Spend • Loyalty Members Average Spend * Average Spend by member type * Repeat Customers by average spend * New Customers by Average Spend * Average spend by individual type, adult, child, high chair * Total customers versus repeat customers versus new customers

3. Customer Ranking * Ranking by venue membership * Ranking by number of visits * Ranking by Spend total and per visit * Ranking by social media profile and social influence * Ranking by relationship (agent, reseller, friend, family, supplier, etc,)

4. Channel Analysis • Revenue by channel * Ranking by channel

Annexure 8 8. Staff Analysis and Roster Parameters for the Claimed Invention

1. Staff Analysis and Ratios (based on customer numbers, menu complexity and menu diversity) • Kitchen staff per customer (ratio) • Kitchen Staff Hours per customer • Kitchen Hand per customer (ratio) • Kitchen Hand Hours per customer • Wait staff per customer (ratio) • Wait staff hours per customer * Food Runner per customer (ratio) * Food Runner hours per customer * Bar Staff per customer (ratio) • Bar Staff hours per customer * Food Runner per customer (ratio) • Food Runner Hours per customer * Reception staff per customer * Reception Hours per customer * Kitchen preparation times to tables and customer ratios • Set-up times to tables and customer ratios

Annexure 9 9. Restaurant Profit and Loss Layout (a la carte) - Example, for the Claimed Invention

Different Areas Main Private Bar Total 0/0 of Dining Dining Restaurant Revenue Room Room

Revenue Food Revenue Breakfast Menu A la Carte Menu: One Course Two Courses Three Courses Tapas menu Cafe menu Bar Menu Degustation Menu Pre-Theatre Menu Post Theatre Menu Promotional Menus Supper Menu Take away Menu Home Delivery Menu Total Food Revenue

Beverage Revenue Alcoholic Beverage Revenue Non-Alcoholic Beverage Revenue Soft Drink Revenue Tea & Coffee revenue Total Beverage Revenue Supplementary Revenue Window seat surcharge Preferred booking time surcharge Booking Fee Gift box Chocolates Roses Other retail items, books, oil, Room Hire Charges Total Supplementary Revenue

Less: Credit Card Fees Less: Commissions

Less: Variable Booking Fees Less: Loyalty program allowance ("hard currency")

Net Revenue

Cost of Goods Sold Variable Costs 1 Food Costs Beverage Costs Alcoholic Beverage Costs Non-Alcoholic Beverage Costs Tea and Coffee Costs Total Cost of Goods Sold

Contribution 1

BH (Back of House) Wages Variable Costs 2 Gross Back of House Wages (including overtime and temp workers)

On-Cost Back of House Wages (super, workers comp, payroll tax) Back of House additional Costs (staff meals, uniforms, etc,) Total Back of House Wage Costs

Contribution 2

Front of House Wages Variable Costs 3 Gross Front of House Wages (including overtime and temp workers) On-Cost Front of House Wages (super, workers comp, payroll tax, staff meals) Front of House additional Costs (staff meals, uniforms, etc,) Total Front of House Wage Costs

Contribution 3

Operational Variable Costs 4 Packaging Repairs and maintenance Breakages Delivery Costs Laundry Chemicals Linen Tea towels Kitchen Duct Cleaning Restaurant Cleaning Garbage and Sanitation Printing and Menus

Decoration Expenses (flowers) Equipment Hire Transport Security Variable Booking Fees Total Operational Variable Costs 4

Contribution 4

Entertainment Variable Costs 5 Entertainment (Bands, Djs) Events Total Entertainment Variable Costs 5

Contribution 5

Marketing Variable Costs 6 Social Media Advertising Total Marketing variable Costs 6

Contribution 6

Utility Variable Costs 7 Water Electricity Rates and Taxes Utility Variable Costs 7

Contribution 7

Premises Overhead Costs 1 Rental Costs Lease marketing levy Lease Outgoing expenses Council Rates and Fees

Contribution 8

Ownership Overhead Costs 2 Depreciation Interest Insurance Health Inspections and Compliance Ownership Overhead Costs 2

Contribution 9

Head Office Overhead Costs 3 Administration Wages Accounts Marketing (Memberships and registration) Telephone & Communications Consultants Computer Head Office Overhead Costs 3

Net Profit/Loss (Contribution 10)

Other Items (Extra Ordinary items)

Annexure 10 10. Break Even and Cost Analysis for the Claimed Invention

1. Break-Even Analysis * BESUF (Breakeven Seat Utilisation factor) • BERSH (Breakeven Revenue Seat Hours) • BERPH (Breakeven Revenue per Hour) • BERPP (Breakeven revenue per Person) • BERPT (Breakeven Revenue per Table) • BEASH (Break Even per Available Seat Hour) • BERY (Break Even Revenue Yield)

2. Profit and Loss Statement, Cost Analysis Ratios and Percentages

To model the business and the performance of the business the profit and loss statement needs to be restructured so that all costs parameters can be identified independently and within homogeneous groups. All prior art systems do not detail items in the detail listed below and with our minimum 10 level contribution and analysis system.

a) Level 1 Analysis - Cost of Goods Sold • Menu Costings * Mark-up per menu item as a percentage * Mark-up per menu item as a dollar value * Food COGS (Split by venues and courses) • Alcohol Beverage COGS * Non- Alcoholic Beverage COGS e Tea and Coffee Beverage COGS * Contribution Margin after COGS

b) Level 2 Analysis - Back of House Wages * BH Wages Gross (Wages split by preparation, by service and by clean-up) • BH Wages On-Costs • BH Wages Total Costs • Contribution Margin after COGS and BH Wages

c) Level 3 Analysis - Front of House Wages * FH Wages Gross (Wages split by preparation, by service and by clean-up) • FH Wages On-Costs • FH Wages Total Costs * Contribution Margin after COGS and BH Wages and FH Wages

d) Level 4 Analysis - Operational Variable Costs • Operational Variable Costs 4

* Contribution Margin after COGS, BH Wages, FH Wages and Operational Costs 4

e) Level 5 Analysis - Entertainment Costs * Entertainment Variable Costs 5 * Contribution Margin after COGS, BH Wages, FH Wages, Operational Costs 4 and Entertainment Variable Costs 5

f) Level 6 Analysis - Marketing Variable Costs * Marketing Variable Costs 6 * Contribution Margin after COGS, BH Wages, FH Wages, Operational Costs 4, Entertainment Variable Costs 5 and Marketing Variable Costs 6

g) Level 7 Analysis - Utility Variable Costs * Utility Variable Costs 7 * Contribution Margin after COGS, BH Wages, FH Wages, Operational Costs 4, Entertainment Variable Costs 5, Marketing Variable Costs 6 and Utility Variable Costs 7

h) Level 8 Analysis - Premises Fixed Overhead Costs * Premises Overhead Costs • Contribution Margin after all Variable Costs and Premises Overhead Costs

i) Level 9 Analysis - Ownership Fixed Overhead Costs • Ownership Overhead Costs • Contribution Margin after all Previous Costs and Ownership Overhead Costs

j) Level 10 Analysis - Head Office Administration Overhead Costs * Head Office Overhead Costs * Net Profit Margin after Head Office Overhead Costs

3. Other Cost Performance Measures and Analysis

• Total Payroll Costs as compared to revenue (all operational payroll costs)

• EBITDA

* Inventory Turnover

• Overhead Rate per metric

* Customer Acquisition Cost (Marketing Variable Costs divided by Total New Customers) • All cost categories by: (per Available Seat Hour) (per Revenue Seat Hour) (per Available Table Hour)

(per Revenue Table Hour) (Opening Hours versus total kitchen Hours) (Open Hours versus total Front of House Hours)

Annexure 11 11. Supplier Pricing Comparisons and Monitoring for the Claimed Invention * Comparison of Pricing by suppliers for the same item * Reliability of Suppliers * System to select the best supplier to send the order to

Claims

Claims:

1. A computing system for processing a plurality of variable transactions associated with a booking including the allocation of a space within a venue and a provision of one or more products and services utilising a volumetric space/time self-reconciling allocation framework over a future time period, the system comprising: a processor arranged to execute a booking allocation software module, the booking module being in communication with a product database including product information relevant to a plurality of products and services, the product and service information for each one of the plurality of products and services having an associated capacity and value within the volumetric space/time self-reconciling allocation framework, the booking module being arranged to request product constraint information related to one or more constraints provided by a booking requestor and retrieve associated product and service capacities and values from the database, and utilise the product and service capacities and values associated with the volumetric space/time self-reconciling allocation framework to determine product and service availability and a purchase price for the product and service in response to the constraints provided by the booking requestor and a user interface arranged to interact with the booking requestor and provide additional product information and additional information regarding one or more attributes to the booking requestor, wherein, if the booking requestor accepts the one or more additional attributes and requests allocation of the booking to the space on the basis of acceptance of the one or more additional attributes, the booking allocation module proceeds to allocate the booking to the space and provide a multi-payment module capable of receiving and reconciling multiple payments from multiple sources across a period of time, wherein the product, service and transaction information associated with a booking is associated with the booking information independently of the space to which the booking is allocated, wherein, the products, services and transactions associated to a booking self-reconciles all orders and all payments and presents a final account to the booking requestor or an authorised person.

2. A system in accordance with claim 1, wherein the system is arranged to interface with an accounting module to provide transaction information to an accounting system.

3. A system in accordance with claim 1 or 2, wherein the booking module utilises qualified product information to determine table availability using the classification of tables into categories.

4. A system in accordance with claims 1 to 3, wherein the booking module utilises the qualified product information to determine table availability within a space comprising one or more spaces.

5. A system in accordance with claims 1 to 4, wherein the booking module utilises the qualified product information to determine the table availability to effect an optimised condition.

6. A system in accordance with any one of claims 2 to 5, wherein, if the product request is not confirmed then the booking requestor is provided with at least one alternative determined utilising the constraint information.

7. A computing system in accordance with any one of claims 2 to 6, wherein a product is one or more of the number of courses associated with a menu, a food item, a beverage item or a combination thereof.

8. A computing system in accordance with claims 2 to 7, wherein product attributes include a: a. specific service; b. specific booking time; c. specific duration time; d. specific day of the week; e. specific date; f. specific group size; g. specific occasion; and h. specific booking duration.

9. A computing system in accordance with claims 2 to 8, wherein the product information includes constraint information regarding supplementary items including: a. extended duration times; b. locations within a venue; c. classes of tables within a venue; d. specific types of table; e. specific tables within a venue; and f. specific levels of service.

10. A computing system in accordance with claims 2 to 9, wherein the price is dynamically set according to: a. Price by product; b. Price by product by time; c. Price by product group size; d. Price by occasion; e. Price by period of extended duration time; f. Price by peak and off-peak times; g. Price by table based on table utility and table location characteristics; h. Booking fees; i. Price by additional services; and j. Discounts, promotions during less popular times.

11. A computing system in accordance with claim 10 wherein the user interface is arranged, in response to constraint information provided by the user, to provide additional constraint information to the user, wherein the user may choose to accept the additional constraint information or may choose to alter their request.

12. A computing system in accordance with claim 11, wherein the database includes menu constraint information regarding menus available dependant on the time period constraint information provided by the user, whereby the user can select to accept the additional restraint information or can alter their request dependent on the menu constraint information.

13. A computing system in accordance with claim 12, wherein the database includes menu constraint information regarding the number of courses provided in a menu based on the at least one request.

14. A computing system in accordance with claims 12 or 13, wherein the database includes time and/or date constraint information regarding at least time and/or date that a space is available to be allocated wherein each time and/or date includes an indicator arranged to allocate a relative rating to the time and/or date, wherein the rating is utilised as a constraint condition, wherein the user is required to pay a particular charge depending on the rating with the time and/or date.

15. A computing system in accordance with claim 14, wherein the user interface provides a means for the user to select at least one item from at least one menu to be had during the use of the space and pay for the use of the space in advance of using that space.

16. A computing system in accordance with claim 15, wherein the user interface is configured to enable the at least one remote user to select a menu, and items on the menu for the allocated use of the space and pay for at least a portion the use of the space in advance of using the space.

17. A computing system in accordance with claim 16, wherein the user interface is configured to enable a first remote user to invite a second remote user to use the user interface.

18. A computer-enabled method for managing a transaction booking allocation system, comprising the steps of, utilising a volumetric space/time framework including defining a plurality of spaces that comprise a venue, each space including a series of attributes, the attributes ascribing characteristics to the space to allow differentiation between the plurality of spaces, utilising a product tree, the product tree including a plurality of products arranged to be groupable into categories of products, the categories of products being associated with each one of the plurality of spaces, whereby each category of products are arranged to have different prices associated with each product in the category of products, whereby a booking requestor, upon allocation of a booking to a space, selects products within the category of products and a transaction is created, the transaction being associated with the space, whereby any selected products are associated with the space until the service and products have been provided and the service is concluded.

19. A computer-enabled method in accordance with claim 18, whereby each space in the plurality of spaces is associated with a unique identifier, whereby the transaction is associated with the unique identifier.

20. A computer-enabled method in accordance with claim 18 or 19, whereby a pre-payment made by the booking requestor is associated with the transaction.

21. A computer-enabled method in accordance with claim 20, further comprising the step of providing an additional user interface, the additional user interface allowing the booking requestor and other parties associated with the allocated booking with an interface to select further products, the further products being associated with the transaction.

22. A computer-enabled method in accordance with claim 21, whereby upon the booking requestor's arrival at the venue, the transaction is activated, whereby all information including products selected and pre-payments are allocated to the space.

23. A computer-enabled method in accordance with claim 18, whereby all further transactions occurring during the booking process are ascribed to the transaction allocated to the space.

24. A computer-enabled method in accordance with any one of claims 18 to 23, whereby the venue is a restaurant.

25. A computer-enabled method in accordance with claim 24, whereby the categories of products are menus and the products are menu items.

26. A computer-enabled method in accordance with claim 25, whereby the products include sub-groupings of differentiated products, each of the differentiated products in the sub-grouping being similar products but functionally separate from each other.

27. A computer-enabled method in accordance with claim 26, whereby the sub groupings of products are menu items that share ingredients, but where each of the products within the sub-grouping omit one or more ingredients.

28. A computer-enabled method in accordance with claim 27, whereby each menu item is associated with a plurality of ingredients, each ingredient being linked to a product tree ofingredients.

29. A computer-enabled method for managing a transaction booking allocation system, comprising the steps of, utilising a table and table combination structure that defines the seating capacity of a venue, each one of the tables and table combinations including a series of attributes, the attributes ascribing characteristics to the each one of the tables and table combinations to differentiate between the plurality of tables and table combinations, utilising a product tree, the product tree including a plurality of products arranged to be groupable into categories of products, the categories of products being associated with each one of the plurality of table and table combinations, whereby each category of products are arranged to have different prices associated with each product in the category of products, whereby a booking requestor, upon allocation of a booking to one or more of a table and table combination, selects products within the category of products and a transaction is created, the transaction being associated with the one or more allocated tables and table combinations, whereby any selected products are associated with the one or more allocated tables and table combinations until the service and products have been provided and the service is concluded.

30. A computer-enabled method to process a multi-stage transaction in an integrated autonomous on-line booking system for a restaurant, utilising a volumetric space/time framework including menu pre-orders comprising the steps of: - providing the volumetric space/time framework including the ability to add or remove tables during the booking allocation process whereby when the volumetric space/time framework adds or removes tables, unique table numbers are maintained within the volumetric space/time framework and unique seating position numbers for all tables, - providing one or more menu items selectable within a classification system or reference system such as a product tree whereby menus are created directly from the product tree or classification system to create permutation menu items that are linked to existing menu items such that the permutation menu items replace the original menu items, - providing to the booking requestor at least one menu from the selection of each of the one or more menu items whereupon prices are applied for each one or more menu items to the specific menu created, and - the at least one menu being associated with time duration allocations, whereby the volumetric space/time framework allows for the posting of the one or more menus to one or more physical attributes by time.

31. A computer-enabled method in accordance with claim 30, whereby the volumetric space/time framework may post utilising one or more further constraints including day, date, service, booking time, table, class of table, utility, occasion, group size, payment terms and conditions together with one or more further constraints accessed by the booking allocation system as part of the booking allocation process such as, user membership details, user CRM details and user transaction history.

32. A computer-enabled method in accordance with claim 31, whereby the booking allocation system records all transactional information in complete detail within the booking diary and the volumetric space/time framework.

33. A computer-enabled method in accordance with claim 32, whereby any online menus presented to users as part of the booking process, subsequent to the booking process but prior to the arrival at the restaurant are stored within the volumetric space/time framework utilising the individual transactional information, such that all information stored is capable of further integration and completely auditable from an accounting perspective as a core accounting system and not as a booking or diary repository of non-integrating text and information not in a financial information format.

34. A computer-enabled method in accordance with claim 33, whereby any variations to the booking information pre-order selections, invitations to pre-order are undertaken through transaction systems and through the booking allocation process such that any appropriate booking allocation changes, duration changes can be recorded and stored together with any previous booking information within the volumetric space/time framework.

35. A computer-enabled method in accordance with claim 34, whereby all the transactions associated with a booking are fixed to a table at some point either before the arrival of a booking requestor and their guests or on arrival to the restaurant and one that table is opened that table form part of the referencing detail of the booking information to which further transactions can be added to and from which the final account can be settled.

36. A computer-enabled method for the integration or replacement of a two dimensional real-time product price framework within a Point of Sale (POS) system with a volumetric space/time framework, comprising a module arranged to provide menu and product information and associated and pricing structures by time including future time periods.

37. A computer-enabled method in accordance with claim 36, whereby future period transactions are constrained by the posted constraints, including at least one of a threshold and trigger arranged to activate actions, including but not limited to payment collection.

38. A computer-enabled method in accordance with claim 37, further including an interface arranged to post to future periods in a third party point of sale system.

39. A computer-enabled method for the integration or replacement of a two dimensional product price framework within a third party system with a volumetric space time framework to permit the posting of additional or further information including one or more of payment terms and conditions, including prepayments, and deposits.

40. A computer-enabled method in accordance with claim 39, whereby transactions for a future period are constrained by the posted constraints.

41. A computer-implemented method for accounting for future transactions in a venue arranged to provide a service and arranged to receive bookings, comprising the steps of, upon a deposit being paid into an account associated with a venue, creating a debit entry in a ledger associated with a bank account of the venue, creating a credit in an advance deposit and payments received account, creating an accounting transaction entry within a reservations diary associated with the venue, including the transaction date, whereby, upon a space being allocated to the booking, allocating the transaction entry to the booking, whereby on completion of the transaction, the advance deposit and payment is deducted from the final amount requested, whereby, on completion of the transaction, all entries are updated in a general ledger in an accounting system.

42. A computer-implemented method for managing transactions in a venue, comprising the steps of, transferring a real time representation of a floor plan of a venue including tables and seats associated with one or more bookings to a point of sale system, whereby tables and seats provided on the real time representation are associated with transactions for products and/or services associated with the tables and seats.

43. A computer-implemented method for managing transactions in a venue in accordance with claim 42, whereby the floor plan is associated with a calendar, the floor plan further being associated with future prospective transactions.

44. A computer-implemented system comprising a volumetric space/time framework arranged to process financial transactions, whereby the transactions are associated with at least one of a future event, threshold and trigger.

45. A computer implemented system in accordance with claim 44, whereby the transactions are multi-stage transactions of a future event.

46. A computer-implemented method for accounting for multiple payments across a period of time for a purchase of one or more products within a booking system arranged to facilitate transactional aspects of at least one of the provision of a service and a product by a venue, comprising the steps of, upon receipt of confirmation that a customer has paid a monetary deposit into an account associated with the venue, creating an accounting transaction entry within a general ledger associated with the venue, including the transaction date, whereby, upon the completion of the transaction associated with the at least one of the provision of a service and a product, the advance deposit and payment is deducted from the final amount requested, whereby, on completion of the transaction, all entries are updated within the accountable ledger booking system and further payment details are recorded in an electronic general ledger in an accounting system.

47. A computer implemented method in accordance with claim 46, whereby the banking file is matched with the booking diary accounting ledger file.

48. A computer implemented method in accordance with claim 46, whereby the booking diary ledger is a sales ledger.

49. A computer enabled method in accordance with claim 46, whereby the booking diary ledger is a sales and revenue ledger.

50. A computer enabled method in accordance with any one of claims 46 to 49, whereby the booking diary ledger is integrated into a Point Of Sale system.

51. A computer-implemented method in accordance with any one of claims 46 to 50, whereby the future transaction is a multi-stage transaction, the method comprising the further step of, for each stage of the multi-stage transaction where additional services and/or products are requested, the final amount is updated to reflect the additional services and/or products.

52. A computer-implemented method in accordance with any of claims 46 to 51, comprising the further step of utilising a volumetric space/time framework to associate the multi-stage transaction with an item in a space/time framework.

53. A computer-implemented method for managing transactions in accordance with any one of claims 46 to 52,whereby the transaction is associated with a venue, comprising the steps of, transferring a real time representation of a floor plan of a venue including tables and seats associated with one or more bookings to a point of sale system, whereby tables and seats provided on the real time representation are associated with transactions for products and/or services associated with the tables and seats.

54. A computer-implemented method in accordance with claim 53, whereby the floor plan is associated with a calendar, the floor plan further being associated with future prospective transactions.

55. A computer-enabled method to process a multi-stage transaction in an integrated autonomous on-line booking system in accordance with any one of preceding claims 46 to 54, whereby the floor plan is situated within a volumetric space/time framework including menu pre-orders comprising the steps of: providing the volumetric space/time framework including the ability to add or remove tables during the booking allocation process whereby when the volumetric space/time framework adds or removes tables, unique table numbers are maintained within the volumetric space/time framework and unique seating position numbers for all tables, providing one or more menu items selectable within a classification system or reference system such as a product tree whereby menus are created directly from the product tree or classification system to create permutation menu items that are linked to existing menu items such that the permutation menu items replace the original menu items, providing to the booking requestor at least one menu from the selection of each of the one or more menu items whereupon prices are applied for each one or more menu items to the specific menu created, and the at least one menu being associated with time duration allocations, whereby the volumetric space/time framework allows for the posting of the one or more menus to one or more physical attributes by time.

Grand Performance Online Pty Limited

Patent Attorneys for the Applicant/Nominated Person

SPRUSON&FERGUSON