AU2020200611A1 - A computer-enabled method, system and computer program for managing the exchange between third parties of service contracts for the provision of a restaurant booking or other analogous service - Google Patents

Abstract

An embodiment of the present invention provides a computer-enabled method for the exchange of bookings comprising an user interface accessible by a remote device and in communication with an exchange server, the exchange server including an offer database having at least one booking received from a third party server, the booking including booking information, the booking information having availability information including at least a booking time, duration time and one or more products associated with the booking information within a volumetric space/time framework, the method comprising the steps of, receiving the booking and availability information and formatting the booking and availability information into a form to allow the information to be presented to a user as a variable offer, the variable offer being saved in the offer database on the exchange server, whereby a user interacts with the exchange server via the user interface to search for and select one or more of a plurality of offers, whereby upon the user selecting and varying one or more of the plurality of offers, the user variation is autonomously provided to the third party booking system to update the booking information within the volumetric space/time framework of the third party booking system, whereby the third party booking system processes the variation and provides a response to the exchange server whereby the response is communicated to the user via the exchange server.

Description

A COMPUTER-ENABLED METHOD, SYSTEM AND COMPUTER PROGRAM FOR MANAGING THE EXCHANGE BETWEEN THIRD PARTIES OF SERVICE CONTRACTS FOR THE PROVISION OF A RESTAURANT BOOKING OR OTHER ANALOGOUS SERVICE

Technical Field

[0001] The present invention relates to a system, method and computer program for exchanging contractual rights and computer implemented actions.

[0002] In one embodiment, the invention is directed to a computer-enabled method including a user interface arranged to allow parties to sell, exchange, purchase, re-sell or otherwise deal with electronic data packets arranged to transfer electronic rights and also the capacity to initiate actions at third party computing systems.

[0003] In one specific embodiment, the invention is directed to an electronic exchange where bookings, such as restaurant bookings, may be sold, traded with booking details updated as well as permitting the "owners" of bookings to add further changes and make further permitted upgrades and changes.

Background

[0004] 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 is 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.

[0005] It is well known to book a table at a restaurant, or to book a hotel room, a car hire service, etc. It is also known that in many situations, for a multitude of possible reasons, a person or party making a booking may have to cancel a booking before the date and/or time of the booking, as personal circumstances change. People get sick, change plans, have unforeseen events occur, etc.

[0006] Where cancellations are made close to a booking date and time, this is an inconvenience for both the person cancelling the booking and for the business that received the booking, who most likely either expended resources in preparing for the booking and/or turned away other bookings. As such, the cancellation of a booking is sub-optimal for both parties.

[0007] It is with these issues in mind that the present invention has been developed.

Summary

[0008] In a first aspect, the invention provides a computer-enabled method for the exchange of bookings comprising an user interface accessible by a remote device and in communication with an exchange server, the exchange server including an offer database having at least one booking received from a third party server, the booking including booking information, the booking information having availability information including at least a booking time, duration time and one or more products associated with the booking information within a volumetric space/time framework, the method comprising the steps of, receiving the booking and availability information and formatting the booking and availability information into a variable offer, the offer information being saved in the offer database on the exchange server, whereby a user interacts with the exchange server via the user interface to search for and select one or more of a plurality of offers, whereby upon the user selecting and varying one or more of the plurality of offers, the user variation is autonomously provided to the third party booking system to update the booking information within the volumetric space/time framework, whereby the third party booking system processes the variation and provides a response to the exchange server whereby the response is communicated to the user via the exchange server.

[0009] In one embodiment, the method includes the step of, upon selection of the offer, the user may purchase the offer, whereby upon purchase of the offer, the exchange server provides the user with access to the third party booking system to allow the user to vary at least one of the one or more products or the availability information associated with the booking.

[0010] In one embodiment, the method includes the step of, upon purchase of the booking, the exchange server performs a transfer operation arranged to transfer control of the booking to the user, whereby the user can re-offer the booking to third parties via the user interface of the exchange.

[0011] In one embodiment, the method includes the step of, the exchange server providing the user with information to access to the third party booking system to allow the user to change at least one of the booking time, duration time and the one or more products of the booking.

[0012] In one embodiment, the method includes the step of, the exchange server providing an auction interface as part of the user interface, the auction interface being arranged to allow the user to bid for purchase of the offer.

[0013] In one embodiment, the booking is related to a restaurant.

[0014] In one embodiment, the booking is related to one or a combination of a hotel booking,acarrentalbooking, accommodation booking, entertainment booking, a workspace booking, a library booking, a beauty treatment booking, a medical service booking, or any other booking associated with the provision of a service.

[0015] In another aspect, the invention provides a computer-enabled method for the exchange of bookings including an user interface accessible by a remote device being in communication with an exchange server, the method being arranged to receive, at the exchange server, information regarding a restaurant booking, the restaurant booking being received from a third party electronic restaurant booking system, the booking information including at least a booking time and date and a duration time and one or more products associated with the restaurant booking information, comprising the steps of, receiving the booking information and formatting the booking information into an offer, the offer being arranged to be displayable on the user interface, providing the offer information to an offer database on the server arranged to a hold a plurality of offers, whereby a user interacts with the exchange server via the user interface to view one or more of the plurality of offers, whereby upon purchase of one of the plurality of offers, the user is autonomously provided with the ability to access the third party booking system to interact with the booking.

[0016] In another aspect, the invention provides a computer-enabled method for the exchange of an electronic data packet, the packet embodying a contractual right for the provision of a service by a contractor to a contractee, the packet including instructions arranged to allow an identified and verified party in instruct a third-party computing system to perform one or more actions and identity information arranged to allow the computing system to verify the packet and the identity of the entity authorised to receive the benefit of the contractual right, the method comprising the steps of, receiving, from a third-party computing system, one or more packets including information regarding one or more contractual rights at an exchange computing system, the packets including one or more instructions arranged to instruct a computing system to perform one or more actions and also including identity information verifying the identity of a party that is authorised to receive the benefit of the contractual right and electronically interact with the computing system capable of performing the one or more actions, the exchange computing system formatting the information for provision of the contractual right information in an electronic format to one or more interested parties via an interface, including the provision of bidding information including but not limited to a starting bid, a bid increment and one or more trigger conditions which, upon triggering, cause the system to conclude the bidding process, whereby the interested parties are capable of bidding, via the interface, for assumption of control of the contractual rights, whereby, when the one or more trigger conditions are satisfied, the successful party is determined and the control of the contractual right is transferred to the successful party, whereby the transfer to the party includes electronically altering the identity and verification information whereby the successful party is authorised to receive the benefit of the contractual right and interact electronically with the with the computing system capable of performing the one or more actions.

[0017] In one embodiment, the method further includes the step of a third party computing system issuing a plurality of electronic data packets, each packet including information regarding one or more contractual rights and information capable of verifying the identity of a party associated with each one of the data packets, whereby the contractual right is capable of being electronically sent via a communications network to the exchange computing system.

[0018] In one embodiment, the method further includes the step of providing the packet to one or more additional exchange computing systems.

[0019] In one embodiment, the method further includes the step of verifying the packet and the identity of the entity includes the step of electronically transferring at least one passcode from the contractee to the successful party.

[0020] In one embodiment, the method includes the further step of electronically transferring the successful party to a third-party computing system controlled by the contractor, whereby the third-party computing system, upon verification of the identity of the successful party, is arranged to perform the one or more actions.

[0021] In one embodiment, the contractual rights are related to the provision of a service, such as a dining service in a restaurant.

[0022] In one embodiment, the ability for the owner of the contractual rights to be able to add additional information to the restaurant booking data base or purchase additional products or services to enhance their booking.

[0023] In one embodiment, the third-party computing system is a restaurant management system.

Brief Description of the Drawings

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

[0025] 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;

[0026] 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; and

[0027] FIGs. 2a-2g are flowcharts illustrating various processes undertaken by a methodology in accordance with an embodiment of the invention.

Detailed Description of the Preferred Embodiments

[0028] The present invention relates generally to a computing system, method and computer program and data signal for the present invention provides a computer-enabled method for the exchange of an electronic data packet.

[0029] The packet embodies a contractual right for the provision of a service by a contractor to a contractee, the packet including instructions arranged to allow an identified and verified party in instructing a third-party computing system to perform one or more actions and identity information arranged to allow the computing system to verify the packet and the identity of the entity authorised to receive the benefit of the contractual right.

[0030] The method comprising the steps of, receiving, from a third-party computing system, one or more packets including information regarding one or more contractual rights at an exchange computing system, the packets including one or more instructions arranged to instruct a computing system to perform one or more actions and also including identity information verifying the identity of a party that is authorised to receive the benefit of the contractual right and electronically interact with the computing system capable of performing the one or more actions.

[0031] The exchange computing system formats the information for provision of the contractual right information in an electronic format to one or more interested parties via an interface, including the provision of bidding information including but not limited to a starting bid, a bid increment and one or more trigger conditions which, upon triggering, cause the system to conclude the bidding process, whereby the interested parties are capable of bidding, via the interface, for assumption of control of the contractual rights.

[0032] When the one or more trigger conditions are satisfied, the successful party is determined and the control of the contractual right is transferred to the successful party, whereby the transfer to the party includes electronically altering the identity and verification information whereby the successful party is authorised to receive the benefit of the contractual right and interact electronically with the with the computing system capable of performing the one or more actions.

The Computing System

[0033] One embodiment of the computing system is shown at FIG. la.

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

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

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

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

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

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

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

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

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

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

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

[0045] Referring to Figure 2a, there is shown a process, embodied in software, for an integrated methodology for adding and removing tables from the exchange network in accordance with an embodiment of the invention. It will be understood that in the following description, reference is made to the ResButler system. The embodiment of the exchange described herein is provided as an integrated module which is arranged to work seamlessly with the ResButler system and is described with respect to the embodiment described herein in such terms. However, it will be understood that the exchange may be a standalone system.

[0046] Returning to Figure 2a, there is shown a process for adding and removing tables from the exchange network. At step 200 a restaurant logs into the exchange and at step 202 a restaurant is selected from a list of relevant restaurants. Thereafter, the restaurant may remove a table from sale or auction at step 204, or add a table from sale or auction at step 216. If the restaurant wishes to remove a table from sale or auction at step 204, the exchange, at step 206, determines whether the table has been sold. If the table has not been sold (and therefore can be removed from the exchange at step 208), and a request is sent to the restaurant floor plan to release the table at step 210 for sale through the restaurant booking system, after which the table set aside for the exchange is released at step 212 and the process ends at step 214.

[0047] Conversely, if the restaurant wishes to add a table for sale or auction on the exchange at step 216, a request is sent to the restaurant's floor plan database to retrieve relevant information regarding the table and any other constraint information relevant to the sale of the table at step 218. A guarantee or bond conditions are applied to the table at step 220. Thereafter, at step 222, the table is added to the exchange, with all relevant information posted in a manner that it may be accessed by a third party through an appropriate interface as depicted in step 224. It will be understood that the interface may be a web interface, or an app that accesses the exchange via an Application Programming Interface (API) or similar. Thereafter, once the table is added to the exchange, the process ends at step 214.

[0048] It will be understood that the process steps described above from steps 297 through to 214 may be carried out autonomously upon receipt of a remove or add command from the ResButler system, or may require some interaction with an operator from the Restaurant.

[0049] Referring to Figures 2b and 2c, there is shown a process, embodied in software, for purchasing a table listed on the exchange network in accordance with an embodiment of the invention. At step 226, a buyer logs onto the exchange. There is provided a plurality of tables for sale, depicted as items 228 and 230. The table information includes all relevant constraints applicable to the specific table, including but not limited to restaurant, date, time, class, menu, price, current bid, acceptance price and any other information that may inform a potential purchaser's decision.

[0050] The potential buyer is provided with three options. The buyer may place a bid matching the asking price and conditions, and thereby commit to buying the table at step 232. Alternatively, the buyer may place a bid less than the asking price of the table and accept the conditions (thereby requiring the restaurant to accept the lower bid for the transaction to be completed) at step 240, or the buyer may place a bid and simultaneously request modifications to the constraint conditions at step 248.

[0051] Returning to step 232, an email is sent to the restaurant notifying the restaurant of the successful sale of the table at step 234, after which the table is temporarily taken off the exchange for a set time while the buyer finalises the contract (via payment and the addition of further information) at step 236, after which the buyer submits the contract details and payment requirements at step 238 and the process continues to Figure 2c.

[0052] Alternatively, returning to step 240, the restaurant is sent an email notifying them of the buyer's bid at step 242. If the restaurant does not accept the bid, the table remains on the exchange at step 246 and the process ends at step 214. Alternatively, if the restaurant accepts the bid at step 244, the table is temporarily taken off the exchange for a set time while the buyer finalises the contract (via payment and the addition of further information) at step 236, after which the buyer submits the contract details and payment requirements at step 238 and the process continues to Figure 2c.

[0053] Alternatively, returning to step 248, the restaurant is sent an email notifying them of the buyer's bid and variation of conditions at step 250. If the restaurant does not accept the bid, the table remains on the exchange at step 246 and the process ends at step 214. Alternatively, if the restaurant accepts the bid and modifies the conditions as offered by the buyer at step 252, the table is temporarily taken off the exchange for a set time while the buyer finalises the contract (via payment and the addition of further information) at step 236, after which the buyer submits the contract details and payment requirements at step 238 and the process continues to Figure 2c.

[0054] Referring now to Figure 2c, once the transaction and payment have been completed, then at step 256 the buyer's details are added to the floor plan/booking database and the table is added to the buyer's exchange account at step 258 (optionally). If the buyer intends to use the booking as shown at step 260, the process ends at step 214 and the buyer interacts with the floor plan/booking database for any further variations or interactions. Alternatively, the buyer may wish to re-sell the table on the exchange at step 262, in which case the buyer may relist the table as shown at step 264, after which the process ends at step 214.

[0055] Referring to Figures 2d and 2e, there is shown a process, embodied in software, for purchasing a table re-listed on the exchange network in accordance with an embodiment of the invention.

[0056] Referring firstly to Figure 2d, at step 266, a buyer logs onto the exchange. There is provided a plurality of tables for sale, depicted as items 268 and 270. The table information includes all relevant constraints applicable to the specific table, including but not limited to restaurant, date, time, class, menu, price, current bid, acceptance price and any other information that may inform a potential purchaser's decision.

[0057] The potential buyer is provided with two options. The buyer may place a bid matching the asking price and conditions, and thereby commit to buying the table at step 272. Alternatively, the buyer may place a bid less than the asking price of the table and accept the conditions (thereby requiring the restaurant to accept the lower bid for the transaction to be completed) at step 280.

[0058] Returning to step 272, an email is sent to the restaurant notifying the restaurant of the successful sale of the table at step 274, after which the table is temporarily taken off the exchange for a set time while the buyer finalises the contract (via payment and the addition of further information) at step 236, after which the buyer submits the contract details and payment requirements at step 238 and the process continues to Figure 2e.

[0059] Alternatively, returning to step 280, the restaurant is sent an email notifying them of the buyer's bid at step 282. If the restaurant does not accept the bid, the table remains on the exchange at step 286 and the process ends at step 214. Alternatively, if the restaurant accepts the bid at step 284, the table is temporarily taken off the exchange for a set time while the buyer finalises the contract (via payment and the addition of further information) at step 236, after which the buyer submits the contract details and payment requirements at step 238 and the process continues to Figure 2e.

[0060] Referring now to Figure 2e, once the transaction and payment have been completed, then at step 288 the buyer's details are added to the floor plan/booking database and the table is added to the buyer's exchange account at step 290 (optionally). If the buyer intends to use the booking as shown at step 260, the process ends at step 214 and the buyer interacts with the floor plan/booking database for any further variations or interactions. Alternatively, the buyer may wish to re-sell the table on the exchange at step 262, in which case the buyer may relist the table as shown at step 264, after which the process ends at step 214.

[0061] Referring to Figure 2f, there is shown a process, embodied in software, for allowing a customer of a restaurant to place a booking on the exchange network in accordance with an embodiment of the invention. At step 266, the restaurant setup option is selected in the ResButler system. Subsequently, the operator selects the exchange rules setup option at step 268, followed by the "allow re- sale"option at step 270. Thereafter, the user is presented with a number of options with regard to the constraints that may be utilised to determine which bookings may be re-sold via the exchange. The constraints may include, by way of example only, a prepayment requirement, a specific booking time, a specific booking duration, a specific menu, a specific minimum spend, a specific tables, class, or any combination of the above.

[0062] Once the operator has selected the desired or relevant constraints, the desired setup (including table information and constraint information) is saved in a manner to allow the information to be transmitted, as a package, to the exchange (i.e. posted to the calendar) at step 274. The process then ends at step 214. It will be understood that the step of "packaging" the transaction includes elements of converting the constraints into elements of an electronic contract, such that the setup file includes provisions that may contractually bind a purchaser, should they decide to purchase the table via the exchange.

[0063] Referring to Figure 2g, there is shown a process, embodied in software, for allowing a user (specifically a customer who has created a normal restaurant booking via the ResButler booking system) to place a booking on the exchange network in accordance with an embodiment of the invention. At step 276, the user follows the usual process in the ResButler system to secure a booking. As per the Resbutler system, the user is sent an email (at either step 278 or 286). If the user has an exchange account, re-selling information and a link is automatically sent via the email at step 278, after which the user may log in at step 280 if the user wishes to participate in the exchange and the process continues to step 290 (described later). Alternatively, if the user has not set up an exchange account previously, the user is provided with a different link in the email provided at step 286, wherein the user is directed to terms and conditions at step 288 and creates an account. Thereafter, at step 290 the secured booking is automatically added to the user's exchange account.

[0064] Thereafter, once step 280 or 290 is completed, the user lists the booking on the exchange for resale at step 282, and the booking is displayed for sale at step 284, after which the process ends at step 214.

[0065] Referring to Figure 2h, there is shown a process, embodied in software, for a methodology for adding and removing tables from the exchange network in accordance with an embodiment of the invention, specifically showing a process where the restaurant wishing to list products on the exchange is using a booking system that is not integrated with the exchange network. At step 286 a restaurant which is not integrated in the ResButler network initiates a request to create an account. The ResButler system verifies the legitimacy of the restaurant at 288. Verifying the legitimacy of the restaurant 290 may be carried out in any suitable autonomous manner. Many verification technologies currently exist, which are able to search official registers (such as company registers and other official bodies such as health and sanitation authorities) to verify the correctness of information inputted. The choice of an appropriate verification mechanism is within the purview of a person skilled in the art. Once the restaurant has been verified, the restaurant must agree to general terms and conditions. Upon agreement, an account is created and the restaurant may be asked either to agree to specific terms and conditions at 294, or alternatively, may be asked to provide a bond at 293.

[0066] Once a bond has been received at 293 or conditions have been agreed to at 294, the restaurant is verified to sell table on the exchange at 296. Either immediately after creating an account (or sometime thereafter), a restaurant may log onto the exchange at step 297.

[0067] Upon logging into the exchange, the restaurant may remove a table from sale or auction at step 204, or add a table from sale or auction at step 216. If the restaurant wishes to remove a table from sale or auction at step 204, the exchange, at step 206, determines whether the table has been sold. If the table has not been sold (and therefore can be removed from the exchange), the table is verified at not yet sold at step 298, after which the table is removed at step 2100 and the process ends at step 214.

[0068] Conversely, if the restaurant wishes to add a table for sale or auction on the exchange at step 216, a request is sent to the restaurant's floor plan database to retrieve relevant information regarding the table and any other constraint information relevant to the sale of the table. This is then loaded into a temporary list from which tables may be selected for addition to the exchange at step 222, and a guarantee or bond conditions are applied to the table at step 220. Thereafter, at step 224, the temporary list is posted to the exchange, with all relevant information posted in a manner that it may be accessed by a third party through an appropriate interface. It will be understood that the interface may be a web interface, or an app that accesses the exchange via an Application Programming Interface (API) or similar. Thereafter, once the table is posted to the exchange, the process ends at step 214.

[0069] It will be understood that the process steps described above from steps 297 through to 214 may be carried out autonomously upon receipt of a remove or add command from the ResButler system, or may require some interaction with an operator from the Restaurant.

Advantages

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

[0071] Firstly, the exchange provides a seamless mechanism for the sale and resale of tables in a restaurant. To date, there has been no mechanism by which a booked table may be "sold" in a seamless and automated manner. In the past, there has been no reliable method of identifying a booking or the person who made the booking, unless all parties were personally known to each other. As such, bookings were not transferrable in any meaningful manner. This resulted in lost revenue for restaurants. The embodiment herein provides a robust identification mechanism due to the fact that information is transferred between two secure and trusted systems. There is no need for the buyer to verify the identity of the seller, as the data packages sent between the restaurant booking system and the exchange system are independently verified.

[0072] Secondly, the exchange provides a mechanism which is "outside" the booking system of any one restaurant, thereby allowing a restaurant or a person holding a booking to reach a wide audience and in turn, increase the probability of on-selling a table booking. As a corollary, the system operates in an autonomous manner and does not require any special knowledge on the part of the restaurant, the seller or the buyer.

[0073] Thirdly, the restaurant booking system and the exchange, while being integrated, can also work independently.

[0074] Importantly, the embodiment allows not only a "right" to be transferred, but also provides the ability for the new right holder (i.e. the buyer of the booking) to make further variations as required.

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

Disclaimers

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

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

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

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

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

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

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

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

[0084] 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 e 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 e 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 e Minimum chair footprint 450mm by 450mm

Spacing between Tables (allowing for chairs and movement) e Space between rectangular tables 1250mm to 1550mm including chairs e Space between table to table with chair 1050mm only on one side e 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 e 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 e Square meters per patron Counter 1.70 to 1.90 square Service meters e Square meters per patron Fast Food 1.00 to 1.30 square Medium meters e Square meters per patron Table Service, 1.40 to 1.70 square Hotel/Club meters e 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

e 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

e ATH (Available Table Hours)

Revenue

e RTH (Revenue Table Hours)

Utilisation

e TUF (Table Utilisation Factor)

Efficiency

e 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 TotalFood 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 (8)

Claims:

1. A computer-enabled method for the exchange of bookings comprising an user interface accessible by a remote device and in communication with an exchange server, the exchange server including an offer database having at least one booking received from a third party server, the booking including booking information, the booking information having availability information including at least a booking time, duration time and one or more products associated with the booking information within a volumetric space/time framework, the method comprising the steps of, receiving the booking and availability information and formatting the booking and availability information into a form to allow the information to be presented to a user as a variable offer, the variable offer being saved in the offer database on the exchange server, whereby a user interacts with the exchange server via the user interface to search for and select one or more of a plurality of offers, whereby upon the user selecting and varying one or more of the plurality of offers, the user variation is autonomously provided to the third party booking system to update the booking information within the volumetric space/time framework of the third party booking system, whereby the third party booking system processes the variation and provides a response to the exchange server whereby the response is communicated to the user via the exchange server.

2. A computer-enabled method in accordance with claim 1, further including the step of, upon selection of the offer, the user may purchase the offer, whereby upon purchase of the offer, the exchange server provides the user with access to the third party booking system to allow the user to vary at least one of the one or more products or the availability information associated with the booking.

3. A computer-enabled method in accordance with claim 2, further including the step of, upon purchase of the booking, the exchange server performs a transfer operation arranged to transfer control of the booking to the user, whereby the user can re-offer the booking to third parties via the user interface of the exchange.

4. A computer-enabled method in accordance with any one of claims 1 to 3, further including the step of the exchange server providing the user with information to access to the third party booking system to allow the user to change at least one of the booking time, duration time and the one or more products of the booking.

5. A computer-enabled method in accordance with claim 4, further including the step of the exchange server providing an auction interface as part of the user interface, the auction interface being arranged to allow the user to bid for purchase of the offer.

6. A computer-enabled method in accordance with any one of the preceding claims, wherein the booking is related to a restaurant.

7. A computer-enabled method in accordance with any one of claims 1 to 5, wherein the booking is related to one or a combination of a hotel booking, a car rental booking, accommodation booking, entertainment booking, a workspace booking, a library booking, a beauty treatment booking, a medical service booking, or any other booking associated with the provision of a service.

8. A computer-enabled method for the exchange of bookings including an user interface accessible by a remote device being in communication with an exchange server, the method being arranged to receive, at the exchange server, information regarding a restaurant booking, the restaurant booking being received from a third party electronic restaurant booking system, the booking information including at least a booking time and date and a duration time and one or more products associated with the restaurant booking information, comprising the steps of, receiving the booking information and formatting the booking information into an offer, the offer being arranged to be displayable on the user interface, providing the offer information to an offer database on the server arranged to a hold a plurality of offers, whereby a user interacts with the exchange server via the user interface to view one or more of the plurality of offers, whereby upon purchase of one of the plurality of offers, the user is autonomously provided with the ability to access the third party booking system to interact with the booking.