AU2021201205A1 - A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service - Google Patents
A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service Download PDFInfo
- Publication number
- AU2021201205A1 AU2021201205A1 AU2021201205A AU2021201205A AU2021201205A1 AU 2021201205 A1 AU2021201205 A1 AU 2021201205A1 AU 2021201205 A AU2021201205 A AU 2021201205A AU 2021201205 A AU2021201205 A AU 2021201205A AU 2021201205 A1 AU2021201205 A1 AU 2021201205A1
- Authority
- AU
- Australia
- Prior art keywords
- booking
- customer
- interface
- accordance
- constraints
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims abstract description 572
- 238000004590 computer program Methods 0.000 title description 14
- 238000004422 calculation algorithm Methods 0.000 claims abstract description 112
- 230000006854 communication Effects 0.000 claims abstract description 71
- 238000004891 communication Methods 0.000 claims abstract description 68
- 230000008569 process Effects 0.000 claims description 409
- 239000000047 product Substances 0.000 claims description 91
- 238000013473 artificial intelligence Methods 0.000 claims description 30
- 238000012545 processing Methods 0.000 claims description 25
- 238000012384 transportation and delivery Methods 0.000 claims description 12
- 230000000694 effects Effects 0.000 claims description 10
- 238000003066 decision tree Methods 0.000 claims description 6
- 230000004044 response Effects 0.000 claims description 6
- 238000012552 review Methods 0.000 claims description 6
- 239000013589 supplement Substances 0.000 claims description 6
- 230000004308 accommodation Effects 0.000 claims description 4
- 230000003796 beauty Effects 0.000 claims description 2
- 239000002131 composite material Substances 0.000 claims description 2
- 230000006870 function Effects 0.000 description 129
- 238000004458 analytical method Methods 0.000 description 65
- 238000007726 management method Methods 0.000 description 35
- 238000012790 confirmation Methods 0.000 description 27
- 230000010354 integration Effects 0.000 description 25
- 230000004069 differentiation Effects 0.000 description 16
- 235000013305 food Nutrition 0.000 description 16
- 239000004615 ingredient Substances 0.000 description 16
- 235000012054 meals Nutrition 0.000 description 15
- 230000002829 reductive effect Effects 0.000 description 15
- 230000008901 benefit Effects 0.000 description 14
- 230000001737 promoting effect Effects 0.000 description 14
- 230000006399 behavior Effects 0.000 description 13
- 206010020751 Hypersensitivity Diseases 0.000 description 11
- 230000007815 allergy Effects 0.000 description 11
- 238000012544 monitoring process Methods 0.000 description 11
- 235000020930 dietary requirements Nutrition 0.000 description 10
- 238000010411 cooking Methods 0.000 description 9
- 238000002360 preparation method Methods 0.000 description 9
- 230000001419 dependent effect Effects 0.000 description 8
- 238000004519 manufacturing process Methods 0.000 description 8
- 235000013361 beverage Nutrition 0.000 description 7
- 230000008859 change Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000010348 incorporation Methods 0.000 description 6
- 230000036961 partial effect Effects 0.000 description 6
- 101000630730 Homo sapiens Small VCP/p97-interacting protein Proteins 0.000 description 5
- 102100026336 Small VCP/p97-interacting protein Human genes 0.000 description 5
- 208000026935 allergic disease Diseases 0.000 description 5
- 238000009826 distribution Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 230000002452 interceptive effect Effects 0.000 description 5
- 239000000203 mixture Substances 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 238000003860 storage Methods 0.000 description 5
- 244000299461 Theobroma cacao Species 0.000 description 4
- 235000013334 alcoholic beverage Nutrition 0.000 description 4
- 235000021152 breakfast Nutrition 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 4
- 235000019219 chocolate Nutrition 0.000 description 4
- 235000013353 coffee beverage Nutrition 0.000 description 4
- 238000013479 data entry Methods 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 235000019520 non-alcoholic beverage Nutrition 0.000 description 4
- 238000013439 planning Methods 0.000 description 4
- 235000013616 tea Nutrition 0.000 description 4
- 230000000007 visual effect Effects 0.000 description 4
- 235000016213 coffee Nutrition 0.000 description 3
- 235000013409 condiments Nutrition 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 238000012905 input function Methods 0.000 description 3
- 238000005304 joining Methods 0.000 description 3
- 230000033001 locomotion Effects 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 238000003825 pressing Methods 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 235000004789 Rosa xanthina Nutrition 0.000 description 2
- 241000109329 Rosa xanthina Species 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 238000004140 cleaning Methods 0.000 description 2
- 230000001149 cognitive effect Effects 0.000 description 2
- 238000007728 cost analysis Methods 0.000 description 2
- 235000020785 dietary preference Nutrition 0.000 description 2
- 235000021186 dishes Nutrition 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000007639 printing Methods 0.000 description 2
- 238000009877 rendering Methods 0.000 description 2
- 235000014214 soft drink Nutrition 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000001131 transforming effect Effects 0.000 description 2
- 238000012800 visualization Methods 0.000 description 2
- 102100035472 DNA polymerase iota Human genes 0.000 description 1
- 101001094672 Homo sapiens DNA polymerase iota Proteins 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000000172 allergic effect Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 208000010668 atopic eczema Diseases 0.000 description 1
- 235000021167 banquet Nutrition 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 239000006227 byproduct Substances 0.000 description 1
- 235000019993 champagne Nutrition 0.000 description 1
- 230000000052 comparative effect Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000007418 data mining Methods 0.000 description 1
- 238000005034 decoration Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 235000021183 entrée Nutrition 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 235000013410 fast food Nutrition 0.000 description 1
- 239000011521 glass Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 235000021184 main course Nutrition 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 230000003278 mimic effect Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000037361 pathway Effects 0.000 description 1
- 230000000135 prohibitive effect Effects 0.000 description 1
- 230000008707 rearrangement Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000029305 taxis Effects 0.000 description 1
- 230000007306 turnover Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
- 235000014101 wine Nutrition 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
- G06Q10/043—Optimisation of two dimensional placement, e.g. cutting of clothes or wood
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0201—Market modelling; Market analysis; Collecting market data
- G06Q30/0202—Market predictions or forecasting for commercial activities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/12—Hotels or restaurants
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Entrepreneurship & Innovation (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Quality & Reliability (AREA)
- Game Theory and Decision Science (AREA)
- Operations Research (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Data Mining & Analysis (AREA)
- Primary Health Care (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- User Interface Of Digital Computer (AREA)
Abstract
The present invention relates to a computer-enabled method for generating a dynamic, customised
booking interface for allocation of a space in a restaurant by allocation methodologies, or one or
more configurable algorithms. In one embodiment, the customized interface is accessible via a
remote device in communication with a server. The remote device provides to the server an
identifier utilised by the server to identify, in a database in communication with the server, one or
more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of
input mandatory and optional requirements and offers, the input mandatory and optional
requirements and offers being utilised to provide a customised user interface to the remote device.
Description
Cross Reference To Related Application
This application is a divisional application of Australian Patent Application No. 2020200607, 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 and computer program for generating a dynamic user interface for allocation of a space in a restaurant by allocation methodologies, or one or more configurable algorithms.
[0002] In one embodiment, the invention is directed to a computer-enabled method including a user interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a user-specific interface for display on the remote device.
[0003] In one embodiment, the invention is directed to utilising a configurable channel and user identifying widget or app as part of a booking allocation process.
Background
[0004] To better understand the inventive concepts and embodiments of the invention described herein, an abridged history 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.
[0005] To provide flexibility and efficient booking systems, restaurants require the ability to offer customised experiences for customers. Such customised experiences, have, in the past, been solely reliant on the staff of the restaurant performing various tasks manually, including interacting with customers, organising table allocations, providing specialised menus, providing specific ancillary services (such as the provision of flowers, etc.).
la
[0006] The earlier filed PCT applications listed above provide a system and method, which, amongst other tasks, is capable of offering a full and rich set of options to potential customers, including various dining times, menus, ancillary services, etc.
[0007] However, providing such a large range of options/potential outcomes to a customer in a simple and intuitive manner is no simple task. The system and method outlined in the above mentioned PCT applications is required to offer what is potentially a staggering number of interrelated options. To provide such an array of options on a traditional user interface would result in a booking experience that would be overwhelming and frustrating to the average customer. It is known that customers will only engage with user interfaces where the user interface is intuitive and easy to navigate.
[0008] Moreover, it is common nowadays for service providers to provide specific options to some customers and not to others. Sometimes, such options may be "engaged" by the customer inputting a code or providing some other information. However, such systems rely on the customer to input relevant information and can be unreliable.
[0009] There are systems which are arranged to manage enterprise applications. For example, in US 9213850 (Barton et. al., entitled "Policy-Based Application Management"), there is described a technique for managing enterprise applications on mobile devices are described herein. In Barton, each enterprise mobile application running on the mobile device has an associated policy through which it interacts with its environment. The policy selectively blocks or allows activities involving the enterprise application in accordance with rules established by the enterprise. Together, the enterprise applications running on the mobile device form a set of managed applications. Managed applications are typically allowed to exchange data with other managed applications, but are blocked from exchanging data with other applications, such as the user's own personal applications. Policies may be defined to manage data sharing, mobile resource management, application specific information, networking and data access Solutions, device cloud and transfer, dual mode application software, enterprise app store access, and virtualized application and resources, among other things.
[0010] However, the system of Barton does not fundamentally change the manner in which an application appears or operates, it merely restricts the functionality of the managed application. Moreover, the management of the applications occurs through a "policy" which requires a user of the application to identify themselves. Moreover, such policies have no ability to adapt to the manner in which the user interacts with the application. This is due to the fact that the use of "policies" in the context of Barton is not related to providing users with a customised interface to better suit their requirements, but rather is solely concerned with security issues - namely, Barton proposes a solution that restricts access based on a set of rules. It does not seek to provide the most relevant information or to the most engaging or effortless experience for the user. There is no need to be "intelligent" regarding the manner in which applications are managed, as the Barton system is not designed to interact with the user or learn from the user, but rather it is designed to restrict the user.
[0011] In the context of the present specification, the type of "intelligence" referred to is artificial intelligence, and in particular analytical artificial intelligence - namely, the ability of the software to perform tasks that require some form of "cognitive intelligence", including the ability to generate a cognitive representation of a real-world situation, and utilising past learning to inform future decisions.
Summary
[0012] In one aspect, there is provided a computer-enabled method for the allocation of a booking, including a booking interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a customised booking interface on the remote device, comprising the steps of, a booking requestor causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of mandatory and optional input requirements, the mandatory and optional input requirements being utilised to provide instructions to render a customised booking interface having a customised set of input requirements on the remote device; whereby, upon the booking requestor providing at least a portion of the mandatory and optional input requirements via the customised booking interface, the input requirements are utilised by the server to perform an electronic search of a constraint database containing a multi-variate tree of further constraints to identify one or more further input requirements required to complete the booking, the further constraints being utilised to provide further instructions to further customise the booking interface, whereby the process of identifying and providing input requirements is iterated until all mandatory input requirements have been completed by the booking requestor and transmitted to the server; whereby the input information is provided to a dynamic booking module arranged to allocate bookings, whereby the booking module utilises the constraint information to attempt to allocate the booking request and if successful, generates booking allocation information; and upon receiving the relevant booking allocation information, the booking interface provides the booking allocation information to the booking interface.
[0013] In one embodiment, the booking allocation comprises the further step of determining all previously allocated booking requests, creating a virtual pool of allocated booking requests, the pool including the request to be allocated, sorting all booking requests into an allocation order, and re-allocating all bookings from the pool of booking requests utilising an allocation algorithm, whereby if all booking requests are allocated, the booking interface confirms the received booking request.
[0014] In one embodiment, the booking allocation comprises the further step of the booking module utilising the confirmed booking information to generate an optimised allocation instruction set, the instruction set being capable of being displayed on an interface accessible by one or more operators associated with the booking.
[0015] In one embodiment, the optimised allocation instruction set is rendered as a graphical representation of a floor plan of a venue.
[0016] In one embodiment, the identifier includes sub-identifiers.
[0017] In one embodiment, the sub-identifiers include a unique code associated with a specific instance of the user interface.
[0018] In one embodiment, the sub-identifiers include information identifying the booking requestor.
[0019] In one embodiment, the sub-identifiers include information identifying the geographical location of the remote device.
[0020] In one embodiment, the sub-identifiers include information identifying a preferred geographic area associated with the booking requestor.
[0021] In one embodiment, the booking interface is represented by a graphic representing a volumetric framework.
[0022] In one embodiment, the constraints include at least one of an availability by one of a menu and time selected by the booking requestor.
[0023] In one embodiment, the constraints include an availability by a package selected by the booking requestor.
[0024] In one embodiment, the constraints include an availability by a number of guests selected by the booking requestor.
[0025] In one embodiment, the constraint includes an availability by an odd number of guests selected by the booking requestor.
[0026] In one embodiment, the constraints include an availability by a presence of children as selected by the booking requestor.
[0027] In one embodiment, the constraints include an availability by an occasion selected by the booking requestor.
[0028] In one embodiment, the constraints include an availability by a specific table selected by the booking requestor.
[0029] In one embodiment, the constraints include an availability by specific class selected by the booking requestor.
[0030] In one embodiment, the constraints include an availability by a promotion selected by the booking requestor.
[0031] In one embodiment, the constraints include by a booking duration selected by the booking requestor.
[0032] In one embodiment, the constraints include additional items arranged to supplement or enhance a dining experience that can be supplied by a venue.
[0033] In one embodiment, the constraints include additional items arranged to supplement or enhance a dining experience that can be supplied by a third party supplier to the venue.
[0034] In one embodiment, the constraints include additional items arranged to supplement or enhance the dining experience that a venue would allow a booking requestor to bring into the venue
[0035] In one embodiment, the constraints include the provision of incentives for a booking requestor not to leave the booking process prior to the completion of the required mandatory information for the processing of the booking request.
[0036] In one embodiment, the constraints include pre-determined promotions associated with one or more of a booking source, booking identifier, customer identifier, other identifier or sub-identifier.
[0037] In one embodiment, the method comprises the further steps of determining if an additional payment or a pre-payment is required for at least one of the date, time, week, menu, number of guests, children, occasion, booking duration, promotion, and additional items selected by the booking requestor, communicating the requirement to the booking requestor and processing the payment of any pre-payment amount via a payment system.
[0038] In one embodiment, the method comprises the further step of providing a third-party interface arranged to identify third parties authorised by the booking requestor to access information regarding at least one of the booking request and the booking.
[0039] In one embodiment, the method comprises the further step of providing a third-party interface arranged to identify third parties authorised by the booking requestor to pre-order and pre-pay for selected items as part of the booking.
[0040] In one embodiment, the method includes the further step of providing a booking requestor interface for a booking requestor associated with a venue to input the plurality of multi-variate tree of inter-related constraints and offers.
[0041] In one embodiment, the method includes the further step of providing a booking requestor interface for a booking requestor associated with a venue can input the plurality of decision tree, inter-related payment or part payment constraints.
[0042] In one embodiment, the method includes the further step of accessing an artificial intelligence module arranged to receive the booking request information and review one or more of the plurality of constraints to determine whether variation of the one or more constraints to allow a variation to the one or more input requirements and constraints is more likely to result in acceptance of the booking request.
[0043] In one embodiment, the method includes the further step of, if the booking requestor has not entered optional information and the optional information increases the probability of finalising and completing the booking request, the artificial intelligence module is arranged to offer an incentive to the booking requestor to provide optional information.
[0044] In one embodiment, the method includes the further step of, if the one or more of the plurality of requested information is varied and the varied constraints result in achieving a desired outcome, the varied constraints are saved and are used for all subsequent booking requests from booking requestors with similar identifiers and/or sub-identifiers.
[0045] In one embodiment, the interface includes a request message whereby a response is required from the booking requestor before the interface allows the booking requestor to continue with the booking.
[0046] In one embodiment, the interface accesses a database, whereby information from the database is utilised to determine the structure of the interface.
[0047] In one embodiment, the booking requestor interface portions are selectable or variable by the booking requestor directly.
[0048] In one embodiment, the customised user interface is one of a graphical user interface or an audible/speech recognition user interface.
[0049] In another aspect, there is provided a computer-enabled method for the provision of a communications channel arranged to interact with a booking requestor to effect the instructions of the booking requestor via a computing system, the method including the steps of utilising a booking requestor interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a booking requestor-specific interface on the remote device, comprising the steps of, a booking requestor causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of input mandatory and optional requirements and offers, the input mandatory and optional requirements and offers being utilised to provide a customised booking requestor interface to the remote device, including the provision of offers associated with the identifier; whereby, upon the booking requestor providing at least a portion of the input mandatory and optional requirements via the customised interface, the input requirements are utilised by the server to provide offers and search through the multi-variate tree of inter-related further constraints, the multi-variate tree being utilised to determine one or more further input requests displayed on the booking requestor interface associated with the remote device, whereby the process of providing input requirements and traversing the multi-variate tree is iterated until at least all mandatory input requirements have been completed; whereby when all requested input information and additional optional information is captured, such that all input information is in compliance with at least the mandatory information required by the server to proceed, the input information is transferred to a processing module; whereby, the processing module undertakes a process required to effect the instructions of the booking requestor.
[0050] In another aspect, there is provided a computer-enabled method including a booking requestor interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a booking requestor-specific interface on the remote device, comprising the steps of, a booking requestor causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of mandatory and optional input requirements, the mandatory and optional input requirements being utilised to provide instructions to render a customised booking requestor interface to the remote device, the customised booking requestor interface including a layout and information unique to the identifier; whereby, upon the booking requestor providing at least a portion of the mandatory and optional input requirements via the customised interface, the input requirements are utilised by the server to perform an electronic search of a constraint database containing a multi-variate tree of inter-related further constraints, the multi-variate tree being utilised to determine one or more further input requirements which are utilised to provide instructions to render a further customised booking requestor interface to the remote device, whereby the process of providing input requirements and traversing the multi-variate tree is iterated until all mandatory input requirements have been completed; whereby when all requested input information and additional optional information is inputted by the booking requestor, the input information is transferred to a processing module; whereby, the processing module, upon performing the relevant processing steps, confirms processing and provides relevant information to the booking requestor interface.
[0051] In one embodiment, the instruction includes one or a combination of a restaurant booking, a service provider booking, a home delivery service, a shopping/ecommerce service, an airline, a train service, a car rental service, a hotel, accommodation, travel services, cruise services, gyms, hair and beauty services, libraries, workspaces and a communication process where there is a requirement to book a service or purchase a product, or any other services that require the booking of an appointment, including any composite or combination service.
[0052] In another aspect, there is provided a computer-enabled method including a user interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a user specific interface for display on the remote device, comprising the steps of, a user causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of mandatory and optional input requirements, the mandatory and optional input requirements being utilised to provide instructions to render a customised user interface to the remote device, the customised user interface including a layout and information unique to the identifier; whereby, upon the user providing at least a portion of the mandatory and optional input requirements via the customised interface, the input requirements are utilised by the server to perform an electronic search of a constraint database containing a multi-variate tree of inter-related, nested and independent further constraints, the multi-variate tree being utilised to determine one or more further input requirements which are utilised to provide instructions to render a further customised user interface to the remote device, whereby the process of providing input requirements and traversing the multi variate tree is iterated until all mandatory input requirements have been completed; whereby when all requested input information and additional optional information is inputted by the user, such that all input information the server proceeds to a processing stage, whereby the input information is transferred to a processing module; whereby, the processing module, upon performing the relevant processing steps, confirms processing and displays relevant information on the user interface.
[0053] In one embodiment, the processing module is a booking module arranged to allocate bookings, whereby the booking module allocates the booking request together with all previously received booking requests utilising an allocation algorithm, whereby if all booking requests can be allocated; the user interface confirms received booking request; and the confirmed booking information is utilised to produce an optimised allocation instruction set which is utilisable by one or more operators associated with the booking.
[0054] In one embodiment, the optimised allocation instruction set is utilised to book a space in a restaurant.
[0055] In one embodiment, the identifier includes one or more identifiers including sub-identifiers.
[0056] In one embodiment, the sub-identifiers include a unique code associated with a specific instance of the user interface.
[0057] In one embodiment, the sub-identifiers include information identifying the user.
[0058] In one embodiment, the sub-identifiers include information identifying the geographic location of the remote device.
[0059] In one embodiment, the sub-identifiers include information identifying a preferred geographic area associated with the user.
[0060] In one embodiment, the constraints include an availability by a time selected by the user.
[0061] In one embodiment, the constraints include an availability by a menu selected by the user.
[0062] In one embodiment, the constraints include an availability by a package selected by the user.
[0063] In one embodiment, the constraints include an availability by a number of guests selected by the user.
[0064] In one embodiment, the constraint includes an availability by an odd number of guests selected by the user.
[0065] In one embodiment, the constraints include an availability by a presence of children as selected by the user.
[0066] In one embodiment, the constraints include an availability by an occasion selected by the user.
[0067] In one embodiment, the constraints include an availability by a specific table selected by the user.
[0068] In one embodiment, the constraints include an availability by specific class selected by the user.
[0069] In one embodiment, the constraints include an availability by a promotion selected by the user.
[0070] In one embodiment, the constraints include by a booking duration selected by the user.
[0071] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment is required for the date selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0072] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the time selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0073] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the day of the week selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0074] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for this for the menu or menu package selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0075] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the number of guests selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0076] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the odd number of guests selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0077] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the children selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0078] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the occasion selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0079] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the specific table selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0080] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the specific class selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0081] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the specific promotion selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0082] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment required for the booking duration selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0083] In one embodiment, the method comprises the further step of determining if an additional payment or a pre-payment is required for any additional items selected by the user and communicate such payment to the user as well as requesting the payment of any pre-payment amount in communication with a payment system.
[0084] In one embodiment, the method comprises includes the further step of providing a user interface for a user associated with a venue can input the plurality of multi-variate tree of inter-related, nested and independent further constraints and offers.
[0085] In one embodiment, the method comprises includes the further step of providing a user interface for a user associated with a venue can input the plurality of decision tree, inter-related, nested and independent payment or part payment constraints.
[0086] In one embodiment, the method comprises includes the further step of providing an artificial intelligence module arranged to receive the request information and review one or more of the plurality of constraints to determine whether variation of the one or more constraints to allow a variation to the one or more input requirements and constraints to allow an easier path to acceptance of the booking request or offer an incentive to provide the requested information to increase the probability of finalising and completing the requested information for a booking request if it will result in a greater maximisation in the probability of achieving the selected outcome, the one or more of the plurality of requested information are varied and the varied constraints are used for all subsequent booking requests from booking requestors with similar identifiers and sub identifiers
[0087] In one embodiment, the method comprises the further step of the user interface being arranged to, upon receiving input from the user, iteratively select interface portions to display to the user, whereby an interactive interface is provided to the user such that the interface varies dynamically depending on input from the user.
[0088] In one embodiment, the interface portions are iteratively selected dependent upon a decision tree, progress along the decision tree being dependent upon the input from the user.
[0089] In one embodiment, the interface portions may include a pop-up display window whereby a response is required from the user before the interface allows the user to continue with the booking.
[0090] In one embodiment, the interface accesses a database, whereby information from the database is utilised to determine the interface portions to be displayed.
[0091] In one embodiment, the user interface portions are selectable or variable by the user directly.
[0092] In another aspect, there is provided a computer-enabled method for the provision of a communications channel arranged to interact with a user to effect the instructions of the user via a computing system, the method utilising a user interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a user specific interface for display on the remote device, comprising the steps of, a user causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of input mandatory and optional requirements and offers, the input mandatory and optional requirements and offers being utilised to provide a customised user interface to the remote device, including the provision of specific offers and promotions for the identifier;
whereby, upon the user providing at least a portion of the input mandatory and optional requirements via the customised interface, the input requirements are utilised by the server to provide offers and search through the multi-variate tree of inter-related, nested and independent further constraints, the multi-variate tree being utilised to determine one or more further input requests displayed on the user interface associated with the remote device, whereby the process of providing input requirements and traversing the multi-variate tree is iterated until at least all mandatory input requirements have been completed; whereby when all requested input information and additional optional information is captured, such that all input information is in compliance with at least the mandatory information required by the server to proceed, the input information is transferred to a transforming module; whereby, the transforming module undertakes a process required to effect the instructions of the user.
[0093] In one embodiment, the booking may be for one or a combination of a restaurant booking, a service provider booking, a home delivery service, a shopping/ecommerce service, and a communication process where there is a requirement to book a service or purchase a product, or any combination thereof.
Brief Description of the Drawings
[0094] 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:
[0095] 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;
[0096] 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;
[0097] FIG. 1c is a flowchart illustrating a process by which a customer interacts with a widget in accordance with an embodiment of the invention;
[0098] FIGs 1d-1g are screenshots of a widget in accordance with an embodiment of the invention;
[0099] FIGs lh-1j are screenshots of a prior art system;
[00100] FIGs 1k-n are diagrammatic representations of a volumetric framework for providing a complex multi-component product and service in accordance with an embodiment of the invention is based;
[00101] FIGs 2a-2x are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00102] FIGs 3a-3b are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00103] FIGs 4a-4c are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00104] FIGs 5a-5e are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00105] FIGs 6a-6i are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00106] FIGs 7a-7d are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00107] FIGs 8a-8o are screenshots illustrating a computer enabled method for the setup of a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00108] FIGs 9a-9d are screenshots illustrating a computer enabled method for the setup of a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00109] FIGs 10a-10n are screenshots illustrating a computer enabled method for the setup of a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00110] FIGs 11a-11d are screenshots illustrating a computer enabled method for the setup of a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00111] FIGs 12a-12o are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00112] FIGs 13a-13i are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00113] FIGs 14a-d are screenshots illustrating a computer enabled method for the setup of a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00114] FIGs 15a-15d are screenshots illustrating a computer enabled method for the setup of a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00115] FIGs 16a-16o are flowcharts illustrating a computer enabled method for a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00116] FIGs 17a-17d are screenshots illustrating a computer enabled method for the setup of a booking process utilising an app/widget in accordance with an embodiment of the invention;
[00117] FIGs 18a-f are diagrammatic representations of widget configurations in accordance with an embodiment of the invention;
[00118] FIG. 19a is a diagrammatic representation of a voice activated device arranged to interact and mediate a conversation between a user and a system or method in accordance with an embodiment of the invention;
[00119] FIG 20a is a flowchart illustrating a menu pre-ordering and payment process in accordance with an embodiment of the invention;
[00120] FIG 20b is a modular diagram illustrating the components of a widget and a database in accordance with an embodiment of the invention;
[00121] FIG 20c is a flowchart illustrating a product setup procedure to enable a menu configuration in accordance with an embodiment of the invention;
[00122] FIGS 20d-l are screenshots illustrating a product setup (including alternatives) in accordance with an embodiment of the invention;
[00123] FIG 21a 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;
[00124] FIGs 22a-h are screenshots illustrating set-up screens for promotions in accordance with an embodiment of the invention;
[00125] FIGs 23a-23g, are a series of flowcharts illustrating a comparison between the prior art and a system in accordance with an embodiment of the invention;
[00126] FIG 24a is a flow chart depicting the process flow of a personalised booking form in accordance with an embodiment of the invention;
[00127] FIG 24b is a diagrammatic representation of a dashboard interface and a client database in accordance with an embodiment of the invention;
[00128] FIG 24c is a screenshot of a widget channel setup screen including a booking form channel in accordance with an embodiment of the invention;
[00129] Figure 25a is a flowchart depicting a process flow for an urgent email module arranged to operate within a widget or app in accordance with an embodiment of the invention;
[00130] Figure 25b is a partial screenshot of a pop up window or frame within a widget or app in accordance with an embodiment of the invention;
[00131] Figure 25c is a screenshot of a dashboard in accordance with an embodiment of the invention, incorporating a frame within the dashboard in accordance with an embodiment of the invention;
[00132] Figure 25d is a partial screenshot of a further pop up window or frame within a widget or app in accordance with an embodiment of the invention;
[00133] Figure 25e is a partial screenshot of a further pop up window or frame within a widget or app in accordance with an embodiment of the invention; and
[00134] Referring to Figures 26a-d, there are shown screenshots of a widget or app in accordance with an embodiment of the invention.
Detailed Description of Preferred Embodiments
[00135] The present invention relates generally to a computing system, method, computer program and data signal including a user interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a user-specific interface for display on the remote device.
[00136] The method generally comprises the steps of, a user causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of input mandatory and optional requirements and offers, the input mandatory and optional requirements and offers being utilised to provide a customised user interface to the remote device, including the provision of specific offers and promotions for the identifier.
[00137] Upon the user providing at least a portion of the input mandatory and optional requirements via the customised interface, the input requirements are utilised by the server to provide offers and search through the multi-variate tree of inter-related, nested and independent further constraints, the multi-variate tree being utilised to determine one or more further input requests displayed on the user interface associated with the remote device, whereby the process of providing input requirements and traversing the multi-variate tree is iterated until at least all mandatory input requirements have been completed.
[00138] When all requested input information and additional optional information is captured, such that all input information is in compliance with at least the mandatory information required by the server to proceed to a booking stage, the input information is transferred to a booking allocation module, whereby, the allocation module allocates the booking request together with all previously received requests to one or more spaces in the restaurant and if all booking requests can be allocated; whereby, the user interface confirms received booking request, whereby, the confirmed booking information is utilised to produce an optimised allocation instruction set which is utilisable by one or more users associated with the restaurant.
[00139] The embodiment also comprises, for the purposes of providing an example of the use of the broader inventive concept, an allocation module which is in communication with a processor. The allocation module includes an intelligent algorithm that mimics the thought processes of a person who would perform the role of allocating tables to bookings. In technical terms, the embodiment is arranged to receive the at least one request and communicate with a database via a processor to determine whether other requests for spaces have been made by other remote users.
[00140] If other requests for spaces have been made by other booking requestors, the allocation module either on receipt of a request or upon the activation of a trigger event utilises the processor to retrieve information regarding the other requests for the one or more spaces and combines the at least one request with the other requests to form a pool of requests, retrieve constraint information regarding the venue, and iteratively allocate all requests from the pool of requests utilising the constraint information to produce an optimised space allocation instruction set, wherein the optimised space allocation instruction set is saved in the database and provided by a space allocation user interface to one or more users associated with the venue. However, this is one embodiment of the invention and further examples of analogous and different uses are also provided in the detailed description below.
[00141] In the following description of an embodiment, specific terms will be used to broadly define particular features or aspects of the inventive concept or the information utilised to allocate a booking request, within the context of a specific example embodiment, namely the allocation of bookings in a restaurant. However, it will be understood that the invention has broader application than the allocation of bookings in a restaurant. Examples of the use of the interface are provided outside of the booking of restaurants.
The Computing System
[00142] One embodiment of the computing system is shown at FIG. la.
[00143] 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.
[00144] 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.
[00145] 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.
[00146] 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.
[00147] 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.
[00148] 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.
[00149] 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.
[00150] 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.
[00151] 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.
[00152] 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.
[00153] 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.
[00154] Referring to Figure 1c, there is shown a block diagram illustrating a high level process flow of a restaurant and function booking widget 156 in accordance with an embodiment of the invention. The widget 156 begins when a user selects a date 158 and selects a venue 160. The user then selects either a restaurant area 162 or a function area 168. If a restaurant area 162 is selected the process continues to process flow 164 and a restaurant booking flow is followed 166. Alternatively, if a function area is selected 168 then the process continues to process flow 164 and a function booking flow 170 is selected.
[00155] Referring to Figure 1d, there is shown a first landing screen for an interface in accordance with an embodiment of the invention. The ResButler system provides a facility for both known customers 172 and first-time customers 174. If the customer is known, a second dialogue box allows the customer to enter an identifier, such as their email address, before continuing. The process then continues along arrow A to Figure le.
[00156] Referring to Figure le, which continues from arrow A of Figure 1d, there are shown a number of options. As can be seen in the screenshot of Figure le, the user has identified themselves (180) and therefore the pull down menu items provided to the customer are a function of customer information and also constraint information. At menu 182, the customer chooses a restaurant, and at 184 chooses a particular area in the restaurant. Subsequently, based on previous bookings in the restaurant and particular area of the restaurant, a calendar 186 is displayed, at which the customer chooses a date. Subsequently, depending on the date selected, available services (e.g. breakfast, lunch, dinner) are shown at 188. The customer selects a service, and then enters the number of guests at 190. At 192, the customer selects whether children will be dining. At step 194, the customer is then provided with the choice as to which constraint is most important (this aspect is described in more detail later). For example, in the screenshot shown, the customer selects the ability to choose a specific table and subsequently selects table 86. In some embodiments, as the customer is known, this field may be prepopulated with the customer's favourite table. This results in a to scale image of the restaurant to appear at 198, so that the customer may visually confirm that they have selected the correct table.
[00157] The interface also provides information on any special conditions attached to the specific table, such as an additional charge at 1000. The customer then selects a second choice as to which constraint is the next most important at 1002, which in the example screenshot is availability by menu. The customer then selects a menu at 1004 (further information about menus can be accessed via link 1006). Based on the information provided, the system then utilises the algorithm to provide a selection of potentially available times at 1008, from which the user can select a desired time. A summary is then provided at 1010 and the option is provided to extend the provisionally allocated dining time. The customer can then confirm the booking request at 1012, and the process continues along arrow B to Figure 1f.
[00158] Referring to Figure 1f, which is a continuation from arrow B of Figure le, there is shown a summary and payment screen. At 1014 and 1016 there is shown a summary of additional items, and at 1018 there is shown the total amount to be prepaid. At 1020, 1022, 1024, 1026, 1028 and 1030 there is provided input boxes for payment (credit card) details, although it will be understood that any other suitable form of electronic payment may be incorporated into the widget, as different manners of payment become available from time to time. For example, direct deposit payment systems such as POLI and cryptocurrency payment systems are also envisaged.
[00159] The customer then selects check box 1032 to confirm that they agree to the terms and conditions of the booking, and then submits the booking at 1034. Thereafter, if the booking is successful, a screen 1036 is displayed, which provides a summary of the booking 1038, and the ability to invite guests at 1040. If the user wishes to invite guests, the system allows the user to input guest names (1042 and 1048), guest emails (1044 and 1050), and messages for the guests (1046 and 1052). This information is then packed into an email and sent by the system on behalf of the customer by clicking on button 1054. Moreover, the customer may also pre-order their meal form the menu by clocking on button 1056.
[00160] Referring to Figure 1g, there is now shown the same widget, but for an instance where the customer has not identified themselves. The unidentified customer may still select certain constraints, but is more limited, as no customer constraint information is available to personalise the choices available to the customer. At 1058, the customer selects a restaurant, and the customer subsequently selects an area or room in the restaurant at 1060. Available dates are then shown at 106, and the customer selects a service at 1064. The customer then selects the number of guests at 1066, and then chooses a constraint at 1068, which in this case is availability by menu. The customer subsequently selects a menu at 1070. The customer then selects a further constraint at 1072 and is presented with available times at 1074. A summary and option to extend the booking is provided at 1076, after which the customer can conform their details at 1078.
[00161] Therefore, as can be seen in Figures id-1f and Figure 1g, the widget/interface provides a very comprehensive method of making a booking, which collects constraint information from the customer in a manner that is intuitive and guides the customer through the booking process, without displaying fields that are not relevant to the customer. The interface is dynamic, with fields appearing or not appearing based on previous selections and based on existing constraint information regarding the customer and the venue, as well as options that have been selected ordeselected for the channel of the widget (which will be described in more detail below).
[00162] The interface in accordance with an embodiment is in stark contrast to known booking system interfaces, which are briefly described with reference to Figures lh-1j.
[00163] Referring to Figure 1h there is shown a screenshot 1080 of a prior art interface. To make a reservation, the customer simply selects a party size at 1084, a date at 1086 and a time at 1088, and a time at 1090, and is provided with some measure of the popularity of the restaurant at 1092. In the prior art example, the interface does not dynamically vary, nor is the customer provided with any ability to choose constraints that are of interest to the customer.
[00164] Referring to Figure li, there is shown a screenshot 1094 of a further interface of the prior art. The customer is provided with a summary of their intended booking date and time at 1096 and 1098, with the number of people selected shown at 1100. The customer is then provided with the ability to sign in or sign up using input boxes 1102, 1104, 1106 and 1108. While the customer may select an occasion at 1110 and add a special request 1112, these items are not integrated with the booking system in any manner. Rather they are simply sent as messages to the restaurant, and it is incumbent on a person in the restaurant to action any requests. The user may ten select to be placed on a mailing list at 1116 and receive updates at 1118, before completing their reservation by clicking button 1120.
[00165] Referring to Figure 1j, there is shown a screenshot of a booking confirmations screen in accordance with the prior art. At 1124 and 1126, booking confirmation information is displayed. At 1128 and 1130, the customer may manually add further information, but such information does not inform the booking process, it is merely passed to the restaurant as a message.
[00166] As can be seen, there is absolutely no integration between the identity of the customer and the booking request, nor does the customer have any ability to customise their dining experience, beyond simply making a manual request to the restaurant.
[00167] Referring now to Figures. 1k-m, 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.
[00168] Broadly, referring to FIG. 1k, 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 168 operates across three axes, generically labelled the x axis 172, the y-axis 166 and the z-axis 170. 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. 11.
[00169] Referring to FIG. 11, there is shown the three-dimensional framework 180 with dimension x 178, dimension y 174 and dimension z 176, compared to a prior art framework 182 which illustrates a Gantt chart 188 including a first dimension 184 and a second dimension 186.
[00170] Referring to FIG. 1m there is described a practical application of the concept of FIG. 1g where the framework 196 with dimensions x 198, y 192 and z 194 are located within the context of a posting calendar, which is arranged to interact with a user-defined reporting calendar 101. This reduction to practice is further described with reference to FIG. 1j, where a restaurant floor plan is overlaid on the three-dimensional framework. In more detail, a floor plan creation module 103 is utilised to create a floor plan for a restaurant, including the size and shape of the restaurant space, the creation of sub-areas and sections, the division of the areas and/or sub areas into classes, the addition of tables and chairs (including dimensions), etc. The floor plan is placed in the volumetric framework 109 within the calendar 107, where the x and y axes represent the length and width of the space, and the z axis represents time. As such, each area, sub area, class, table, chair, etc. can be tracked over time. The z axis is controlled by a time constraint module 113 which includes time constraints 115 such as opening hours, seating periods, etc.
[00171] 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).
[00172] Referring to Figures 2a-x, there is shown a flowchart for a user creating a restaurant booking, which shows the various paths and outcomes that can result from a user's unique interaction with the booking widget.
[00173] Turning to Figure 2a there is shown a widget flow chart for restaurant bookings. In particular a first phase (phase one) is shown. At step 200 the venue options are displayed to the user. At step 202 the venue is selected by the user utilising the information regarding the venue, the widget returns relevant date options at step 204 and a user selects a relevant date at step 206. Utilising the date selected, the widget returns relevant service options which are displayed to the user at step 208.
[00174] The user selects a service at step 210. Utilising the service selection, the widget displays the options available for the number of guests at step 212. At step 214 the number of guests is selected by the user. Optionally, at step 216 the widget may display a customised message to inform the user that children under a certain age cannot be catered for at the venue. Additionally, the widget at step 218 displays a tick box that allows the user to provide information that states that they wish to include children as guests. The process flow then continues as indicated by arrow B to Figure 2b where at step 220 the user either selects or does not select the option of including children as guests. If children are included as guests, the algorithm proceeds to step 2142 where a prompt is provided to allow the user to input the number of children. The user inputs the number of children at step 2144 and a further option is displayed, asking the user to select the number of high chairs required 2146. When step 2148 has been completed, the process continues to step 222. Similarly, if no children are to be guests, the process continues directly to step 222 where area options are displayed including a two dimensional representation of the restaurant floor plan. At this stage, the user may select one of three principal options. Firstly, the user may select a main dining room at step 224, a bar area at step 2108 or a private dining room at step 2820. Irrespective of the option chosen, relevant availability filters are displayed as shown at steps 226. If the main dining room or the bar is selected, identical process flows are followed as described at step 2112 and as indicated by arrows labelled one, which refers to Figure 2c. Alternatively, if a private dining room is selected the process continues along the path indicated by the arrow labelled 3 which is continued at Figure 2x.
[00175] Turning to Figure 2c, the user selects availability based on one of a number of criteria. For example, a user may select availability by menu 228, by time 236, by occasion 244, by specific table 252 or by specific class 2180 or by other options shown by arrow C, which is later described with regard to Figure 2d.
[00176] If the user selects by menu at 228, available menus constrained by previous inputs are loaded and displayed at 230. The user selects a menu at 232, after which the process then proceeds along arrow Al, which is described later with regard to Figure 2e.
[00177] If the user selects by time at 236 available times constrained by previous inputs are loaded and displayed at 238. The user selects a time at 240. The process then proceeds along arrow B1, which is described later with regard to Figure 2h.
[00178] If the user selects by occasion at 244 available occasions constrained by previous inputs are loaded and displayed at 246. The user selects an occasion at 248. The process then proceeds along arrow C1, which is described later with regard to Figure 2k.
[00179] If the user selects by specific table, at 252 available tables constrained by previous inputs are loaded and displayed at 254. As will be described later with regard to Figure 8c, the availability of a table (or the ability to select a specific table from a sub-set of appropriate tables, or the ability to purchase a table) is an option that is selectable by the operator. That is, this option may or may not be available to the requestor dependent on the options selected by the operator in the setup screens for the channels as described in more detail with regard to Figure 8 generally. In short, the options may include displaying by class, by price, or by the number of guests associated with a booking request, or any other suitable constraint or attribute. Therefore, step 254, 256 and subsequent steps related to step 254 should be read in the context of Figure 8. The user selects a specific table at 256. The process then proceeds along arrow D1, which is described later with regard to Figure 2n.
[00180] If the user selects by specific class at 2180, available classes constrained by previous inputs are loaded and displayed at 2182. The user selects a class at 2184. The process then proceeds along arrow D1, which is described later with regard to Figure 2n.
[00181] Referring to Figure 2d there is shown a continuation of the flow chart from Figure 2c, including two further availability options, namely availability by bidding for a specific table or class 2226 and availability by promotion 2328. If the user selected availability by bidding at 2226, table availability by menu and time are displayed at 2228. If the user selected by menu 228, available menus constrained by previous inputs are displayed at 230, the user selects a menu at 232, available time intervals are displayed at 238, and bidding availability filters are displayed at 2230, before the process continues along arrow El which is described later with regard to Figure 2t. Alternatively, if the user selected by time 236, available times constrained by previous inputs are displayed at 238, the user selects a time at 240, available time intervals are displayed at 230, and bidding availability filters are displayed at 2230, before the process continues along arrow El which is described later with regard to Figure 2t.
[00182] If the user selected availability by promotion 2328, the user is displayed available promotions constrained by previous inputs, as shown at 2330, before the process continues along arrow Fl which is described later with regard to Figure 2u.
[00183] Referring to Figure 2e there is shown a continuation of the booking process and flowchart from arrow Al. Figure 2e is also connected to Figure 2f via arrow D. In Figure 2e, the customer may select availability by time 236 or availability by occasion 244 (and other options are selectable, as will be described with reference to Figure 2f). If the customer selects availability by time 236, available time intervals (as constrained by previous constraints and venue constraints) are displayed on the interface at 238, and at step 240 the customer selects a time interval. The remaining availability options are availability by occasion 244, availability by specific table 252 and availability by class 2180. If the customer selects availability by occasion at 244, the available occasions, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248 then continues to Figure 2g (as shown by arrow A2).
[00184] Alternatively, if the customer selects availability by specific table at 252, the available specific tables, constrained by all previous customer selections and venue constraints, are displayed at step 254, after which the customer selects a table at step 256 then continues to Figure 2g (as shown by arrow A3).
[00185] If the customer selects availability by specific class at 2180, the available specific classes, constrained by all previous customer selections and venue constraints, is displayed at step 2182, after which the customer selects a specific class at step 2184 then continues to Figure 2g (as shown by arrow A4).
[00186] Returning to step 244, if the customer has selected by occasion, available occasion options (as constrained by previous constraints and venue constraints) are displayed on the interface at 246, and at step 248 the customer selects an occasion. The remaining availability options are availability by time 236, availability by specific table 252 and availability by class 2180. If the customer selects availability by time at 236, the available times, constrained by all previous customer selections and venue constraints, is displayed at step 238, after which the customer selects a time at step 240 then continues to Figure 2g (as shown by arrow A5).
[00187] Alternatively, if the customer selects availability by specific table at 252, the available specific tables, constrained by all previous customer selections and venue constraints, is displayed at step 254, after which the customer selects a table at step 256, then continues to Figure 2g (as shown by arrow A6).
[00188] If the customer selects availability by specific class at 2180, the available specific classes, constrained by all previous customer selections and venue constraints, is displayed at step 2182, after which the customer selects a specific class at step 2184 then continues to Figure 2g (as shown by arrow A7).
[00189] Referring to Figure 2f, which is connected to Figure 2e via arrow D, the customer may select availability by specific table 252 or availability by class 2180 (and other options are selectable, as was described with reference to Figure 2e). If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 a specific table is selected. The remaining availability options are availability by time 236 and availability by occasion 244. If the customer selects availability by time at 236, the available times, constrained by all previous customer selections and venue constraints, is displayed at step 238, after which the customer selects a time at step 240 and an occasion at step 248 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00190] Alternatively, if the customer selects availability by occasion at 244, the available occasion types, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248, after which the customer selects a time at step 240 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00191] Returning to step 2180, if the customer selects availability by class, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class. The remaining availability options are availability by time 236 and availability by occasion 244. If the customer selects availability by time at 236, the available times, constrained by all previous customer selections and venue constraints, is displayed at step 238, after which the customer selects a time at step 240 and an occasion at step 248 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00192] Alternatively, if the customer selects availability by occasion at 244, the available occasion types, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248, after which the customer selects a time at step 240 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00193] Referring to Figure 2g, there is shown a continuation of the process flow of Figure 2e, and in particular of the process flows indicated by arrows A2, A3, A4, A5, A6 and A7. Referring firstly to the process flow from arrow A2, the customer may select availability by specific table 252 or availability by class 2180. If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 the customer selects a table, and the process continues along arrow 4, which is described in more detail in Figure 20. Alternatively, if the customer selects by class 2180, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00194] Referring now to the process flow from arrows A3 and A4, at 246 available occasions constrained by previous inputs are displayed and at step 248 the customer selects an occasion, and the process continues along arrow 4, which is described in more detail in Figure 20.
[00195] Referring now to the process flow from arrow A5, the customer may select availability by specific table 252 or availability by class 2180. If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 the customer selects a table, and the process continues along arrow 4, which is described in more detail in Figure 20. Alternatively, if the customer selects by class 2180, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00196] Referring now to the process flow from arrows A6 and A7, at 238 available times constrained by previous inputs are displayed and at step 240 the customer selects a time, and the process continues along arrow 4, which is described in more detail in Figure 20.
[00197] Referring to Figure 2h there is shown a continuation of the booking process and flowchart from arrow B1. Figure 2h is also connected to Figure 2i via arrow E. In Figure 2h, the customer may select availability by menu 228 or availability by occasion 244 (and other options are selectable, as will be described with reference to Figure 2i). If the customer selects availability by menu 228, available menus (as constrained by previous constraints and venue constraints) are displayed on the interface at 230, and at step 232 the customer selects a menu, The remaining availability options are availability by occasion 244, availability by specific table 252 and availability by class 2180. If the customer selects availability by occasion at 244, the available occasions, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248 then continues to Figure 2j (as shown by arrow B2).
[00198] Alternatively, if the customer selects availability by specific table at 252, the available specific tables, constrained by all previous customer selections and venue constraints, is displayed at step 254, after which the customer selects a table at step 256 then continues to Figure 2j (as shown by arrow B3).
[00199] If the customer selects availability by specific class at 2180, the available specific classes, constrained by all previous customer selections and venue constraints, is displayed at step 2182, after which the customer selects a specific class at step 2184 then continues to Figure 2j (as shown by arrow B4).
[00200] Returning to step 244, if the customer has selected by occasion, available occasion options (as constrained by previous constraints and venue constraints) are displayed on the interface at 246, and at step 248 the customer selects an occasion. The remaining availability options are availability by menu 228, availability by specific table 252 and availability by specific class 2180. If the customer selects availability by menu at 228, the available menus, constrained by all previous customer selections and venue constraints, is displayed at step 230, after which the customer selects a menu at step 232then continues to Figure 2j (as shown by arrow B5).
[00201] Alternatively, if the customer selects availability by specific table at 252, the available specific tables, constrained by all previous customer selections and venue constraints, is displayed at step 254, after which the customer selects a table at step 256 then continues to Figure 2j (as shown by arrow B6).
[00202] If the customer selects availability by specific class at 2180, the available specific classes, constrained by all previous customer selections and venue constraints, is displayed at step 2182, after which the customer selects a specific class at step 2184 then continues to Figure 2j (as shown by arrow B7).
[00203] Referring to Figure 2i which is connected to Figure 2h via arrow E, the customer may select availability by specific table 252 or availability by class 2180 (and other options are selectable, as was described with reference to Figure 2h). If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 the customer selects a table. The remaining availability options are availability by time 236 and availability by occasion 244. If the customer selects availability by time at 236, the available times, constrained by all previous customer selections and venue constraints, is displayed at step 238, after which the customer selects a time at step 240 and an occasion at step 248 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00204] Alternatively, if the customer selects availability by occasion at 244, the available occasion types, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248, after which the customer selects a time at step 240 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00205] Returning to step 2180, if the customer selects availability by class, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class. The remaining availability options are availability by time 236 and availability by occasion 244. If the customer selects availability by time at 236, the available times, constrained by all previous customer selections and venue constraints, is displayed at step 238, after which the customer selects a time at step 240 and an occasion at step 248 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00206] Alternatively, if the customer selects availability by occasion at 244, the available occasion types, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248, after which the customer selects a time at step 240 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00207] Referring to Figure 2j there is shown a continuation of the process flow of Figure 2h, and in particular of the process flows indicated by arrows B2, B3, B4, B5, B6 and B7. Referring firstly to the process flow from arrow B2, the customer may select availability by specific table 252 or availability by class 2180. If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 the customer selects a table, and the process continues along arrow 4, which is described in more detail in Figure 20. Alternatively, if the customer selects by class 2180, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00208] Referring now to the process flow from arrows B3 and B4, at 246 available occasions constrained by previous inputs are displayed and at step 248 the customer selects an occasion, and the process continues along arrow 4, which is described in more detail in Figure 20.
[00209] Referring now to the process flow from arrow B5, the customer may select availability by specific table 252 or availability by class 2180. If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 the customer selects a table, and the process continues along arrow 4, which is described in more detail in Figure 20. Alternatively, if the customer selects by class 2180, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00210] Referring now to the process flow from arrows B6 and B7, at 230 available menus constrained by previous inputs are displayed and at step 232 the customer selects a menu, and the process continues along arrow 4, which is described in more detail in Figure 20.
[00211] Referring to Figure 2k there is shown a continuation of the booking process and flowchart from arrow C1. Figure 2k is also connected to Figure 21 via arrow F. As shown by Figure 2k, the customer may select availability by time 236 or availability by menu 228 (and other options are selectable, as will be described with reference to Figure 21). If the customer selects availability by time 236, available times (as constrained by previous constraints and venue constraints) are displayed on the interface at 238, and at step 240 the customer selects a time,. The remaining availability options are availability by occasion 244, availability by specific table 252 and availability by class 2180. If the customer selects availability by occasion at 244, the available occasions, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248 then continues to Figure 2m (as shown by arrow C2).
[00212] Alternatively, if the customer selects availability by specific table at 252, the available specific tables, constrained by all previous customer selections and venue constraints, is displayed at step 254, after which the customer selects a table at step 256 then continues to Figure 2m (as shown by arrow C3).
[00213] If the customer selects availability by specific class at 2180, the available specific classes, constrained by all previous customer selections and venue constraints, is displayed at step 2182, after which the customer selects a specific class at step 2184 then continues to Figure 2m (as shown by arrow C4).
[00214] Returning to step 228, if the customer has selected by menu, available menus (as constrained by previous constraints and venue constraints) are displayed on the interface at 230, and at step 232 the customer selects a menu. The remaining availability options are availability by occasion 244, availability by specific table 252 and availability by class 2180. If the customer selects availability by occasion at 244, the available occasions, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248 then continues to Figure 2m (as shown by arrow C5).
[00215] Alternatively, if the customer selects availability by specific table at 252, the available specific tables, constrained by all previous customer selections and venue constraints, is displayed at step 254, after which the customer selects a table at step 256 then continues to Figure 2m (as shown by arrow C6).
[00216] If the customer selects availability by specific class at 2180, the available specific classes, constrained by all previous customer selections and venue constraints, is displayed at step 2182, after which the customer selects a specific class at step 2184 then continues to, Figure 2m (as shown by arrow C7).
[00217] Referring to Figure 21 which is connected to Figure 2k via arrow F, the customer may select availability by specific table 252 or availability by class 2180 (and other options are selectable, as was described with reference to Figure 2k). If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 the customer selects a table. The remaining availability options are availability by time 236 and availability by occasion 244. If the customer selects availability by time at 236, the available times, constrained by all previous customer selections and venue constraints, is displayed at step 238, after which the customer selects a time at step 240 and an occasion at step 248 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00218] Alternatively, if the customer selects availability by occasion at 244, the available occasion types, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248, after which the customer selects a time at step 240 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00219] Returning to step 2180, if the customer selects availability by class, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class, The remaining availability options are availability by time 236 and availability by occasion 244. If the customer selects availability by time at 236, the available times, constrained by all previous customer selections and venue constraints, is displayed at step 238, after which the customer selects a time at step 240 and an occasion at step 248 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00220] Alternatively, if the customer selects availability by occasion at 244, the available occasion types, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248, after which the customer selects a time at step 240 and the process continues along arrow 4, which is described in more detail in Figure 20.
[00221] Referring to Figure 2m there is shown a continuation of the process flow of Figure 2k, and in particular of the process flows indicated by arrows C2, C3, C4, C5, C6 and C7. Referring firstly to the process flow from arrow C2, the customer may select availability by specific table 252 or availability by class 2180. If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 the customer selects a table, and the process continues along arrow 4, which is described in more detail in Figure 20. Alternatively, if the customer selects by class 2180, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00222] Referring now to the process flow from arrows C3 and C4, at 230 available menus constrained by previous inputs are displayed and at step 232 the customer selects a menu, and the process continues along arrow 4, which is described in more detail in Figure 20.
[00223] Referring now to the process flow from arrow C5, the customer may select availability by specific table 252 or availability by class 2180. If the customer selects availability by specific table 252, available tables (as constrained by previous constraints and venue constraints) are displayed on the interface at 254, and at step 256 the customer selects a table, and the process continues along arrow 4, which is described in more detail in Figure 20. Alternatively, if the customer selects by class 2180, available classes (as constrained by previous constraints and venue constraints) are displayed on the interface at 2182, and at step 2184 the customer selects a specific class, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00224] Referring now to the process flow from arrows C6 and C7, at 238 available times constrained by previous inputs are displayed and at step 240 the customer selects a time, and the process continues along arrow 4, which is described in more detail in Figure 20.
[00225] Referring to Figure 2n, there is shown a continuation of the process flow from arrow D1 of Figure 2c. The customer may select availability by time 236, availability by occasion 244 or availability by menu 228. If the customer selects availability by time 236, available time intervals (as constrained by previous constraints and venue constraints) are displayed on the interface at 238, and at step 240 the customer selects a time interval. The remaining availability options are availability by occasion 244 and availability by menu 228. If the customer selects availability by occasion at 244, the available occasions, constrained by all previous customer selections and venue constraints, is displayed at step 246, after which the customer selects an occasion at step 248 and available menus are displayed at 230, after which the customer selects a menu at 232, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00226] Alternatively, if the customer selects availability by menu at 228, the available menus, constrained by all previous customer selections and venue constraints, are displayed at step 230, after which the customer selects a menu at step 232 and available occasions are displayed at 246, after which the customer selects an occasion at 248, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00227] Returning to step 244, if the customer selects availability by occasion 244, available occasions (as constrained by previous constraints and venue constraints) are displayed on the interface at 246, and at step 248 the customer selects an occasion. The remaining availability options are availability by time 236 and availability by menu 228. If the customer selects availability by time at 236, the available times, constrained by all previous customer selections and venue constraints, are displayed at step 238, after which the customer selects a time at step 240 and available occasions are displayed at 246, after which the customer selects an occasion at 248, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00228] Alternatively, if the customer selects availability by menu at 228, the available menus, constrained by all previous customer selections and venue constraints, are displayed at step 230, after which the customer selects a menu at step 232. The remaining availability option is availability by time where available time intervals constrained by previous inputs are loaded and displayed at step 238, after which the customer selects a time interval at step 240 before the process continues along arrow 4, which is described in more detail in Figure 20.
[00229] Returning to step 228, following directly from arrow D1, if the customer selects availability by menu 228, available menus (as constrained by previous constraints and venue constraints) are displayed on the interface at 230, and at step 232 the customer selects a menu. The remaining availability options are availability by time 236 and availability by occasion 244. If the customer selects availability by time at 236, the available times constrained by all previous customer selections and venue constraints, are displayed at step 238, after which the customer selects a time at step 240 and available occasions are displayed at 246, after which the customer selects an occasion at 248, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00230] Alternatively, if the customer selects availability by occasion at 244, the available occasions, constrained by all previous customer selections and venue constraints, are displayed at step 246, after which the customer selects an occasion at step 248 and available times are displayed at 238, after which the customer selects a time at 240, before the process continues along arrow 4, which is described in more detail in Figure 20.
[00231] Referring to Figure 20 there is shown a continuation of the booking process from arrow 4, where at step 258, a booking duration is calculated and displayed for the constraints selected, and subsequently booking duration extension options are displayed at step 260. If the user selected an extension option at 262, then at 263 an extension value is selected and the process continues to step 264. Alternatively, if no extension is selected, the process continues directly to 264.
[00232] At step 264 the send booking request button is enabled, and the user is able to click the send booking button at step 266. The booking request is subsequently sent via an API link, at step 268 and at step 270, the algorithm processes the booking request, and thereafter the process continues along arrow G which is continued in Figure 2p.
[00233] Referring to Figure 2p, there is shown the process flow that continues from Figure 20 via arrow G. At step 2192 the booking request is not allocated (due to an inability to allocate the booking given the constraints), so the process continues to step 2194, where the allocation/optimisation algorithm searches for and locates an alternative time and/or a shortened duration. The application or widget then displays, at step 2196, a popup with one or more alternative booking options. At this stage, the user has one of four options. The user may select an alternative time 2198, select a shortened time 2204, elect to join a waitlist 2208, or cancel the booking 2222.
[00234] If the user selects an alternative time 2198, an edited booking request is sent 2200 from the app or widget to the ResButler system and the Allocation/Optimisation processes the booking request at step 270, before continuing the process as shown by arrow 5 (which is continued in Figure 2q). Alternatively, if the user selects a shortened booking duration 2204, optionally an incentive may be offered at step 2206, after which an edited booking request is sent 2200 from the app or widget to ResButler and the Allocation/Optimisation processes the booking request at step 270, before continuing the process as shown by arrow 5 (which is continued in Figure 2q).
[00235] If the user elects to join a waitlist at step 2208, the user's details are displayed as per step 2210. The user then inputs or amends and confirms the details at step 2212, and a waitlist request is sent to the allocation algorithm at step 2214, the allocation algorithm creating a waitlist booking at step 2216, where a receipt of the waitlist booking is sent to the user at 2218 and the process ends at 2220.
[00236] If the user decides to cancel the booking at step 2222, the booking widget or app returns to a splash screen and/or closes at step 2224, and the process ends at step 2220.
[00237] Referring to Figure 2q there is shown a continuation of the booking process from arrow 5. At step 272, the booking request is temporarily allocated. At step 274, various details and inputs of the booking request are displayed, and at step 276, the customer details are input. Optionally at step 278 alternate contact details may be displayed. If at step 280 the alternate contact details option is selected, then at step 281 alternate contact details are displayed and alternate contact details are input and submitted at 283, and the process continues to step 284. Alternatively, if no alternate contact details are selected at 280, the customer details are submitted at 282 and the additional booking details are displayed at 284, where the additional booking details are input by the user at 286 and the process continues along arrow H, which is described with reference to Figure 2r.
[00238] Referring to Figure 2r, which continues the process flow described with reference to Figure 2q as shown by arrow H, at step 288 there is provided an optional step of selecting concierge service items requiring pre-payment and pre ordering. Depending on user input, the user is taken along one of four paths. The user may select options only requiring pre-payment 290, requiring both pre payment and pre-ordering 291, only requiring pre-ordering 2120 or the user may not select any concierge service items 2121. If the selected concierge items require some form of pre-payment (i.e. options 290 and 291), the system checks to determine whether the user has previously selected options that require the provision of payment details such as extended duration or a special menu, at step 292 and then proceeds along arrow 6, wherein the ensuing process flow is described with reference to Figure 2s. Conversely, if the concierge service items only require pre-ordering 2120 or no concierge service items are selected 2121, the process flow continues to step 2122 and a determination is made as to whether there is a requirement to submit payment details at step 2122. If so, then the process proceeds along arrow 6, wherein the ensuing process flow is described with reference to Figure 2s. Alternatively, if no payment details need to be submitted, the process proceeds along arrow 7, wherein the ensuing process flow is described with reference to Figure 2s. In other words, the concierge service option allows the user to select optional items which enhance the dining experience but are not necessarily an ordinary part of booking a table at a restaurant. For example, the concierge service items may include flowers, entertainment, or other third-party products and/or services.
[00239] Referring now to Figure 2s, there is shown a continuation of the process flow of Figure 2r, including the process flows denoted by arrow 6 and arrow 7 in Figure 2r. Referring firstly to arrow 6, at step 294 payment options relevant to previously selected constraints are shown. The user then selects a payment option at step 296, selected payment option inputs are displayed at step 298, and the user inputs selected payment option details at step 2100. Optionally, there may be displayed an option to join a mailing list at step 2102. Terms and conditions relevant to the booking request are displayed at step 2104. Consequently, if payment is not processed successfully at step 2106, then the process returns to step 298. If payment is processed successfully at step 2107, the booking confirmation is displayed at step 2109, and the process ends at step 2220. Returning to arrow 7, which is a continuation of the process flow described in Figure 2r, at step 2102 an option to join the mailing list is displayed and terms and conditions are displayed, and consequently a user submits their accidence to the terms and conditions at step 2104. The process then displays a booking confirmation at step 2109 and the process ends at step 2220.
[00240] Referring to Figure 2t, there is shown a process flow that continues from arrow El, which is a continuation of the process flow described in Figure 2d. The user has the ability to select by bidding for a specific table 2300, or bidding for a specific class 2322. If bidding for a specific table 2300, a list of specific tables for bidding is displayed at 2302. The user then selects a specific table at 2304. This causes relevant rules for bidding to be displayed at step 2306, and the user accepts the rules at step 2308. Once the message is accepted, two options are displayed at step 2310, namely bidding or guaranteed purchase. If bidding is selected at step 2312, inputs are displayed at 2314, the user inputs relevant bid amounts at 2318, then available occasions are loaded and displayed at 246 and an occasion is selected at step 248, and the process continues along arrow 4, which is described in Figure 20. Conversely, if guaranteed purchase is selected at step 2320, available occasions are loaded and displayed at 246 and an occasion is selected at step 248, and the process continues along arrow 4, which is described in Figure 20.
[00241] If the user bids by a specific class 2322, an analogous process is followed. A list of classes for bidding is displayed at 2324. The user then selects a specific class at 2326. This causes relevant rules for bidding to be displayed at step 2306, and the user accepts the rules at step 2308. Once the message is accepted, two options are displayed at step 2310, namely bidding or guaranteed purchase. If bidding is selected at step 2312, inputs are displayed at 2314, the user inputs relevant bid amounts at 2318, then available occasions are loaded and displayed at 246 and an occasion is selected at step 248, and the process continues along arrow 4, which is described in Figure 20. Conversely, if guaranteed purchase is selected at step 2320, available occasions are loaded and displayed at 246 and an occasion is selected at step 248, and the process continues along arrow 4, which is described in Figure 20.
[00242] Referring to Figure 2u, there is shown a continuation of the process flow of arrow F1, which is continuation of the process flow described in Figure 2d. It will be appreciated that Figures 2u, 2v and 2w are interconnected, as shown by arrows k, I and m respectively. However, for the sake of clarity, it will be appreciated that step 2332 of Figure 2u, step 2400 of Figure 2v and step 2402 of Figure 2w are interrelated.
[00243] Referring specifically to Figure 2u, at step 2332 a promotional reduced price menu is selected. Consequently, at step 268, a booking request containing all previously selected constraints is sent to the allocation system via an API link and at step 270 the allocation algorithm processes the request. If the booking request is allocated, the process continues along arrow 5, which connects to the process flow described in more detail in Figure 2q.
[00244] If the booking request cannot be allocated, at step 2192, the allocation algorithm provides alternative promotional reduced price menus at step 2340, and at 2342 a popup appears on the user interface displaying the alternative reduced price menus. At this point, the user may select from one of three options. Firstly, the user may select the alternative menu at 2344, in which case an edited booking request is sent at step 2200 and the optimisation algorithm processes the booking request at step 270. Alternatively, the user may elect to join a waitlist at step 2208. The user is prompted to enter contact details at step 2210 and enters the details. A waitlist request is sent to the allocation system at step 2214 and a waitlist booking is created at step 2216. Confirmation of the waitlist booking is sent to the customer at step 2218, at which time the promotional process ends at step 2220. As a third option, the user may elect to cancel the booking at step 2222, in which case the booking widget is closed at step 2224 and the process ends at step 2220.
[00245] Referring specifically now to Figure 2v, at step 2400 a reduced-price promotion is selected. Consequently, at step 268, a booking request containing all previously selected constraints is sent to the allocation system via an API link and at step 270 the allocation algorithm processes the request. If the booking request is allocated, the process continues along arrow 5, which connects to the process flow described in more detail in Figure 2q.
[00246] If the booking request cannot be allocated, at step 2192, the allocation algorithm provides an alternative promotional reduced-price promotion at step 2341, and at 2343 a popup appears on the user interface displaying the alternative reduced price promotions. In the example shown, three promotion types are described. There is described a promotional reduced price menu, a reduced price promotion and a backfill promotion. However, it will be understood that the embodiment could incorporate other types of promotions, and the examples described herein are to be taken as illustrative and not restrictive. At this point, the user may select from one of three options. Firstly, the user may select the alternative promotion at 2345, in which case an edited booking request is sent at step 2200 and the optimisation algorithm processes the booking request at step 270. Alternatively, the user may elect to join a waitlist at step 2208. The user is prompted to enter contact details at step 2210 and enters the details at step 2212. A waitlist request is sent to the allocation system at step 2214 and a waitlist booking is created at step 2216. Confirmation of the booking is sent to the customer at step 2218, at which time the promotional process ends at step 2220. As a third option, the user may elect to cancel the booking at step 2222, in which case the booking widget is closed at step 2224 and the process ends at step 2220.
[00247] Referring now to Figure 2w, at step 2402 a backfill promotion is selected. Consequently, at step 268, a booking request containing all previously selected constraints is sent to the allocation system via an API link and at step 270 the allocation algorithm processes the request. If the booking request is allocated, the process continues along arrow 5, which connects to the process flow described in more detail in Figure 2q.
[00248] If the booking request cannot be allocated, at step 2192, the allocation algorithm provides an alternative backfill promotion at step 2404, and at 2406 a popup appears on the user interface displaying the alternative backfill promotions. At this point, the user may select from one of three options. Firstly, the user may select the alternative backfill promotion at 2408, in which case an edited booking request is sent at step 2200 and the optimisation algorithm processes the booking request at step 270. Alternatively, the user may elect to join a waitlist at step 2208. The user is prompted to enter contact details at step 2210 and enters the details. A waitlist request is sent to the allocation system at step 2214 and a waitlist booking is created at step 2216. Confirmation of the booking is sent to the customer at step 2218, at which time the promotional process ends at step 2220. As a third option, the user may elect to cancel the booking at step 2222, in which case the booking widget is closed at step 2224 and the process ends at step 2220.
[00249] Referring to Figure 2x, there is shown a process flow which is a continuation of the process flow indicated by arrow 3, which in turn is described in Figure 2b. At this point in the process flow, the user may select availability by time at step 236, or availability by occasion at step 244. If the user selects availability by time, available time intervals are shown at step 238, the user selects a time interval at step 240, available occasions are shown at step 246 and the user selects an available occasion at step 248. Thereafter, a list of available private dining rooms is displayed at 2834, the user selects a private dining room at 2836, room configuration options are displayed at step 2838, and the user selects a room configuration at 2840. Thereafter, the process flow continues along arrow 5, which continues to the process flow described with reference to Figure 2q. Alternatively, if the user selects availability by occasion at step 244, available occasions are shown at step 246, the user selects an occasion at step 248, available times are shown at step 238 and the user selects an available time at step 240. Thereafter, a list of available private dining rooms is displayed at 2834, the user selects a private dining room at 2836, room configuration options are displayed at step 2838, and the user selects a room configuration at 2840. Thereafter, the process flow continues along arrow 5, which continues to the process flow described with reference to Figure 2q.
[00250] Referring to Figure 3a, there is shown a flowchart for a booking widget where the user identifies prior to entering the booking process. The process of identifying themselves provides the user with the ability to receive a customised widget. The widget has a combination of personal and "group" customisation. That is, in broad terms, the identity of the user not only identifies the user as an individual, but also identifies the user, potentially, as a member of one or more groups. Both individual identity and group identity may have an impact on the algorithm and the information and options provided to the customer. For example, the individual may be identified as John Smith, but John Smith may also be an American Express card holder, which identifies him as a member of a group (i.e. an American Express card holder).
[00251] Returning to Figure 3a, at step 300 a customer inputs one or more identifiers. At step 302 the booking widget retrieves customer information from a client database to retrieve information about the customer, to either identify the customer and/or determine customer preferences to thereby allow personalisation and customisation of the widget. In the context of the present specification, the term customisation refers to the "look and feel" of the widget interface, including the input fields displayed, the options displayed and the aesthetic appearance of the widget interface. Conversely, personalisation refers to the inclusion and/or removal of fields, pre-filling of fields with relevant data, the inclusion of promotions tailored to the customer, etc. In other words, while from a functional point of view, there is some overlap with regard to the terms customisation and personalisation, customisation refers primarily to the "look and feel" of the widget, while personalisation refers primarily to the information displayed on the widget.
[00252] Subsequently, at step 304, the widget is personalised based on the customer's information. As shown in more detail in steps 306, 312, 314, 316, 318 320 and 322, the interface of the widget and the options displayed to the customer can vary the appearance or functionality of the widget. At step 306, for example, the widget may offer a specific promotion. For example, if the widget is associated with a specific channel that is offering a specific promotion, the customer may be shown certain pre-populated information unique to the channel. In the alternative, at step 312 the widget may provide suggestions in the form of prepopulating certain fields. Alternatively, at step 314 the widget may "hide" (i.e. not display) certain fields or may add certain fields depending on the constraints relevant to the customer. Alternatively, as shown in steps 316, 318, 320 and 322, the widget may utilise any combination of the steps shown individually in 306, 312 and 314. That is, certain fields maybe hidden, shown, pre-populated, and/or certain promotions shown depending on the constraint information relevant to the restaurant, the channel and the identified customer. After the customised interface is provided to the customer, the customer can select the promotion or other offer at step 308, after which the customer, at step 310, is taken through the booking process generally described with reference to Figures 2a-2x.
[00253] Referring to Figure 3b, there is shown a block diagram which illustrates some of the functional connections between the booking widget or app and the customer database. Figure 3b is not intended to provide a detailed modular representation of the hardware/software modules that comprise an embodiment of the invention, but rather to provide the person skilled in the art with a high level overview of the manner in which the booking app/widget interfaces with the client database, the client database forming part of the ResButler platform (not shown in Figure 3b). It will be appreciated by the person skilled in the art that the data structures and modules implied by Figure 3b are exemplary only, and variations and obvious modifications are within the purview of a person skilled in the art.
[00254] At Figure 3b, there is shown a representation of a device 324, which may be a desktop computing system, a laptop, a tablet computing device, a smartphone, or any other electronic device capable of communicating with a server and database via a communications network (as per Figure la). The device is capable of executing and displaying a website (referred to as a booking channel within the context of the invention described herein) 326, the website including an integrated or embedded software application referred to herein as a widget 328. The widget 328 is capable of receiving (and optionally storing) a customer identifier 330 which is utilised as information that is passed to a client database 334 when customer information is requested 332.
[00255] Referring to the client database 334 there is provided a customer relationship management system (CRM) 336, which includes multiple customer records, a single example of which is shown at 338 (where the example is directed to hypothetical customer 'A'). The customer record 338 includes a customer ID 340, booking history information 342, membership information 344, customer data 346 and customer behaviour information 348. Outside of the CRM, but also within the client database 334, is, information regarding promotional offers 350 (which is linked to the CRM) and information regarding booking constraints 351.
[00256] When customer information is requested 332, CRM information is sent to the widget on the website 352 and the widget on the website is personalised 354, to include information regarding specific promotions for the customer 356, specific constraints which pre-populate fields in the widget 358, specific fields and input options which can be added or hidden 360, which combine to provide a customised and unique interface for the customer. Once the customised interface is provided, the customer can interact with the widget and complete and submit the booking request 362.
[00257] Referring to Figure 4a there is shown a flowchart for a restaurant booking editing process in accordance with an embodiment of the invention. As will be appreciated, customers may wish, from time to time, to update bookings for a variety of reasons. At step 400, a waitlisted booking becomes allocated and a notification email is sent at step 402. Alternatively, a booking confirmation email is sent at step 401. Either of these events allow a customer to click on a link in the email to access the booking widget as per step 404, where the customer can input booking reference numbers and/or login details at step 406. The original booking is subsequently put on hold for a time period at step 408, and at step 410, the restaurant widget is loaded, displaying a summary of the previously displayed details. The booking process then proceeds along arrow 1.
[00258] Referring to Figure 4b, there is shown a continuation of the process flow indicated by arrow 1 with regard to Figure 4a. At step 412, the customer edits booking detail fields and at step 414, the customer sends an availability check for the edited booking details. As shown in step 416, the edited booking details contain all previously selected and defined constraints. At step 418, the allocation/optimisation algorithm processes the updated booking request and if the booking request is successfully allocated, at step 422 the original request is cancelled and the original booking request number is transferred to the new booking and the process flow continues along arrow 2, which is described in more detail with regard to Figure 4c.
[00259] Alternatively, if the booking request cannot be allocated at step 420, the optimisation algorithm, at step 438, searches for alternative booking options and at step 440, a popup appears displaying the alternative booking options. The customer may then choose from one of four potential options, including selecting an alternative booking option 442, joining a waitlist 468, cancelling the edited booking request 435 or cancelling the original booking request 436.
[00260] If the alternative booking request option is selected 442, the alternative booking request is sent to the allocation algorithm 444, the algorithm processes the booking request 418 and the original booking request is subsequently cancelled 422 and the original booking request number is transferred to the new booking and the process flow continues along arrow 2, which is described in more detail with regard to Figure 4c.
[00261] If the join waitlist option 468 is selected, then the original booking request is cancelled at step 470, the waitlist request is sent to the allocation system 472, a waitlist booking is created 474 and an automated waitlist booking confirmation email is sent at step 476, after which the process ends at step 490. If the cancel edited booking request is selected at step 435, the original booking request is taken off hold and converts back into a confirmed booking at step 437, and the process ends at step 490.
[00262] Alternatively, if the cancel original booking option is selected at 436, the original booking request is cancelled at 470, and an automated cancelled booking email is sent to the customer at 472, after which the process ends at 490.
[00263] Referring to Figure 4c, there is shown a continuation of the process flow of arrow 2, which is a continuation of the process flow described in Figure 4b. At step 424, the customer may elect to edit their contact details, or may elect, at step 425, to not edit their contact details. Thereafter, the system determines whether the new booking request causes an increase or decrease in the original pre-payment total at step 426. If not, the process proceeds to step 428 where terms and conditions are displayed to the customer. The customer then agrees to the terms and conditions and submits their agreement. If payment is successful at step 432, a booking confirmation is displayed at step 434 and the process ends at step 490.
[00264] If payment is not successful at step 431, the process returns to step 450, which is described hereinbelow.
[00265] Returning to step 426, if an increase of decrease in pre-payment is required, the process continues to step 448 if an increased payment is required, or step 458 if a decrease is required. At step 448 (increased payment required), the process proceeds to step 450, where relevant payment options are displayed. The customer selects a payment option at 452, and relevant payment option inputs are provided for the customer to input details at step 454. At step 456 the payment details are input and submitted by the customer, at which time the process proceeds to step 428, where terms and conditions are displayed to the customer. The customer then agrees to the terms and conditions and submits their agreement. If payment is successful at step 432, a booking confirmation is displayed at step 434 and the process ends at step 490.
[00266] Returning to step 458, where there is a decrease to the original pre payment required, the process allows the customer to leave the balance as a further credit towards the booking at step 460, where the process adds the amount as credit to the customer's account at step 462. Thereafter, the process proceeds to step 428, where terms and conditions are displayed to the customer. The customer then agrees to the terms and conditions and submits their agreement after which a booking confirmation is displayed at step 434 and the process ends at step 490.
[00267] Alternatively, if the customer elects to receive a refund at 488, the customer initiates a refund request at 466, and thereafter the process proceeds to step 428, where terms and conditions are displayed to the customer. The customer then agrees to the terms and conditions and submits their agreement after which a booking confirmation is displayed at step 434 and the process ends at step 490.
[00268] Referring to Figure 5a, there is shown a flow chart for booking a show. The booking of a show is analogous to the booking of a table at a restaurant. However, in the context of the embodiment described, the booking of a show is utilised as an example of the ability, by the system, to allow a customer to book two different "events" at two different venues. For example, a customer may wish to book a show in a theatre, and also choose to book a restaurant for a meal after the show. In prior art systems, there is no facility to allow such a "double" or "synchronised" booking, as no prior art system has the ability to contemporaneously book more than one venue or event. However, the embodiment described herein provides a facility by which a first booking is put "on hold" (i.e. the booking is tentatively placed in the database for a defined period of time), so that the system can then make a second booking at a second venue, thereby allowing coordination between different events at different venues. This facility is best described with reference to the process flow generally described at Figures 5a-5e. In Figure 5a, at step 500, a show is selected. Thereafter a date is selected at step 502, a time is selected at step 504, inputs for the number of tickets are displayed at step 506, the user inputs the number of tickets at step 508, a booking request containing all selections is sent at step 510 and the booking algorithm processes the booking request at step 512, before the system continues the booking process as indicated by arrow 1.
[00269] Referring to Figure 5b, there is shown a continuation of the process flow of Figure 5a as indicated by arrow 1. At step 566, if a booking request is not allocated, the algorithm searches for an alternative time and alternative date options at step 568, and subsequently a popup appears displaying the alternatives at step 570.
[00270] The customer generally has four options, including selecting an alternative time 572, selecting an alternative date 578, electing to join a waitlist at step 580, or cancel the booking at step 592. If the customer selects an alternative time 572 or an alternative date 578, then the edited booking request is sent to the allocation algorithm at step 574, the algorithm processes the edited booking request at 576 and the show booking request is temporarily allocated at step 514 for a given number of minutes, to allow the customer to complete the booking. The customer is then provided, at step 516, the option of adding a second booking, namely a restaurant booking. If the customer wishes to add a restaurant booking, the process continues to the process flow for restaurant bookings at step 518 (namely the booking process outlined with reference to Fig 2a). Alternatively, if the customer does not want to add a restaurant booking, the process flow continues as indicated by arrow 2, and proceeds as described with reference to the process of Figure 5c.
[00271] Alternatively, if the customer elects to join a waitlist at step 580, inputs for contact details are displayed at 582, the customer inputs their details at step 584, the waitlist request is sent to the algorithm at step 586, a waitlist booking is created at step 588, and receipt of the waitlist booking is sent to the customer at step 590. The process then terminates at step 599. The customer may elect to cancel the booking at step 592, instead of joining a waitlist. If the customer decides to cancel the booking at step 592, the booking widget closes at step 594 and the process ends at step 599.
[00272] Referring to Figure 5c the booking process described with reference to Figure 5b is continued along arrow 2, where at step 520, contact detail inputs are displayed, and at step 522 a user inputs their details. Optionally at step 526 alternate contact details or inputs may be displayed. If at step 526 the alternate contact details option is selected, then at step 527 alternate contact details are displayed and alternate contact details are input and submitted at 529, after which the process continues to step 530. Alternatively, if no alternate contact details are selected at 526, the customer details are submitted at 528 and the additional booking details are displayed at 530, where the additional booking details are input by the user at 532 and the process continues along arrow 3.
[00273] Referring to Figure 5d there is shown a continuation of the process flow along arrow 3, as described with reference to Figure 5c. At step 534, the customer can select concierge service items requiring pre-payment and/or pre-ordering. Depending on user input, the user is taken along one of four paths. The user may select options only requiring pre-payment 536, requiring both pre-payment and pre-ordering 560, only requiring pre-ordering 562 or the user may not select any concierge service items 564. If the selected concierge items require some form of pre-payment (i.e. options 536 and 560), the system checks to determine whether the user has previously selected options that require payment details to be submitted at step 538 and then proceeds along arrow 4, wherein the ensuing process flow is described with reference to Figure 5e. Conversely, if the concierge service items only require pre-ordering 562 or no concierge service items are selected 564, the process flow continues to step 538 and a determination is made as to whether there is a requirement to submit payment details at step 538. If so, then the process proceeds along arrow 4, wherein the ensuing process flow is described with reference to Figure 5e. Alternatively, if no payment details need to be submitted, the process proceeds along arrow 5, wherein the ensuing process flow is described with reference to Figure 5e. In other words, the concierge service option allows the user to select optional items which enhance the dining experience but are not necessarily an ordinary part of booking a table at a restaurant. For example, the concierge service items may include flowers, entertainment, or other third-party products and/or services.
[00274] Referring to Figure 5e, there is shown a continuation of the process flow of Figure 5d, including the process flows denoted by arrow 4 and arrow 5 in Figure d. Referring firstly to arrow 4, at step 540 payment options relevant to previously selected constraints are shown. The user then selects a payment option at step 542, selected payment option inputs are displayed at step 544, and the user inputs selected payment option details at step 546. Optionally, there may be displayed an option to join a mailing list at step 548. Terms and conditions relevant to the booking request are displayed at step 550. Consequently, if payment is not processed successfully at step 552, then the process returns to step 544. If payment is processed successfully at step 554, the booking confirmation is displayed at step 556, and the process ends at step 599. Returning to arrow 5, which is a continuation of the process flow described in Figure 5d, at step 548 an option to join the mailing list is displayed and terms and conditions are displayed, and consequently a user submits their accidence to the terms and conditions at step 550. The process then displays a booking confirmation at step 556 and the process ends at step 599.
[00275] Referring to Figure 6a, there is shown a process for booking a function in accordance with an embodiment of the invention. As with Figure 2a-x, there is shown the various paths and outcomes that can result from a user's unique interaction with the booking widget. At step 600, a venue is selected by the customer. The customer then selects an area at step 602, and the algorithm loads, at step 604 and in response to the customer's selections at steps 600 and 602, a list of current available dates, which is presented on a calendar. The user, at step 606, selects up to three preferred dates. Dependent on the selection of dates by the customer, the system determines, at step 608, whether one of more of the selected dates have tentative or waitlisted bookings. If yes, then at step 609, the customer is informed of the pre-existing bookings and is further informed that only a waitlisted enquiry may be submitted for the requested dates.
[00276] Irrespective of whether the customer is provided with the warning at step 609, the process continues to step 610, where the meal period is selected for each selected date. Once a meal period is selected, the customer may then narrow their booking request by prioritising any one of a number of criteria. For example, the customer may choose to narrow by number of guests at step 612, by function occasion at step 688, by function style at step 6116 or by facility requirement at step 6130. The reason for providing this flexibility is due to the fact that, when booking a function, different customers may place different priorities on different aspects of the function. For example, some customers may only wish to invite a set number of guests and are therefore not flexible with regard to guest numbers but may be flexible with function style (e.g. they may be happy with a casual function or a more formal function). As such, the algorithm allows the customer to place their requirements into a hierarchy, so that non-negotiable criteria are met first, and negotiable criteria are met second. In this way, a customer can be given instant feedback on whether a function space will be capable of meeting their requirements.
[00277] Returning to Figure 6a, if the principal criteria is number of guests at 612, the customer enters the number of guests at step 614, before the process continues along arrow 1, which is described in more detail in Figure 6b. Analogously, if the principal criteria is occasion as per step 688, the customer selects the occasion from a list of occasion types at step 690, before the process continues along arrow 2, which is described in more detail in Figure 6c. Analogously, if the principal criteria is function styles as per step 6116, the customer selects the function style from a list of function style types at step 6118, before the process continues along arrow 3, which is described in more detail in Figure 6d. Analogously, if the principal criteria is facility requirements as per step 6130, the customer selects one or multiple facility requirements from a list of facility requirement types at step 6132, before the process continues along arrow 4 which is described in more detail in Figure 6e.
[00278] Referring to Figure 6b, there is shown a process for booking a function which follows from arrow 1 of Figure 6a. As the customer has selected the number of guests as the primary booking constraint at step 614 of Figure 6a, the next selection of a booking constraint must be one of the three remaining options, namely by occasion at step 616, by facility requirements at step 674 or by function style at step 682. If the customer selects by occasion at step 616, the selected occasion type is applied as a constraint at step 618, and the customer must then select the next constraint, which is now limited to style at step 620 and facility requirements at step 672. If the customer selects function style at step 620, the function style constraint is selected and the selected style is applied as a constraint at step 622, and the customer is then taken to the last of the four options, namely facility requirements at step 624, at which the customer selects one or multiple facility requirements and the process continues along the arrow 1A, which is described in more detail in Figure 6f. Alternatively, if the customer selects facility requirement at step 672, the facility requirement is selected and the selected requirement is applied as a constraint at step 624, and the customer is then taken to the last of the four constraints, namely function style at step 622, at which the customer selects a function style and the process continues along the arrow 1A, which is described in more detail in Figure 6f.
[00279] Returning to Figure 6b, if the customer selects the facility requirements field at step 674, the selected facility requirement or requirements are applied as a constraint at step 624, and the customer must then select the next constraint, which is now limited to function style at 676 and occasion at step 680. If the customer selects function style at step 676, the function style is selected and the selected style is applied as a constraint at step 622, and the customer is then taken to the last of the four constraints, namely occasion at step 618, at which the customer selects a function occasion type and the process continues along the arrow 1A, which is described in more detail in Figure 6f. Alternatively, if the customer selects occasion at step 680, the function occasion type is selected and the selected requirement or requirements are applied as a constraint at step 618, and the customer is then taken to the last of the four constraints, namely function style at step 622, at which the customer selects a function style and the process continues along the arrow 1A, which is described in more detail in Figure 6f.
[00280] Returning once more to Figure 6b, if the customer selects function style at step 682, the selected function style is applied as a constraint at step 622, and the customer must then select the next constraint, which is now limited to function occasion at 684 and facility requirements at step 686. If the customer selects function occasion at step 684, the function occasion is selected and the selected occasion is applied as a constraint at step 618, and the customer is then taken to the last of the four options, namely facility requirements at step 624, at which the customer selects one or multiple facility requirements and the process continues along the arrow 1A, which is described in more detail in Figure 6f. Alternatively, if the customer selects facility requirement at step 686, one or multiple facility requirements are selected and the selected requirement or requirements are applied as a constraint at step 624, and the customer is then taken to the last of the four constraints, namely function occasion at step 618, at which the customer selects a function occasion and the process continues along the arrow 1A, which is described in more detail in Figure 6f.
[00281] Referring to Figure 6c, there is shown a process for booking a function which follows from arrow 2 of Figure 6a. As the customer has selected the function occasion as the primary booking constraint at step 690 of Figure 6a, the next selection of a booking constraint must be one of the three remaining options, namely by number of guests at step 6100, by facility requirements at step 6104 or by function style at step 6110. If the customer selects by number of guests at step 6100, the selected number of guests is applied as a constraint at step 614, and the customer must then select the next constraint, which is now limited to function style at step 620 and facility requirements at step 672. If the customer selects function style at step 620, the function style constraint is selected and the selected style is applied as a constraint at step 622, and the customer is then taken to the last of the four options, namely facility requirements at step 624, at which the customer selects one or multiple facility requirements and the process continues along the arrow 2A, which is described in more detail in Figure 6f. Alternatively, if the customer selects facility requirement at step 672, one or multiple facility requirements are selected and the selected requirement is applied as a constraint at step 624, and the customer is then taken to the last of the four constraints, namely function style at step 624, at which the customer selects a function style and the process continues along the arrow 2A, which is described in more detail in Figure 6f.
[00282] Returning to Figure 6c, if the customer selects the facility requirement at step 6104, the selected facility requirement or requirements are applied as a constraint at step 624, and the customer must then select the next constraint, which is now limited to function style at 6106 and number of guests at step 6108. If the customer selects function style at step 6106, the function style is selected and the selected style is applied as a constraint at step 622, and the customer is then taken to the last of the four constraints, namely number of guests at step 614, at which the customer selects a number of guests and the process continues along the arrow 2A, which is described in more detail in Figure 6f. Alternatively, if the customer selects number of guests at step 6108, the number of guests is selected and the selected number of guests is applied as a constraint at step 614, and the customer is then taken to the last of the four constraints, namely function style at step 622, at which the customer selects a function style and the process continues along the arrow 2A, which is described in more detail in Figure 6f.
[00283] Returning once more to Figure 6c, if the customer selects function style at step 6110, the selected function style is applied as a constraint at step 622, and the customer must then select the next constraint, which is now limited to number of guests at 6112 and facility requirements at step 6114. If the customer selects number of guests at step 6112, the number of guests is selected and applied as a constraint at step 614, and the customer is then taken to the last of the four options, namely facility requirements at step 624, at which the customer selects one or multiple facility requirements and the process continues along the arrow 2A, which is described in more detail in Figure 6f. Alternatively, if the customer selects facility requirement at step 6114, the facility requirement is selected and the selected requirement or requirements are applied as a constraint at step 624, and the customer is then taken to the last of the four constraints, namely number of guests at step 614, at which the customer selects a function style and the process continues along the arrow 2A, which is described in more detail in Figure 6f.
[00284] Referring to Figure 6d there is shown a process for booking a function which follows from arrow 3 of Figure 6a. As the customer has selected the function style as the primary booking constraint at step 6116 of Figure 6a, the next selection of a booking constraint must be one of the three remaining options, namely by number of guests at step 6120, by facility requirements at step 6122 or by function occasion at step 6128. If the customer selects by number of guests at step 6120, the number of guests is applied as a constraint at step 614, and the customer must then select the next constraint, which is now limited to occasion at step 684 and facility requirements at step 686. If the customer selects function occasion at step 684, the occasion constraint is selected and the selected occasion is applied as a constraint at step 618, and the customer is then taken to the last of the four options, namely facility requirements at step 624, at which the customer selects one or multiple facility requirements and the process continues along the arrow 3A, which is described in more detail in Figure 6f. Alternatively, if the customer selects facility requirement at step 686, the one or more facility requirements are selected and the selected requirement or requirements are applied as a constraint at step 624, and the customer is then taken to the last of the four constraints, namely function occasion at step 618, at which the customer selects a function occasion and the process continues along the arrow 3A, which is described in more detail in Figure 6f.
[00285] Returning to Figure 6d, if the customer selects the facility requirement at step 6122, the selected facility requirement or requirements are applied as a constraint at step 624, and the customer must then select the next constraint, which is now limited to function occasion at 6124 and number of guests at step 6126. If the customer selects function occasion at step 6124, the function occasion is selected and the selected occasion is applied as a constraint at step 618, and the customer is then taken to the last of the four constraints, namely number of guests at step 614, at which the customer selects a number of guests and the process continues along the arrow 3A, which is described in more detail in Figure 6f. Alternatively, if the customer selects number of guests at step 6126, the number of guests is selected and the number of guests is applied as a constraint at step 614, and the customer is then taken to the last of the four constraints, namely function occasion at step 618, at which the customer selects a function occasion and the process continues along the arrow 3A, which is described in more detail in Figure 6f.
[00286] Returning once more to Figure 6d, if the customer selects function occasion at step 6128, the selected function occasion is applied as a constraint at step 618, and the customer must then select the next constraint, which is now limited to number of guests at 6112 and facility requirements at step 6114. If the customer selects number of guests at step 6112, the number of guests is selected and applied as a constraint at step 614, and the customer is then taken to the last of the four options, namely facility requirements at step 624, at which the customer selects one or multiple facility requirements and the process continues along the arrow 3A, which is described in more detail in Figure 6f. Alternatively, if the customer selects facility requirement at step 6114, the facility requirement or requirements are selected and applied as a constraint at step 624, and the customer is then taken to the last of the four constraints, namely number of guests at step 614, at which the customer the number of guests and the process continues along the arrow 3A, which is described in more detail in Figure 6f.
[00287] Referring to Figure 6e there is shown a process for booking a function which follows from arrow 4 of Figure 6a. As the customer has selected the facility requirements as the primary booking constraint at step 6132 of Figure 6a, the next selection of a booking constraint must be one of the three remaining options, namely by number of guests at step 6134, by function style at step 6135 or by function occasion at step 6142. If the customer selects by number of guests at step 6134, the number of guests is applied as a constraint at step 614, and the customer must then select the next constraint, which is now limited to occasion at step 6136 and function style at step 6138. If the customer selects function occasion at step 6136, the function occasion constraint is selected and the selected occasion is applied as a constraint at step 618, and the customer is then taken to the last of the four options, namely function style at step 622, at which the customer selects a style and the process continues along the arrow 4A, which is described in more detail in Figure 6f. Alternatively, if the customer selects function style at step 6138, the style is selected and the selected style is applied as a constraint at step 622, and the customer is then taken to the last of the four constraints, namely function occasion at step 618, at which the customer selects a function occasion and the process continues along the arrow 4A, which is described in more detail in Figure 6f.
[00288] Returning to Figure 6e, if the customer selects the function style at step 6135 the selected style is applied as a constraint at step 622, and the customer must then select the next constraint, which is now limited to function occasion at 622 and number of guests at step 6140. If the customer selects function occasion at step 622, the function occasion is selected and the selected occasion is applied as a constraint at step 618, and the customer is then taken to the last of the four constraints, namely number of guests at step 614, at which the customer selects a number of guests and the process continues along the arrow 4A, which is described in more detail in Figure 6f. Alternatively, if the customer selects number of guests at step 6140, the number of guests is selected and is applied as a constraint at step 614, and the customer is then taken to the last of the four constraints, namely function occasion at step 618, at which the customer selects a function occasion and the process continues along the arrow 4A, which is described in more detail in Figure 6f.
[00289] Returning once more to Figure 6e, if the customer selects function occasion at step 6142, the selected function occasion is applied as a constraint at step 618, and the customer must then select the next constraint, which is now limited to number of guests at 6144 and function style at step 6146. If the customer selects number of guests at step 6144, the number of guests is applied as a constraint at step 614, and the customer is then taken to the last of the four options, namely function style at step 622, at which the customer selects a function style and the process continues along the arrow 4A, which is described in more detail in Figure 6f. Alternatively, if the customer selects function style at step 6146, the style is selected and applied as a constraint at step 618, and the customer is then taken to the last of the four constraints, namely number of guests at step 614, at which the customer selects a number of guests and the process continues along the arrow 4A, which is described in more detail in Figure 6f.
[00290] Referring to Figure 6f, which is a continuation of the process from arrows 1A, 2A, 3A and 4A, from Figures 6b, 6c, 6d and 6e respectively, there is shown a continuation of the process flow, from the perspective of the information delivered to and from the allocation algorithm. At step 628, all floor plan templates, as constrained by the previous inputs (and as determined by the allocation algorithm), are loaded and displayed. At step 630 a floor plan is selected and the selected floor plan is loaded and displayed at step 632, and at step 634, the customer may optionally edit the floor plan. As can be seen generally by step 636, additional booking detail inputs are also included, and may include food menu fields 638, beverage menu field 640, theming fields 642, audio visual hire fields 646, entertainment field 648, staffing fields 650, guest list fields 652 and other supplier fields 654. These fields interact with a live pricing comparison display 656, which include multiple selected date and meal period combination pricing lists 658, 660 and 662 (which are shown by way of example, as it will be understood that there may be less or more than three options).
[00291] The comparison fields 656, upon display to the customer, allow the customer to select preferred combinations. Upon selecting a preferred combination at 664, the customer submits an updated availability check at 666 and the request is sent to the algorithm 668, at which point the process continues along arrow 11, which is described with reference to the flowchart in Figure 6g.
[00292] Referring to Figure 6g and in particular to arrow 11, there is shown a continuation of the process described with reference to Figure 6f (and correspondingly with previous Figures 6a-e). The outcome of step 668 of Figure 6f is one of three possibilities. Firstly, at step 670, the updated availability check may result in the discovery that an existing booking exists for the date and period selected by the customer. If so, the customer is advised to select an alternative date, and the process returns along arrow 10 to step 664 of Figure 6f, where the customer is required to select another date.
[00293] Alternatively, at step 6172, the updated availability check may result in the discovery that a tentative booking exists for the date and period selected by the customer. If so, the customer may select an alternative date, and the process returns along arrow 10 to step 664 of Figure 6f, where the customer is required to select another date, or the customer may select to be placed on a waitlist at step 6148, and the process continues along arrow 5 to Figure 6h.
[00294] Alternatively, the updated availability check may result in the discovery that a booking may be made for the date and period selected by the customer 6182. If so, the customer may decide to place an enquiry at step 6174, in which case the process continues along arrow 6 to Figure 6h, or alternatively may opt to create a tentative booking at step 6184, in which case the process continues to step 6186, where the customer submits a tentative booking request, the booking is placed on hold at step 6188 and the a timer starts, the timer being indicative of the amount of time allowed for the customer to finalise the booking, or risk the date being "released" for use by other customers. The process then continues along arrow 7, as described with reference to Figure 6h.
[00295] In the situation where a date is available, it is still possible for the customer to decide not to book the available date and return to the process by selecting an alternative date, and the process returns along arrow 10 to step 664 of Figure 6f, where the customer is required to select another date.
[00296] Referring to Figure 6h, there is shown a continuation of the process flows indicated by arrows 5, 6 and 7 of the processes described with reference to Figure 6g. At arrow 5, at step 6150, the user is asked to input function details, including first name 6152, last name 6154, email 6156, mobile number 6158, company name 6160 and alternate contact details 6162. The details are then submitted to a waitlist function at step 6164, and at step 6166 a waitlist enquiry is created in the ResButler system, where the customer receives an automated email confirmation at step 6168. The process then ends at step 699.
[00297] At arrow 6, at step 6150, the user is asked to input function details, including first name 6152, last name 6154, email 6156, mobile number 6158, company name 6160 and alternate contact details 6162. The details are then submitted as an enquiry at step 6176, and at step 6178 an enquiry is created in the ResButler system, where the customer receives an automated email confirmation at step 6180. The process then ends at step 699.
[00298] At arrow 7, at step 6150, the user is asked to input function details, including first name 6152, last name 6154, email 6156, mobile number 6158, company name 6160 and alternate contact details 6162. The process then continues along arrow 9, as described with reference to Figure 6i.
[00299] Referring to Figure 6i, there is shown a continuation of the process flows indicated by arrow 9 of the processes described with reference to Figure 6h. At step 6202 the customer commits to fulfil payment requirements, at which time at step 6204, the tentative function is taken off hold and an automated email is sent to the customer at 6206. If payment requirements are not met at 6208, the system continues to step 6207 and the tentative function is cancelled, and the process ends at step 699. Alternatively, if payment requirements are satisfied at step 6208, the existing restaurant bookings for the date of service are unallocated and affected customers are notified by email, then an automated confirmation booking email is sent to the function customer at step 6214. If full payment is made within a defined time as required at step 6216, the process ends at step 699. Alternatively, if full payment is not received, then the booking is cancelled at step 6218 and the process ends at step 699.
[00300] Referring to Figures 7a-d, there is shown generally a flowchart for a function booking process where an existing function booking is edited by a customer. Referring firstly to Figure 7a, there is one of five circumstances which give rise to the requirement to edit the details of a function booking and which provide an "entry point" (via a link embedded in an email) into the booking system. At 700, a tentative function may be cancelled, at which time waitlisted functions will receive an email at step 702 to inform those on the waitlist that their requested date is potentially available. Alternatively, at 716 there may be an entry via a waitlisted function enquiry email 716, a function enquiry confirmation email 734, a tentative function booking confirmation email 746, or a confirmed function booking email 776. Irrespective of the initial entry point, at 704, a customer clicks a link in the received email to access the booking widget, the customer subsequently identifies themselves by inputting login details and/or a reference number (or is automatically identified by information embedded in the link). This causes, at step 708, the function booking widget to be loaded and the process continues along arrow 1, where the process steps followed are described in Figure 7b.
[00301] Referring to Figure 7b, there is shown a continuation of the process flow of arrow 1 (described in Figure 7a), where upon the customer accessing the widget (as per step 708 in Figure 7a) the user may either edit booking details at 710 or decide not to edit booking details at 718. In either case the process continues to step 720, where the user submits an availability check (which may or may not be edited) and at step 722 the request is sent to the ResButler system. The ResButler system may return with one of three results.
[00302] At step 724, the system may inform the customer that another booking has already been made (i.e. the customer has lost the ability to book the function on the desired date). If this information is provided to the customer, the customer may cancel the request at step 712, in which case the process ends at 799, or the user may return to step 710 and edit their booking request details and proceed through the booking process again.
[00303] At step 725, the updated availability check may inform the customer that a tentative booking has been received before the customer finalised their booking (i.e. the customer, cannot, at this time, book the function on the desired date, but may be able to book at some time in the future). In this circumstance, the customer may opt to be placed on a waitlist at step 724, in which case the process flow continues along arrow 2, the remaining process flow being described at Figure 7c. Of course, as with the previous option, the customer may also cancel the request at step 712, in which case the process ends at 799, or the user may return to step 710 and edit their booking request details and proceed through the booking process again.
[00304] As a third potential result, the system may, at step 736, inform the customer that the desired booking date is available. The customer may choose to create an enquiry at step 738, in which case the process continues as indicated by arrow 3, the remaining process flow being described with reference to Figure 7c.
[00305] Alternatively, if the customer opts to make a tentative booking at step 748, the customer submits a tentative booking request at step 750, at step 754 an on-hold tentative booking is created, and at step 756 a timer is started to provide the customer with a limited time to finalise the booking or risk losing the booking.
[00306] Referring to Figure 7c, there is shown a continuation of the flows of arrows 2, 3 and 4, as described with reference to Figure 7b.
[00307] Following from arrow 2, the customer may decide to edit contact details at step 726 or may decide not to edit contact details at 727, before proceeding to step 728, where the customer submits the waitlisted function. At step 730 a waitlisted function is created in the ResButler system, and at step 732 the customer receives an email before the process ends at step 799. Similarly, following on from arrow 3, the customer may decide to edit contact details at step 726, or may decide not to edit contact details at 727, before proceeding to step 740, where the customer submits the function enquiry. At step 742 a function enquiry is created in the ResButler system, and at step 744 the customer receives an email before the process ends at step 799. Similarly, following on from arrow 4, the customer may decide to edit contact details at step 726, or may decide not to edit contact details at 727, before proceeding along arrow 5, which is described in Figure 7d.
[00308] Referring to Figure 7d, there is shown a continuation of the process flow from arrow 5 of Figure 7c, where at step 758, the user commits to fulfil payment requirements, and a tentative booking is taken at step 760. Followed by an automated email being sent to the customer at step 762, and a determination is made as to whether payment requirements have been met at step 764. If not, the tentative booking is cancelled at step 765 and the process ends at step 799. If the payment requirements are met, the existing restaurant bookings are unallocated at 766, the tentative booking becomes a confirmed booking at step 768, and an automated email is sent at step 770. If full payment is subsequently made at step 772, the process ends at step 799. Otherwise, the booking is cancelled at step 774 and the process ends at 799.
[00309] Referring to Figure 8a there is shown a screenshot 850 of a configurator in accordance with an embodiment of the invention. As described, the configurator allows multiple "channels" (i.e. different instances of the widget which behave differently and may be deployed to different websites, apps, etc.) to be individually controlled, wherein all features, inputs, outputs and aspects of the interface may be potentially turned off or on depending on the requirements of the restaurant.
[00310] The interface 850 includes a title 802, a restaurant selector 804, booking widget configuration set selection facility 806 (which allows an operator to create multiple booking widget configuration sets that can be posted by specific service and date range combinations by day of the week), a series of selectable switches as shown at 810 generally (or 810a, b, c and d specifically), wherein each category as denoted by 808 includes sub-categories as denoted by 812 and 814. For each channel, there is also provided toggle switches 801a, 801b, 801c and 801d respectively. The interface also allows each element in each sub-category to be moved using arrows 816 or an entire category to be moved using arrows 818.
[00311] Referring to Figure 8b through to 80, there are shown screenshots 820 through to 846, each displaying examples of sub-categories, such as booking details, enhancements, contact details, etc. It will be appreciated that potentially any sub-categories may be included, as per the figures shown.
[00312] Referring specifically to Figure 8c, a specific option is shown with regard to screenshot 822 and more specifically to option group 883, namely the ability for the client/customer/booking requestor to select a specific table. At 885 through to 899, there are shown various options which may be turned on and off by the operator, which in turn affect the manner in which the client/customer/booking requestor may select tables. At 885, there is provided an option to allow the requestor to select a specific table. By default, this option provides the requestor with the ability to select what would colloquially be termed "free" tables (i.e. tables that have no additional cost associated with the booking of the table). In the example shown, the algorithm has been set up to provide booking requestors with the ability to select any table that matches their constraints. To provide a simple example, a booking requestor who wishes to book a table for four people is shown all available tables that sit four people and/or all tables where the operator will accept four people. However, it will be understood that these options are provided as an example of the options available to the operator. In other embodiments, the system and method may implement different options. The purpose of this option is to provide the operator with flexibility to meet customer expectations while optimising yield.
[00313] If the operator wishes to limit the ability of the requestorto select tables to a sub-category of tables from the total number of tables that are potentially selectable, the operator can turn on various sub-options, such as allowing the requestor to only select within a particular class at 887. Moreover, to provide the requestor with a better visual representation of the restaurant layout, the operator may select the ability for the requestor to view a floor plan using toggle 889, including the sub-options to display classes and chair positions at 891 and 893 respectively.
[00314] In addition, the operator may toggle on or off the showing of tables for sale by using toggle 895, including the showing of tables by class by using toggle 897, and the showing of tables with a pax range requirement greater than the booking pax using toggle 899. In other words, the operator can create a number of different permutations of what is available and/or displayed to the requestor, depending on what the operator wishes to achieve.
[00315] For example, in some venues, the operator may wish to allow the requestor to purchase any available table, whereas in other venues, the operator may wish to restrict the requestor to tables that match the number of guests associated with the booking request (e.g. a booking request for 4 people can only select tables that seat four people).
[00316] Referring to Figure 9a, there is shown an example of a scheduler that works in conjunction with the widget configurator. In addition to turn features on and off, the embodiment described herein contains a scheduler which allows the operator to turn features on and off at particular times and days. The screenshot 900 shows the scheduler including a title 902, a restaurant selector 804, and a series of configurations, where a new configuration can be chosen by selecting button 904, and priorities can be changed using arrows 816, or individual scheduled channels can be edited using button 906 or previewed using button 908.
[00317] Referring to Figure 9b there is shown a screenshot 910 of an example scheduled instance of the widget, including a restaurant selector 804, a title 912 which denotes and identifies the instance, a create/edit tab 914, a configurator tab 916 and a scheduler tab 918. The instance can be saved by clicking the save button 848. The operator uses this tab to create and define the channel/instance of the widget.
[00318] Referring to Figure 9c there is shown an example of the configurator tab including a restaurant selector 804, a title 912 which denotes and identifies the instance, a create/edit tab 914, a configurator tab 916, a scheduler tab 918 and a category label 919 for a widget category. There is also shown that each element in each sub-category can be moved using arrows 816 or an entire category to be moved using arrows 818. The operator uses this tab to select the options desired for the channel.
[00319] Referring to Figure 9d there is shown an example of the scheduler tab including a restaurant selector 804, a title 912 which denotes and identifies the instance, a create/edit tab 914, a configurator tab 916 and a scheduler tab 918. There is also shown a meal period selector 920, a calendar date selector 922, a days of the week selector 924 and a save button 848. This tab is utilised to select the schedule during which the configured options will be "live".
[00320] Referring to Figure 10a there is shown a screenshot 1000 of an example of a function booking widget configuration screen analogous to the screens shown in Figures 8a-o. As with the configuration screens of Figure 8a-o, there is provided a restaurant selector 804, the functionality of the page is identified by a descriptor or title 1002, and different configurations can be selected via drop down box 1004. Each channel is represented in a grouping of columns (generally 810, or specifically 810e, 810f, 810g and 810h) of on/off switches corresponding to options, information and other variables and constraints which can be toggled on or off. Toggles can be grouped into categories generally denoted by 808, and sub categories, generally denoted by 812 and 814. Within subcategories, the relative priority of each toggle can be moved using arrows 816 and the entire sub-category can be moved using arrow 818.
[00321] Referring to Figures 10b through to 10n, there is shown, respectively, at screenshots 1012 through to 1036, various sub-categories for booking details, service periods, floor plans, etc. Figures 10b-n illustrate the plethora of options available to customise each channel. Given the vast array of options available, there a functionally infinite number of channels that are capable of being generated, allowing the operator to create customised widgets and/or apps for limitless uses and circumstances. In other words, a non-programmer is capable of customising and deploying an extremely large number of apps and widgets, each through a different channel, and each which entirely unique requirements, features, constraints and "look and feel".
[00322] Referring to Figure 11a there is shown a screenshot 1100 of an interface of a function booking widget configuration and scheduler in accordance with an embodiment of the invention. The interface includes a functional title 1102 indicating the purpose of the interface, and a restaurant selector 804. The interface 1100 also includes a new functions configuration button 1104, which allows an operator to set up a new instance of a widget or app, based on a defined time and date. There is also provided a prioritising function 816, where different events in the scheduler can be prioritised over other events, to allow the algorithm to determine which event to select in the case of conflicting requirements and overlapping time/date periods. Each configuration can also be enabled or disabled, as indicated by 905, and can be edited and previewed as shown by 906 and 908.
[00323] Referring to Figure 11b, there is shown a screenshot 1106 of an interface which allows a user to edit, create, configure and schedule a channel of a widget or app. The interface includes a descriptive title 1108 that identifies the configuration, a restaurant selector 804 which allows the operator to select a restaurant and three tabs, an edit/create tab 914 (selected in the screenshot of Figure 11b), which allows the user to define the name of the configuration and provide a free form description, a configurator tab 916 and a scheduler tab 918. There is also provided a save button 848 to allow the user to save the configuration.
[00324] Referring to Figure 11c, there is shown a screenshot 1106 depicting the function booking widget configuration and scheduler of Figure 11b in accordance with an embodiment of the invention with the configurator tab selected. As per Figure 11b, the interface includes a descriptive title 1108 that identifies the configuration, a restaurant selector 804 which allows the operator to select a restaurant and three tabs, an edit/create tab 914, which allows the user to define the name of the configuration and provide a free form description, a configurator tab 916 and a scheduler tab 918. In Figure 11c, the configurator tab 918 is selected, displaying a series of channels shown at 810 for a widget category denoted by 808 and sub-categories denoted by 812 and 814. Each category includes a series of on/off toggles for each channel into which an instance of the app or widget is deployed, with the subcategories being capable of being prioritised using arrows 816, and sub-categories being moved to different locations in the interface through use of arrows 818.
[00325] Referring to Figure 11d, there is shown a screenshot 1106 depicting the function booking widget configuration and scheduler of Figure 11b in accordance with an embodiment of the invention with the scheduler tab 918 selected. The interface includes a descriptive title 1108 that identifies the configuration, a restaurant selector 804 which allows the operator to select a restaurant and three tabs, an edit/create tab 914 and a configurator tab 916. There is also provided a save button 848 to allow the user to save the channel. There is also provided a meal period selector 920, a calendar 922 for selection of a series of dates and a selector for days of the week 924, allowing the operator to select the application of the configuration options during selected days of the week.
[00326] Referring to Figures 12a-12o, there are shown diagrams that illustrates functionally the interconnections between various software modules, devices and data files that comprise the widget or app in accordance with an embodiment of the invention, with particular emphasis on the embodiment where channels are "posted" to a calendar. Figures 12a-12o provide the skilled addressee with an understanding of the hardware, software and data components that comprise an embodiment of the invention, to further aid in the understanding of the operation of the invention. However, it will be appreciated that the components described with respect to Figures 12a to 120 are representative of one embodiment, and obvious variations are within the purview of a person skilled in the art (one variation being described with reference to Figures 13a-i described hereinbelow).
[00327] Referring firstly to Figure 12a, there is shown a ResButler project module 12276 representing the "booking engine" described in more detail elsewhere in the present specification. It will be understood that while the embodiment described is directed to a system for booking at a restaurant, the inventive concept has broader application than the embodiments described herein. Moreover, it will be understood that, for the purpose of clarity, reference is made to an example restaurant, restaurant 'A'.
[00328] The ResButler project module 12276 is in functional connection with a Point of Sale module 12278, which in turn may reside on a device arranged to display an interface 12282. Point of Sale module 12278 is connected to other components, as indicated by arrow Y, which is described in Figure 12d. Similarly, ResButler project module 12276 is connected to other components, as indicated by arrow Z, which is described in Figure 12d.
[00329] In turn the device is in communication with Restaurant A point of sale (12286) (and it will be understood that there may be other third party restaurant point of sale databases such as 12320) which in turn is in communication with a ResButler menu and display setup file 12302 and a concierge service setup 12312, each of which are in communication with further components as connected to arrow A (which is described in more detail in Figure 12b).
[00330] The module 12276 is also in communication with a device, such as a desktop computer, a tablet computing system or a smartphone. The device is capable of rendering an interface 1202, the interactive and information elements of the interface being selected, based in part, on the utilisation of CRM data in the form of a CRM setup file or data (in the case where the data is not in a file per se but is embedded in a relational database or similar). The CRM setup file 1208 includes customer setup input data 1206 and membership, benefits, offers and preferences data 1208, which is derived from a source described in more detail with reference to Figure 12d (see arrow D, which is connected to Figure 12d). In turn, CRM setup 1204 interacts with a booking constraints setup file 1238, which includes information for multiple restaurants such as restaurant B (1239) and restaurant A (1240). Referring specifically to restaurant A (1240) as an example of the information provided within a restaurant booking constraints file, there is provided at 1242 a plurality of interrelated and nested booking constraints, a promotions setup file 1244 which includes promotions information such as promotion A (1246) tables for sale file 1260 and tables for auction file 1268.
[00331] The booking constraints setup 1238 also interacts with a calendar 1276, which includes information for multiple restaurants such as restaurant A 1278 and restaurant B 1277, and in each restaurant file there is includes a service or date range 1280 which includes a plurality of interrelated nested booking constraints 1282, details of promotions 1284, details of tables for sale 1286 and details of tables for auction 1288.
[00332] Referring to Figure 12b, there is shown a continuation of arrow A from Figure 12a (and continues along arrow B to Figure 12c), wherein a device is capable of hosting a widget for a website, app or analogous software application (computer program arranged to be executable on the device), wherein execution of the widget, app or software application causes the ResButler interface 1202 to be displayed on the device (display not shown). For the interface 12328 to function correctly, the interface must be capable of accessing and utilising a restaurant registration and widget/code snippet setup file 12330, which includes multiple booking widget strategiser files (12331 and 12332) for each restaurant, wherein each strategiser file includes the interface to control the one or multiple widget facility 12334. The widget/code snippet setup file is in communication with a posting option, wherein one or multiple widgets can be posted to a calendar, which in turn is in communication along arrow C, which is described in more detail with reference to Figure 12c. The widget/code snippet setup file is in communication with a configurable constraint data set (see along arrow D to Figure 12d).
[00333] Referring to Figure 12c there is shown a continuation of arrows B and C from Figure 12b. There is provided a ResButler interface 1202, booking widget configurator 12106 which includes multiple restaurant constraint data files such as 12107 and 12109, which in turn contain configurable booking constraint data sets 12108, 12110, 12112 and 12114. The booking widget configurator is operatively connected to a posting module 12116 arranged to post one or multiple widget configurations to a calendar and also operatively coupled via arrow G to other modules, components and data files, as is described in more detail in Figure 12d. Returning to posting module 12116, the posting module includes restaurant data files 12118 which include service or date range files 12120 which include configurable booking constraint data sets such as 12124, 12130, 12136 and 12142. Data is provided to posting module 12116 via setup screens and/or files such as booking widget themes setup 12334 and alternate functionality structures setup 12330.
[00334] Returning to posting module 12116, the module 12116 interacts which a validation engine 12148 to determine which constraints are indicated as "ON" before such dates are posted to the calendar, before the process interacts with further modules, components and data files in Figure 12d.
[00335] Referring to Figure 12d, there is shown a continuation of the components, modules and data files shown in Figures 12a-12o generally. Referring specifically ResButler booking database 12274, which is connected to arrows Z and Y, which in turn are connected to ResButler project module 12276 and Point of Sale module 12278 respectively, there is provided a series of customer behaviour records 1226. Moreover, ResButler Booking Database 12274 is connected via arrow I to further components, modules and files as described in more detail in Figure 12e. Customer behaviour records 1226 are also connected via arrow M to further components, modules and files as described in Figure 12e.
[00336] Correspondingly there is provided a client booking database 12275, which includes the customer behaviour records 1226 which are in turn connected to a configurable Customer Relationship Management module 1212, which includes customer records 1213 including specific customer record for customer A 1214. There is also provided an overarching set of files per restaurant such as the files 1227 including a specific file for Restaurant A 1228, which includes booking constraint calendar 1292, including multiple service or date ranges 1293 and 1294. File 1228 also includes a configurable booking constraint data set 1295 and 12194, and also includes widget configuration calendar 12152, which includes multiple service or date ranges 12153 and 12154.
[00337] Customer behaviour records 1226 are also connected to booking constraint calendar 1292, configurable booking constraint data set 1295 and widget configuration calendar 12152.
[00338] Referring to arrow D which is connected to Figure 12a, at step 1210 customer data and ID are saved to the configurable CRM (1212) within the client database 12275. Similarly, referring to arrow E which is also connected to Figure 12a, at step 1290 booking constraints are saved to client booking constraints calendar 1292.
[00339] Turning to arrow F, which is connected to Figure 12b, at step 12326 configurable booking constraint data sets are saved to the configurable booking constraint data set 1295. Referring to arrow G, which is connected to Figure 12c, at step 12104 configurable booking constraint data set IDs populate a number of configurable booking constraint data. Constraint booking data set 1295 is in turn connected to other components, modules and files via arrow J, which is described in more detail in Figure 12e.
[00340] Lastly, turning to arrow H, which is connected to Figure 12c, at step 12150 the widget configuration is saved to the client database into the multiple widget configuration calendar 12152.
[00341] Referring to Figure 12e, there is shown a continuation of arrow I from Figure 12d, where at step 12168, an html code snippet for a configurable booking constraint data set is embedded on website 12172 which is hosted on a device.
[00342] Similarly, there is a continuation of arrow J, which is connected to a server 12164 that includes an instance of the online booking widget 12166 which can then be deployed as code snippets 12168, 12190 and 12212 to websites 12172, website 12194 and website 12216. Websites 12171, 12194 and 12216 are also capable of interacting with other components of the ResButler system as shown by arrows L and M which are described in Figure 12f and 12d respectively.
[00343] Referring to Figure 12f there is shown a continuation of arrow K from Fig 12e, where at step 12232 and 12258 code snippets for data set 3 and 4 respectively are loaded on website D (12234) and website E (12260) respectively, by using ID 3 (12236) and ID set 4 (12262). Utilising iFrame technology 12238, the widget is then displayed as an app, on a kiosk, or an app on a mobile device. There is also shown an API link 12256 which is capable of interfacing directly with a device. Devices are also capable of interfacing directly with other components as shown by arrow L, which is connected to components, modules and files represented in Figure 12e.
[00344] Referring to Figure 12g there is shown a representation of specific data files for specific constraint types with examples of the constraints contained within each file and their use. In particular, Figure 12g describes the ResButler POS interface 12282 which includes a POS product group and products setup file 12284.
[00345] There is also shown a Restaurant POS database 12286 which represents the database of a single restaurant'A'. The database includes multiple product groups 12287 and 12288, wherein each product group contains multiple product files 12289 and 12290. In turn, each product file contains multiple fields which identify various characteristics of the product, such a product number 12292, product details 12294, allergy information 12296, ingredients and recipes that make up the product 12298 and pricing 12300. Similarly, other POS databases may exist such as 12320, which also include products 12290 and 12321, each of which may also have identifying information, such as product information 12292.
[00346] There is also provided ResButler Menu and Display setup files 12302, which include menu item setup data 12304, product number 12306, menu formatting instructions 12308 and menu pre-ordering instructions 12310. There is also a corresponding concierge service setup data 12312, including concierge item data 12314, product number data 12316 and concierge service constraints 12318.
[00347] Referring to Figure 12h, there is shown a representation of specific data files for specific constraint types with examples of the constraints contained within each file and their use. In particular, Figure 12h summarises some of the data or constraints used by each widget, or components of a widget At 1246, there is shown a promotion setup file, which contains promotion constraints inputs 1248, apply to customer x and customer y selected 1250, apply to membership groups X, Y and Z selected 1254, apply to location X selected 1254, apply to notional location X selected 1256, and popup setup 1258.
[00348] There is also shown a table for sale setup 1260 which includes a list of individual tables 1262, a list of classes of tables 1264 and a list of classes of sub areas of tables 1266. Similarly, a table for auction setup 1268 includes a list of individual tables 1262, a list of classes of tables 1264 and a list of classes of sub areas of tables 1266.
[00349] Referring to Figure 12i, there is shown a widgets facility data file 12334, which includes a series of configurable booking constraint data sets 12335, 12336, 12338, 12340 and 12342. There is also shown a facility to post one or multiple widgets to a calendar at 12328. This facility allows the operator to "post" a widget to a calendar - in practical terms, this renders the widget "live" and useable for a defined period of time (e.g. a widget may only be used for a specific promotion, after which the widget is deactivated).
[00350] Referring to Figure 12j, there is shown examples of configurable booking constraint data sets for the drag and drop re-ordering of the hierarchy of tiered constraints for different channels (e.g. different websites and instances of the widget). That is, the operator can configure booking constraint data and also arrange the constraints in a set. There is shown at 12108 an example, where four different widget configuration sets, namely widget configuration la, 1b, 1c and 1d (labelled 12108a, 12108b, 12108c and 12108d respectively). Similarly, there is shown at 12110 an example, where four different widget configurations, namely widget configuration 2a, 2b, 2c and 2d (labelled 12110a, 12110b, 12110c and 12110d respectively. Similarly, there is shown at 12112 an example, where four different widget configurations, namely widget configuration 3a, 3b, 3c and 3d (labelled 12112a, 12112b, 12112c and 12112d respectively). Similarly, there is shown at 12114 an example, where four different widget configurations, namely widget configuration 4a, 4b, 4c and 4d (labelled 12114a, 12114b, 12114c and 12114d respectively).
[00351] Referring to Figure 12k, there is shown examples of configurable booking constraint data sets for posting input. At 12124 there is shown a first set which includes widget configuration la (12126) and widget theme A (12128). At 12130 there is shown a second set which includes widget configuration 2c (12132) and widget theme A (12134). At 12136 there is shown a third set which includes widget configuration la (12138) and widget theme B (12140). At 12142 there is shown a first set which includes widget configuration 4c (12144) and widget theme C (12146).
[00352] Referring to Figure 121, there is shown an alternate functionality widget structures setup file 12330 including setup files for multiple restaurants such as indicated by 12331 and 12332. There is also shown a booking widgets themes setup set of files, including multiple restaurant files 12335 and 12336, each of which includes multiple widget theme files 12337. In this manner, each restaurant may have multiple different themes.
[00353] Referring to Figure 12m, there is shown a representation of a customer file 1214, which includes customer ID 1216, customer data including preferences 1218, customer history 1220, customer behaviour 1222 and customer category/level 1224, as indicated by the multiple files 1213, a separate file is kept for each customer. There are also service or date range files 1232 which include a plurality of nested booking constraints 1234 and promotion information 1236. Correspondingly, there is also provided configurable booking constraint data sets 1294 (and also indicated by 1293), which include multiple configurable booking constraint data sets, indicated by 1296, 1298, 12100 and 12102. Lastly, there are service or data ranges 12153 and 12154 which are associated with each widget configuration 12156, 12158, 12160 and 12162.
[00354] With regard to how a widget, app or website is configured, this is generally shown at Figures 12n and 120. The configuration of each widget, app or website is dependent on two factors - an identifier which is unique to the widget, and the identity of the customer as they interact with the widget. For example, referring to website A (12172), there is shown that at 12174, the configuration ID is captured and a widget corresponding to the configuration ID is loaded at 12176. In the context of the embodiment described, the configuration ID is a compound identifier, which may be an alphanumeric string, a file with discrete data entries, or some other form of data packet. The purpose of the configuration ID is to uniquely identify the widget or app and the information or data that makes up the ID can include a geographic location, a specific alphanumeric identifier that is associated with some other characteristic of the widget or app, or any other information that serves to uniquely identify the instance of the app or widget. The customer then inputs their personal ID at 12178 and a service or date range is selected at 12180. Utilising all the configuration data provided by the website and the customer, the widget then is provided with a package of data 12182 unique to the combination of the channel and the customer. The package 12182 has a unique promotion 12184, configuration 12186 and a unique theme 12188.
[00355] Similarly, referring to website B (12194), there is shown that at 12174, the location is captured and a widget corresponding to the location is loaded at 12198. The customer then inputs their personal ID at 12178 and a service or date range is selected at 12180. Utilising all the configuration data provided by the website and the customer, the widget then is provided with a package of data 12182 unique to the combination of the channel and the customer. The package 12182 has a unique promotion 12206, configuration 12208 and a unique theme 12188.
[00356] Similarly, referring to website C (12216), there is shown that at 12174, the location is captured and a widget corresponding to the location is loaded at 12220. The customer then inputs their personal ID at 12178 and a service or date range is selected at 12180. Utilising all the configuration data provided by the website and the customer, the widget then is provided with widget configuration data 12208, and widget theme data 12188.
[00357] Referring to Figure 120, referring to kiosk A (12242), there is shown that at 12242, the customer inputs their personal ID at 12178 and the location is captured 12174. A service or data range is selected at 12180 and utilising all the configuration data provided by the website and the customer, the widget then is provided with a package of data 12250 unique to the combination of the channel and the customer. The package 12250 provides promotion data 12182, widget configuration data 12253, and widget theme data 12256.
[00358] Similarly, referring to app A (12270), there is shown that at 12242, the customer inputs their personal ID at 12178 and the location is captured 12174. A service or data range is selected at 12180 and utilising all the configuration data provided by the website and the customer, the widget then is provided with a package of data 12250 unique to the combination of the channel and the customer. The package 12250 provides promotion data 12182, widget configuration data 12253, and widget theme data 12255.
[00359] Referring to Figure 13a, there is shown a programmable portion of the widget or app which includes interaction with a scheduler. There is shown a ResButler project module 12276 representing the "booking engine" described in more detail elsewhere in the present specification. It will be understood that while the embodiment described is directed to a system for booking at a restaurant, the inventive concept has broader application than the embodiments described herein.
[00360] The project module 12276 is in functional connection with a Point of Sale module 12278, which in turn may reside on a device 12280 arranged to display an interface 12282. In turn the device 12280 is in communication with a restaurant, which in the example embodiment is simply referred to as "Restaurant A" point of sale (12286) (as may be other restaurant point of sale databases such as 12320) which in turn is in communication with a ResButler menu and display setup file 12302 and a concierge service setup 12312, each of which are in communication with further components as connected to arrow A (which is described in more detail in Figure 13b).
[00361] The module 12276 is also in communication with a device, such as a desktop computer, a tablet computing system or a smartphone. The device is capable of rendering an interface 1202, the interface being set up via the utilisation of a CRM setup file or data (in the case where the data is not in a file per se but is embedded in a relational database or similar). The CRM setup file 1208 includes customer setup input data 1206 and membership, benefits, offers and preferences data 1208, which is derived from a source described in more detail with reference to Figure 13d (see arrow D, which is connected to Figure 13d). In turn, CRM setup 1204 interacts with a booking constraints setup file 1238, which includes information for multiple restaurants such as restaurant B (1239) and restaurant A (1240). Referring specifically to restaurant A (1240) as an example of the information provided within a restaurant booking constraints file, there is provided at 1242 a plurality of interrelated and nested booking constraints, a promotions setup file 1244 which includes promotions information such as promotion A (1244) a table for sale file 1260 and a table for auction file 1268.
[00362] The booking constraints setup 1238 also interacts with a booking constraints calendar 1276 which includes information for multiple restaurants such as restaurant A 1278 and restaurant B 1277, and in each restaurant file there is includes a service or date range 1280 which includes a plurality of interrelated nested booking constraints 1282, details of promotions 1284, details of tables for sale 1286 and details of tables for auction 1288.
[00363] Referring to Figure 13b, there is shown a continuation of arrow A from Figure 13a (and continues along arrow B to Figure 13c), wherein a device is capable of hosting a widget for a website, app or analogous software application (computer program arranged to be executable on a device), wherein execution of the widget, app or software application causes the ResButler interface 1202 to be displayed on the device (display not shown). For the interface 1202 to function correctly, the interface must be capable of accessing and utilising a restaurant registration and widget/code snippet setup file 12330, which includes multiple booking widget strategiser files (12331 and 12332) for each restaurant, wherein each strategiser file includes the interface to control the one or multiple widget facility 12334, which in turn is in communication along arrow C, which is described in more detail with reference to Figure 13c. The widget/code snippet setup file is in communication with a configurable constraint data set (see along arrow F to Figure 13d).
[00364] The ResButler Interface 1202 for the widget also includes a theme setup file 13000 including theme setup files for multiple restaurants 13001 and 13002. Within each restaurant setup file there are multiple themes, such as 13003 and 13004.
[00365] Referring to Figure 13c there is shown a device including a ResButler interface 1202, which includes a booking widget configurator and scheduler 13006 which in turn is connected to other components, modules and data files via arrows B and C which are described in Figure 13b. The interface is connected to other components, modules and files as indicated by arrows G and H, which are described in more detail in Figure 13d.
[00366] Returning to the widget configurator and scheduler 13006, there are included multiple restaurant modules 13007 and 13008, with each restaurant module, such as module 13008 having multiple widget configuration files 13010, 13012, 13014 and 13016. There is also provided a widget configurator 13018 which includes various configurable booking constraint data sets 13020, 13024, 13028 and 13032. Within each constraint data set there are widget themes such as 13022, 13026, 13030 and 13034. There is also provided a widget scheduler 13036 which includes specific time periods such as meal periods 13038, specific date or date ranges 13040 and days of the week 13042.
[00367] There is also provided an alternate functionality widget structure 12330 which includes multiple restaurant files 13043 and 13044. Alternate functionality widget 12330 is connected to other components, modules and files as indicated by arrow H, which are described in more detail in Figure 13d.
[00368] Referring to Figure 13d there is shown a continuation of the components, modules and data files shown in Figures 13a-13i generally. Referring specifically to ResButler booking database 12274, which is connected to arrows Z and Y, which in turn are connected to ResButler project module 12276 and Point of Sale module 12278 respectively, there is provided a series of customer behaviour records 1226. Moreover, ResButler Booking Database 12274 is connected via arrow I to further components, modules and files as described in more detail in Figure 13e.
[00369] Correspondingly there is provided a client booking database 13049 which includes the customer behaviour records 1226 which are in turn connected to a configurable Customer Relationship Management module 1212, which includes customer records 1213 including specific customer record for customer A 1214. Customer behaviour records 1226 are also connected via arrow J to further components, modules and files as described in Figure 13e.
[00370] There is also provided an overarching set of files per restaurant such as the files 1227 including a specific file for Restaurant A 1228, which includes booking constraints calendar 1292, including multiple service or date ranges 1293 and 1294. File 1228 also includes a configurable booking constraint data set 1295and 12194, and also includes widget configuration 13046, which includes multiple widget configurations 13010, 13012, 13014 and 13016, and also alternate functionality widget structures 13048.
[00371] Customer behaviour records 1226 are also connected to booking constraint calendar 1292, configurable booking constraint data set 1295 and widget configuration 13046.
[00372] Referring to arrow D which is connected to Figure 13a, at step 1210 customer data and ID are saved to configurable CRM 1212, within the client database 13049. Similarly, referring to arrow E which is also connected to Figure 13a, at step 1290 booking constraints are saved to client booking constraints calendar 1292.
[00373] Turning to arrow F, which is connected to Figure 13b, at step 12326 configurable booking constraint data sets are saved to the restaurant file 1228, within the client database 13049, as the configurable booking constraint data set 1295. Referring to arrow G, which is connected to Figure 12c, at step 12104 configurable booking constraint data set IDs populate a number of configurable booking constraint data sets and are also saved in booking constraint data set 1295. Constraint booking data set 1295 is in turn connected to other components, modules and files via arrow J, which is described in more detail in Figure 13e.
[00374] Lastly, turning to arrow H, which is connected to Figure 13c, at step 12150 the widget configuration is saved to the client database into the widget configuration 13046.
[00375] Referring to Figure 13e there is shown a continuation of arrow I from Figure 13d, where at step 12168, an html code snippet for a configurable booking constraint data set is embedded on website 12172 which is hosted on device.
[00376] Similarly, there is a continuation of arrow J, which is connected to a server 12164 that includes an instance of the online booking widget 12166 which can then be deployed as code snippets 12168, 12190 and 12212 to websites 12172, 12194 and 12216on devices, \ Devices are also capable of interacting with other components of the ResButler system as shown by arrows L and M which are described in Figure 13f and 13d respectively.
[00377] Referring to Figure 13f, there is shown a continuation of arrow K from Fig 13e, where at step 12232 and 12258 code snippets for data set 3 and 4 respectively are loaded on website D (12234) and website E (12260) respectively, by using ID 3 (12236) and ID set 4 (12262). Utilising iFrame technology 12238, the widget is then displayed as an app 12242 on a kiosk or an app 12270 on a mobile device. There is also shown an API link data set 12256 and 12272which is capable of interfacing directly with devices. Devices are also capable of interfacing directly with other components as shown by arrow L, which is connected to components, modules and files represented in Figure 13e.
[00378] Referring to Figure 13g there is shown a widgets facility data file 12334, which includes a series of configurable booking constraint data sets 12335, 12336, 12338, 12340 and 12342. There is also shown a facility to post one or multiple widgets to a calendar at 12328. This facility allows the operator to "post" a widget to a calendar - in practical terms, this renders the widget "live" and useable for a defined period of time (e.g. a widget may only be used for a specific promotion, after which the widget is deactivated).
[00379] With regard to how a widget, app or website is configured, this is generally shown at Figures 13h and 13i. The configuration of each widget, app or website is dependent on two factors - an identifier which is unique to the widget, and the identity of the customer as they interact with the widget. For example, referring to website A (12172), there is shown that at 12174, the configuration ID is captured and a widget corresponding to the configuration ID is loaded at 12176. The customer then inputs their ID at 12178 and a service or date range is selected at 12180. Utilising all the configuration data provided by the website and the customer, the widget then is provided with a package of data 12182 unique to the combination of the channel and the customer. The package 12182 may provide promotion data (not shown), widget configuration data 12186 and widget theme data 12188.
[00380] Similarly, referring to website B (12194), there is shown that at 12174, the configuration ID is captured and a widget corresponding to the configuration ID is loaded at 12198. The customer then inputs their ID at 12178 and a service or date range is selected at 12180. Utilising all the configuration data provided by the website and the customer, the widget then is provided with a package of data 12182 unique to the combination of the channel and the customer. The package 12182 may provide promotion data (not shown), widget configuration data 13050 and widget theme data 12188.
[00381] Similarly, referring to website C (12216), there is shown that at 12174, the configuration ID is captured and a widget corresponding to the configuration ID is loaded at 12220. The customer then inputs their ID at 12178 and a service or date range is selected at 12180. Utilising all the configuration data provided by the website and the customer, the widget then is provided with widget configuration data 13050, and widget theme data 12188.
[00382] Referring to Figure 13i referring to kiosk A (12242), there is shown that the customer inputs their ID at 12178 and the location is captured 12174. A service or data range is selected at 12180 and utilising all the configuration data provided by the website and the customer, the widget then is provided with a package of data 12250 unique to the combination of the channel and the customer. The package 12250 provides promotion data (not shown), widget configuration data 13052, and widget theme data 12256.
[00383] Similarly, referring to app A (12270), there is shown that the customer inputs their ID at 12178 and the location is captured 12174. A service or data range is selected at 12180 and utilising all the configuration data provided by the website and the customer, the widget then is provided with a package of data 12250 unique to the combination of the channel and the customer. The package 12250 provides promotion data (not shown), widget configuration data 13053, and widget theme data 12256.
[00384] Referring to Figure 14a there is shown a screenshot of administrative interface for managing widget channels. As previously described, each "channel" generates a unique instance of the booking widget, which is arranged to have a unique set of constraints, access to promotions, etc., such that specific channels can be developed for specific third-party vendors, for promotions, or for any other reason where an operator wishes to segment the market and provide a unique solution for each channel. At 1400 there is shown a title, and at 804 there is provided a drop-down menu for selecting a restaurant. A new channel may be created by clocking the new channel button 1402. At 1404 existing channels are listed including the name(s) of the channel(s) 1406, 1408, 1410 and 1412, an indicator 905 that the channels are enabled, and an edit button 906.
[00385] Referring to Figure 14b, there is shown a screenshot of a create channel popup window. If the new channel button 1402 of Figure 14a is selected, the popup window of Figure 14b is presented to the operator. The popup has an identifying title 1414, a drop-down menu to select restaurants 804, and a data input area 1416 including a text box for a name for the channel 1418, and a restaurant selection box 1420, plus a tick box which allows the operator to enable the channel 1422.
[00386] Referring to Figure 14c, there is shown a screenshot of a restaurant booking widget configurator screen or popup window including a restaurants elector 804, a drop down menu for posting to a particular date/group of dates/service/group of services (as previously defined by the operator) 1405, and various widget categories 808 which include subcategories 812 and 814 and apply to each instance or deployment of the widget 1406, 1408 and 1410. The individual items within each sub-category can be moved using arrows 816.
[00387] Referring to Figure 14d, there is shown a screenshot of a restaurant booking widget configurator screen or popup window including a restaurants elector 804, a drop down menu for posting to a particular date/group of dates/service/group of services (as previously defined by the operator) 1405, and various widget categories 808 which include subcategories 812 and 814 and apply to each instance or deployment of the widget 1406, 1408, 1410 and 1412. In this instance, when compared to Figure 14c, it can be seen that Figure 14d includes a new instance, namely the column 1412 which includes toggle controls for an app deployment of the widget. The individual items within each sub-category can be moved using arrows 816.
[00388] Referring now generally to Figures 15a-d, there are shown various screenshots of an email template interface. The embodiment described herein utilises automated emails as a portion of the manner in which the embodiment communicates with end users (customers). The email template interface allows the operator to set up various email templates. At Figure 15a, there is shown an email template screen including a title display 1500, a drop-down menu which allows a user to select the channel a set of templates is being set up for, the ability to add a header logo 1504 and a footer logo 1506 and the ability to add footer text 1508.
[00389] Referring to Figure 15b, there is shown a screenshot of another template interface 1510 for a booking confirmation email, at which an operator can enter a confirmation message 1512, attach an image 1514, add promotion text 1516 and upload a promotion image 1518, and subsequently review the template by pressing the preview button 1520.
[00390] Referring to Figure 15c, there is shown a screenshot of another template interface 1522 for a waitlist booking confirmation email, at which an operator can enter a confirmation message 1524, attach an image 1526, add promotion text 1528 and upload a promotion image 1530, and subsequently review the template by pressing the preview button 1520.
[00391] Referring to Figure 15d there is shown a screenshot of another template interface 1532 for an upcoming booking, at which an operator can enter an upcoming booking message 1534, attach an image 1536, enter the time before the booking that the email should be sent 1538 add promotion text 1540 and upload a promotion image 1542, and subsequently review the template by pressing the preview button 1520.
[00392] Referring to Figure 16a there is shown an email process triggered by the creation of a booking. At step 1600, a customer submits a successful booking via the booking widget. At step 1602, a determination is made as to whether the booking includes a prepayment concierge service item. If yes, four emails are sent, as shown at steps 1604, 1612, 1620 and 1624. Referring to step 1604, an email is sent to the restaurant, in the form of a new booking email 1606, which includes booking details 1608 and a link to the dashboard 1610. Referring to step 1612, an email is sent to the customer, in the form of a booking email 1614, which includes booking details 1608, an update booking link 1616 and a menu pre-order link 1618. Referring to step 1620, an email is sent to the customer's guests, in the form of an invitation email 1622, which includes booking details 1608 and a menu pre-order link 1618. Referring to step 1624, an email is sent to the supplier, in the form of a new order email 1626, which includes order details 1628 and booking details 1608.
[00393] If the booking does not include a concierge item, the email creation process continues along arrow 1, which is described in more detail in Figure 16b.
[00394] Referring to Figure 16b there is shown a continuation the email creation process as indicated by arrow 1 (in the case where a booking request does not include a pre-ordered concierge item), which is further described with reference to Figure 16a. Referring to step 1604 of Figure 16b, an email is sent to the restaurant, in the form of a new booking email 1606, which includes booking details 1608 and a link to the dashboard 1610. Referring to step 1612, an email is sent to the customer, in the form of a booking email 1614, which includes booking details 1608, an update booking link 1616 and a menu pre-order link 1618. Referring to step 1620, an email is sent to the customer's guests, in the form of an invitation email 1622, which includes booking details 1608 and a menu pre-order link 1618.
[00395] Referring now to Figure 16c, there is shown a process by which emails are created as a result of a waitlist booking. At step 1630, a customer submits a waitlist booking via the booking widget. This triggers at steps 1604 and 1612 respectively, an email to be sent to the restaurant and an email to be sent to the customer. At step 1604, the email sent to the restaurant is in the form of a new waitlist booking email 1632 which includes waitlist booking details 1634 and a link to the dashboard 1610. At step 1612, the email sent to the customer is in the form of a waitlist booking email 1636 which includes waitlist booking details 1634 and a link to the booking widget 1616 which allows for the updating of details.
[00396] Referring to Figure 16d, there is shown, in conjunction with Figure 16e, a process flow for email generation when a booking is cancelled. At step 1638, a customer cancels their booking. If, as per step 1602, the booking does not include prepayment for a concierge item, the process continues along arrow 2, which is described with reference to Figure 16e.
[00397] If the booking includes prepayment for a concierge item, a determination is made at step 1640 as to whether a refund is due. If not, the process continues along arrow 3, which is described with reference to Figure 16e.
[00398] If a refund is payable, then four emails are generated at steps 1604, 1612, 1620 and 1624. At step 1604, an email is sent to the restaurant in the form of a cancelled booking email 1642, which includes booking details 1644. At step 1612, an email is sent to the customer in the form of a cancelled booking email 1646, including cancelled booking details 1648 and refund details 1646. At step
1620, an email is sent to the customer's guests in the form of an invitation cancelled email 1652 which includes cancelled booking details 1648. Lastly, at step 1624, an email is sent to the supplier in the form of a cancelled order email 1654 including cancelled order details 1656. The receipt of this email results, at step 1658, in the order being removed from the supplier calendar.
[00399] Referring now to Figure 16e, which shows a continuation of the cancelled booking email generation process described with reference to Figure 16d, if a booking does not include a prepayment component (as described in Figure 16d and indicated by arrow 2 in both Figures 16d and 16e), then three emails are sent as indicated by step 1604, 1612 and 1620. At step 1604, an email is sent to the restaurant in the form of a cancelled booking email 1642, which includes booking details 1648. At step 1612, an email is sent to the customer in the form of a cancelled booking email 1646, including cancelled booking details 1648. At step 1620, an email is sent to the customer's guests in the form of an invitation cancelled email 1652 which includes cancelled booking details 1648.
[00400] Referring to arrow 3, which is a continuation of the case where a booking includes a prepayment component, but no refund is due (as described in Figure 16d), four emails are sent, as indicated by step 1604, 1612, 1620 and 1624. At step 1604, an email is sent to the restaurant in the form of a cancelled booking email 1642, which includes booking details 1644. At step 1612, an email is sent to the customer in the form of a cancelled booking email 1646, including cancelled booking details 1648 and a message that no refund is due 1660. At step 1620, an email is sent to the customer's guests in the form of an invitation cancelled email 1652 which includes cancelled booking details 1648. Lastly, at step 1624, an email is sent to the supplier in the form of a cancelled order email 1654 including cancelled order details 1656. The receipt of this email results, at step 1658, in the order being removed from the supplier calendar.
[00401] Referring to Figure 16f, there is shown a process for the generation of emails when a waitlisted booking is cancelled. At step 1662, a customer cancels a waitlisted booking. This generates two emails at steps 1604 and 1612. At step 1604, a cancelled waitlist booking email 1664 is sent to the restaurant, the email including cancelled waitlist booking details 1666. Similarly, at step 1612, a cancelled waitlist booking email 1668 is sent to the customer, the email including cancelled waitlist booking details 1666.
[00402] Referring to Figure 16g there is shown a process by which emails are created as a result of a booking being converted from a waitlist booking to a confirmed booking. At step 1668, a waitlist booking is converted to a confirmed booking. This triggers steps 1604 and 1612 respectively, where an email is sent to the restaurant and an email is sent to the customer. At step 1604, the email sent to the restaurant is in the form of a converted booking email 1670 which includes converted booking details 1608 and a link to the dashboard 1610. At step 1612, the email sent to the customer is in the form of a converted booking email 1672 which includes booking details 1608 and a link to the booking widget 1674 which allows for the updating of details. If at step 1676 the customer clicks on the link 1674 and updates their details, a determination is made at step 1602 as to whether the booking includes a prepayment concierge service item. If no, the process continues along arrow 4, which is described with reference to Figure 16h. If yes, the process continues along arrow 5, which is described with reference to Figure 16i.
[00403] Referring to Figure 16h there is shown a continuation the email creation process as indicated by arrow 4 (in the case where a booking request does not include a pre-ordered concierge item), which was described with reference to Figure 16g. Referring to step 1604 of Figure 16h, an updated booking email 1678 is sent to the restaurant, which includes updated booking details 1680 and a link to the dashboard 1610. Referring to step 1612, an email is sent to the customer, in the form of an updated booking email 1682, which includes booking details 1680, an update booking link 1616 and a menu pre-order link 1618. Referring to step 1620, an email is sent to the customer's guests, in the form of an invitation email 1622, which includes booking details 1608 and a menu pre-order link 1618.
[00404] Referring to Figure 16i, referring to arrow 5, which is a continuation of the case where a booking includes a prepayment component (as described in Figure 16g), four emails are sent, as indicated by step 1604, 1612, 1620 and 1624. At step 1604, an email is sent to the restaurant in the form of an updated booking email 1678, which includes updated booking details 1680 and an updated link to the dashboard 1610. At step 1612, an email is sent to the customer in the form of an updated booking email 1682, including updated booking details 1680, update booking details link 1616 and a menu pre-order link 1618. At step 1620, an email is sent to the customer's guests in the form of an invitation email 1622 which includes updated booking details 1608 and a menu pre-order link 1618. Lastly, at step 1624, an email is sent to the supplier in the form of a new order email 1626 including order details 1628 which in turn include booking details 1608.
[00405] Referring to Figure 16j there is shown an automated process that generates emails when a customer updates a booking. At step 1676, a customer updates a booking. If no concierge item is added by the updating of the booking, the process continues along arrow 6, joining the process described in more detail with reference to Figure 16k.
[00406] Alternatively, if the process does include a concierge item, four emails are sent, as shown at steps 1604, 1612, 1620 and 1624. Referring to step 1604, an email is sent to the restaurant, in the form of an updated booking email 1678, which includes updated booking details 1680 and a link to the dashboard 1610. Referring to step 1612, an email is sent to the customer, in the form of an updated booking email 1682, which includes updated booking details 1680, an updated booking link 1616 and a menu pre-order link 1618. Referring to step 1620, an email is sent to the customer's guests, in the form of an updated invitation email 1684, which includes booking details 1680 and a menu pre-order link 1618.
Referring to step 1624, an email is sent to the supplier, in the form of a new order email 1626, which includes order details 1628 and booking details 1608.
[00407] Referring to Figure 16k there is shown a continuation the email creation process as indicated by arrow 6 (in the case where a booking request does not include a pre-ordered concierge item), which is further described with reference to Figure 16j. Referring to step 1604 of Figure 16k, an email is sent to the restaurant, in the form of an updated booking email 1678, which includes updated booking details 1680 and a link to the dashboard 1610. Referring to step 1612, an email is sent to the customer, in the form of an updated booking email 1682, which includes updated booking details 1680, an updated booking link 1616 and a menu pre order link 1618. Referring to step 1620, an email is sent to the customer's guests, in the form of an updated invitation email 1684, which includes booking details 1680 and a menu pre-order link 1618.
[00408] Referring to Figure 161 there is shown an automated upcoming booking email process. At step 1686, a trigger (such as a set time before a service period) causes two emails to be sent, as shown at steps 1612 and 1620. At step 1612, an upcoming booking emails 1688 is sent to the customer, the email including booking details 1608 and a confirmation link 1690. Simultaneously, at step 1620, an invitation reminder email 1692 is sent to the customer's guests, the email including booking details 1608.
[00409] Referring to Figure 16m, there is shown a process for autonomously generating daily supplier emails. At step 1694, the system determines whether there are any third-party concierge items existing for the specified date. If not, the process ends at step 16014. If yes, at step 1624 a daily order email 1696 is sent to the supplier. The daily order email 1696 includes order details 1698 and 16002 which in turn includes booking details 1608, so that each order is associated with the correct booking. There is also provided a confirm orders link 16004. Once the supplier receives the email, the supplier may confirm the order 16006, in which case the orders are conformed on the supplier calendar at step 16008. Alternatively, if the supplier does not confirm the order at 16010, the orders remain unconfirmed at step 16012.
[00410] Referring to Figure 16n there is shown a booking notification email process for a SVIP/VIP in accordance with an embodiment of the invention. At 16016 there is shown a trigger arranged to send an email at a set time daily. At 16018 there is an email sent to the restaurant and any other set recipients which includes an email of daily SVIP/VIP bookings 16020 which includes booking details 16022 and 16024.
[00411] Referring to Figure 160, there is shown a SVIP/VP arrival notification email, where, upon the trigger 16026 of the SVIP/VIP being seated in the restaurant, an email is sent to the restaurant and any relevant operators 16018 to notify the operators of the SVIP/VIP arrival 16028.
[00412] Referring to Figures 17a-d, there is shown screenshots for the concierge service categories setup. The concierge service setup allows the operator to set up specific concierge service categories to which specific products from the POS can be added to, then displayed and offered as concierge service items on the booking widget. The operator can set up services through the interface shown in Figures 17a-d generally. Referring specifically to Figure 17a, the interface includes an identifying title 1700, a drop-down menu for selecting a restaurant 1702, the ability to add a new concierge service category 1704, and a list of concierge service categories 1706, which can be edited 1711.
[00413] Referring to Figure 17b, when a new concierge service category is added by selecting the new concierge service category button 1704 of Figure 17a, there is displayed a further screen as per Figure 17b, which includes an identifying title 1700, the ability to select a restaurant 1702, a name input 1710, a short description 1712, a checkbox to enable the category 1714, plus a button to save the category 1713.
[00414] Referring to Figure 17c, there is shown a further setup screen including an identifying title 1716, the ability to select a restaurant 1702, a product group selection dropdown 1718, a name input box 1720, a description input box 1722 an enable button 1724, an enable for booking widget concierge service button 1726 and a save button 1713.
[00415] Referring to Figure 17d, there is shown a further screenshot for editing a particular service including an identifying title 1722, the ability to select a restaurant 1704, the selection of a product group 1724, the addition of a name 1726, the addition of a description 1728, the ability to enable the service 1718 and enable for the widget 1730, the ability to place the service in a category 1732, the ability to calculate a price 1720, the ability to require prepayment 1734 and the ability to allow a customer to provide text input 1736, plus the ability to save the aforementioned information for future use 1720.
[00416] It will be understood that while the inventive reduction to practice of providing a configurable widget or app that may be deployed via various channels has been described with reference to a restaurant booking example, the underlying inventive concept and the embodiment described herein may be modified to provide use in analogous instances where there is a technical advantage that arises from the ability to deploy "customised" widgets and apps. For example, customised widgets and apps find application in the booking of other services, in eCommerce platforms or in the provision of other services. Figures 18a-f illustrate some examples of the types of uses that the inventive concept and the embodiment may be applied to, with relevant modification to the information and specific use.
[00417] Referring to Figure 18a there is shown multiple configurations by channel for one or more widgets or apps. At 1800, there is shown the ResButler interface including a widget configuration facility 1802 which includes multiple widget configurations 1804, 1814, 1824 and 1834. Each widget configuration contains a code snippet 1806, 1816, 1826 and 1836 respectively. Each code snippet is deployed to a corresponding website, 1808, 1818, 1828 and 1838, where each widget configuration is loaded and displayed 1810, 1820, 1830 and 1840 respectively. Each widget configuration includes transaction constraint fields 1812, 1822, 1832 and 1842 relevant to a transactional system, such as an eCommerce site.
[00418] Referring to Figure 18b there is shown multiple configurations by channel for one or more widgets or apps. At 1800, there is shown the ResButler interface including a widget configuration facility 1802 which includes multiple widget configurations 1804, 1814, 1824 and 1834. Each widget configuration contains a code snippet 1842, 1846, 1850 and 1854 respectively. Each code snippet is deployed to a corresponding website, 1808, 1818, 1828 and 1838, where each widget configuration is loaded and displayed 1810, 1820, 1830 and 1842 respectively. Each widget configuration includes booking constraint fields 1844, 1848, 1852 and 1856 which include fields relevant to the provision of a booking service.
[00419] Referring to Figure 18c, there is shown multiple configurations by channel for one or more widgets or apps where the channels are used to book a legal service. At 1800, there is shown the ResButler interface including a widget configuration facility 1802 which includes multiple widget configurations 1804, 1814 and 1824. Each widget configuration contains a code snippet 1842, 1846, and 1850 respectively. Each code snippet is deployed to a corresponding website, 1858, 1862 and 1866, where each widget configuration is loaded and displayed 1810, 1820 and 1830 respectively. Each widget configuration includes constraint fields 1860, 1864 and 1868 which include data fields relevant to the provision of a legal service.
[00420] Referring to Figure 18d there is shown multiple configurations by channel for one or more widgets or apps which is specifically adapted to be utilised by a travel company. At 1800, there is shown the ResButler interface including a widget configuration facility 1802 which includes multiple widget configurations 1804, 1814, 1824 and 1834. Each widget configuration contains a code snippet 1842, 1846, 1850 and 1854 respectively. Each code snippet is deployed to a corresponding website, 1808, 1818, 1828 and 1838, where each widget configuration is loaded and displayed 1810, 1820, 1830 and 1842 respectively. Each widget configuration includes constraint fields 1870, 1872, 1874 and 1876 which include data fields relevant to a travel company.
[00421] Referring to Figure 18e there is shown multiple configurations by channel for one or more widgets or apps. At 1800, there is shown the ResButler interface including a widget configuration facility 1802 which includes multiple widget configurations 1804, 1814, 1824 and 1834. Each widget configuration contains a code snippet 1842, 1846, 1850 and 1854 respectively. Each code snippet is deployed to a corresponding website, 1878, 1882, 1886 and 1890, where each widget configuration is loaded and displayed 1810, 1820, 1830 and
1842 respectively. Each widget configuration includes constraint fields 1880, 1884, 1888 and 1892 relevant to the booking of a hotel.
[00422] Referring to Figure 18f there is shown a configuration by channel for one or more widgets or apps. At 1800, there is shown the ResButler interface including a widget configuration facility 1802 which includes multiple widget configurations 1804 and 1814. Each widget configuration contains a code snippet 1842 and 1846 respectively. Each code snippet is deployed to a corresponding website, 1894 and 1898 (for Widget configuration 1 - 1804), and 18002 (for widget configuration 2 1814), where each widget configuration is loaded and displayed 1810 (for website 1894 and app 1898) and 1820 (for Website 18002). Each widget configuration includes respective constraint fields 1896 and 18004).
[00423] Referring to Figure 19a there is shown an example of an embodiment of the invention when utilised using a voice interface in lieu of a visual interface (e.g. a website or app). It will be understood that the concept of different channels remains relevant as there is still a large amount of customisation that is not explicitly relevant to visual elements of the interface. At Figure 19a there is shown a user 1900 that interacts with a device 1916 (which may be a smartwatch, smartphone, tablet, computing system or smart "home device" (such as a Google Home or Amazon Alexa device). At 1902, the user asks the device to make a booking. At 1904, the device responds with specific questions (utilising constraints and taking into consideration information about the user). The user and the device then proceed through a series of questions and answers a 1906, 1908, 1910, 1912 and 1914. Each of the questions 1904, 1908, 1912 and 1914 are determined "on the fly" dependent on the customer's identity, the availability in the restaurant to make a booking, etc. In other words, the device is not utilising a pre-determined "script" per se but is dynamically varying the responses and questions based on the channel, the customer identity and the allocation algorithm.
[00424] Referring to Figure 20a, there is shown a flowchart illustrating a menu pre-payment process including the selection and payment of menu items, prior to the booking date, and linking the prepayment to a unique booking and table once allocation has been finalised. At step 2000, a customer accesses the menu pre ordering widget. The customer is identified at step 2002, after which an interactive display illustrating the relevant table and chair position numbers for the booking is displayed at step 2004. The customer assigns guests at step 2006 to each chair position, and thereafter, an interactive menu is displayed at step 22008. The customer selects items at step 20190, and at step 2012, an order summary is displayed.
[00425] Thereafter, pre-payment options are displayed at step 2014, and the customer prepays for selected items at 2016. The transactions are subsequently added to the customer's account at step 2018. After prepayment and menus selection, then at step 2020 the transaction is added to a specific table when at a specific time before service, booking are allocated to tables at step 2022, all booking information including menus are associated with the stable at step 2024, such that when the customers arrive at step 2026, they are seated, and if all orders have been pre-paid and pre-ordered, then at step 2028 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.
[00426] Referring to Figure 20b, there is shown the interaction between the device (customer device or kiosk) 2030 and a CRM 2046 within a database 2044, demonstrating the facility to personalise a user's experience of the booking process based on information about the customer from collected customer data within the CRM system. The device 2030 is capable of executing a widget 2032 in accordance with an embodiment of the invention. The interface of the widget 2032 allows the customer to input an identified 2034, which is then used by the widget (at 2043) to request CRM information from the client database 2044. Returning to the widget, once the CRM information is identified, the information is sent to the widget at step 2062 and is customised at step 2064, in order to display on the user interface of the widget 2032 specific promotions 2036, menu-related constraints 2038, and to hide or show specific fields based on constraint information as shown at 2040. The customer completes and submits the pre-order at 2042.
[00427] Returning to the client database 2044, included in the database is a CRM 2046, the CRM including customer records such as Customer 'A' record 2048m which includes a customer ID 2050, booking history 2052, membership information 2054, customer preference data including dietary preferences, etc. 2056, customer behaviour information 2058, wherein the record 2048 is also associated with relevant promotions 2060.
[00428] Referring to Figure 20c, there is shown a flowchart illustrating a product setup to enable a product for menu configuration for the menu pre-ordering widget, where menu configuration is referring to the automated adjustments and personalisation of menu items provided to specific patrons based on CRM information including patron booking history, recorded dietary requirements and allergies etc. At step 2066, the operator selects a product setup and at step 2068, the operator selects a new product option. Subsequently, the operator selects a product group to assign the new product to at step 2070, and the operator inputs the full name of the product at 2072 and the product description at 2074. The operator then inputs the PLU barcode number for the product at 2076 and subsequently elects a restaurant to assign the product to at 2078. The operator then inputs a product price at 2080, and a display name (for display on the widget) at 2082. The operator selects a relevant product supplier at 2084 and a product price calculation type at 2086. The operator then enables the product as an active menu item at 2088 and then selects the variation button at 2090 to access the setup interface for product variations. At step 2094 the operator selects items from stock to add to the product ingredients list and at 2096 the operator inputs preparation time and cooking time.
[00429] At step 2098 the operator inputs the method of preparation and cooking. Optionally, at step 20100, the operator adds an alternative product. At step 20104 the operator s4elects an alternative product description, and at 20106 the operator selects appropriate allergy and or dietary requirement categories. The operator modifies the ingredients for the alternative product at 20108 and the operator saves the alternative product details at 20112. The operator then saves all product details at 20114. 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.
[00430] Referring to Figures 20d to 20f, there are shown screenshots which display the input screens associated with the process flow described with reference to Figure 20c. Firstly referring to Figures 20d, there is shown a product setup screen 20116, which is generally under the admin section of the ResButler interface, as indicated by pathway 20117. The operator can select a product group 20118, input a name 20120, input a description 20122, enter a barcode 20124, associate the product with a restaurant 20126, enter a sale price 20128 and decide whether the product will be visible on the menu 20130. If the product is to be visible, the operator can attach a display description 20132, can select a supplier 20134, can choose one of a number of price calculation mechanisms, and can enable the whole product at 20138. The operator can also add recipes and product variations by clicking button 20140, add cooking instructions by clicking button 20142 and add associated condiments by clicking button 20144. The operator can then save the input information by clicking the save button 20146.
[00431] Referring to Figure 20e, if the operator clicks the recipe button 20140, the operator is provided with the input screen 20150 shown at Figure 20e. The operator is presented with a stock item from which the user can add items using add item buttons 20155. If added, the items are displayed in selected ingredients screen 20156 and the operator can add a quantity as shown generally at 20158. The operator can delete items from the ingredients list by using button 20159. The operator can add a preparation time at 20160 and a cooking time at 20116. The operator can also add cooking instructions at 20162 and can enter variations (alternative products) at area 20164. The user can add an alternative product description at 20166, select relevant allergies at 20168 and relevant dietary requirements at 20170 and is provided with a modified ingredients list at 20172, where the operator can add an ingredient using button 20174 and remove ingredients using button 20176 or substitute ingredients using button 20178.
[00432] Referring to Figure 20f, there is shown a continuation of the alternative ingredients screen 20164 of Figure 20e. The operator can add a different preparation time at 20180, a different cooking time at 20182 and a different recipe or cooking method at 20184. Once finished entering information, the operator can save the alternative product at 20146.
[00433] Referring to Figures 20g-1, there are shown various screenshots of an ordering widget which utilises the menu and product items created with reference to Figures 20c-e. At Figure 20g, there is shown a first screen 20188 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 20186 or may be displayed to the customer in some other manner. The booking widget 20188 includes the restaurant name 20189, the number of guests 20190, the date of the booking 20191 and the time of the booking 20192. The display also includes the name of the customer who booked the space 20193 and a unique reference for the booking 20194. Using various buttons, the customer can edit a booking using button 20196, cancel a booking using button 20197, pre-order from the menu using button 20198 or view promotions using button 20199.
[00434] 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 20200 which includes instructions 20202, where the customer can enter a booking reference number 20204 is known, or alternatively enter an email address 20206 and a booking date 20208 before clicking the continue button 20210.
[00435] Referring to Figure 20h, there is shown a subsequent screen 20212 which is displayed once the customer is identified and elects to pre-order their meal. AT screen 20212 there is shown a welcome message 20214, a descriptor of the person logged in at 2021, and a general area 20215 which includes information about the booking 20218, a logo 20216, a link to view the table booked 20220, a link to view existing orders associated with the booking 20222, a listing of guests 20224 including each guest name 20226 and a facility to edit the guest name 20228. 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 20231.
[00436] There is further provided a series of tabs in area 20232, such as tab 20234 which corresponds to a specific guest, and tab 20235 which corresponds to the table. There is also shown the menu generally denoted by 20236, with various menu items (such as 20238) grouped under headings 20237 and 20242. There are also shown prices 20239 and the ability to add an item using add button 20240.
[00437] Referring to Figure 20i, if the customer selects the table booked view button from Figure 20h (20220) a screen 20244 is displayed including a representation of the table 20246, a representation of chairs 20243 and 20245, where the selected chair is coloured differently (20245), and a tab representing each guest 20248, 20249, 20251 and 20253. Each guest tab allows a first name 20250 to be input, a last name 20252 to be input, an email address 20254 to be input, a mobile number 20256 to be input, a allergy to be optionally selected 20258 and a dietary requirement 20260 to be selected. All information input can be saved using button 20146 or cancelled using 20262.
[00438] Referring to Figure 20j, there is shown a closeup of a portion of the screen 20264, for a particular tab 20234 (of a series of guest tabs 20235, 20237, 20239 and 20235) where a popup screen for a selected menu item is displayed. There is provided an image of the item 20216, the name of the menu item 20266, the price 20268, the ingredients 20270, an option to select condiments 20272, an option to vary cooking instructions 20274, a button to add to the order 20276 and a cancel button 20262.
[00439] Referring to Figure 20k, there is shown a variation of the closeup of Figure 20j, where guest 4 (20239) has provided information regarding allergies 20282 and dietary requirements 20284 which results in the ingredients 20286 being changed, and optionally the condiments 20288 may also be varied, as may the cooking instructions 20290.
[00440] Referring to Figure 201, once each customer has placed their order, there is shown a total screen 20292, which, for each guest, such as guest 20296 and guest 20304, there is shown an order 20294 including selected menu items 20298, 20399, 20300, 20301 and 20302, associated prices such as 20305, including sub totals 20307 and a total 20308, and the ability to delete items using cross 20306. The customer can also proceed to payment by clicking button 20311.
[00441] Referring to Figure 21a, 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 2100 and opening hours information 2101 and 2103, floor plan information 2102, menu information 2104, promotion information 2106 including reduced price promotions 2107, backfill promotions 2119 and follow on promotions 2111, pus booking fee information 2106, extended duration information 2108, concierge service item information 2110, allocation rules 2112, widget configuration rules 2134 and email configuration data 2135, all information is posted to the posting calendar 2114 which includes table allocation logic 2118 and transaction details 2120 and interacts with the booking widget 2136 which receives booking request 2138 from customer 1 to create a seating process 2121 which is then posted to the POS system within the volumetric framework, which is arranged to interact with the floor staff ordering app and databases 2124. The floor staff ordering app is in communication with the printer integration manager 2128 and a kitchen printer 2130, and a till 2132.
[00442] The email configurator 2135 communicates with the customer via emails 2146 which include the ability to edit bookings 2148 and cancel bookings 2150 an also pre-order 2152, which connect with the menu ordering app 2142 or the menu ordering widget 2144. Similarly, customer 2 (2154) may interact directly with kiosk 2156 which has a cloud connection to the calendar 2158. The operator/owner/manager 2131 may also have a cloud connection 2133 to the diary and dashboard reporting system.
[00443] Referring to Figures 22a-h, there is shown the setup screens of various types of promotions which can be configured to be offered to customers at various points during and after the booking process as a way to optimise resources and manage operations as well as other reasons related to a restaurant's unique strategy, by utilising one or multiple incentivised promotions.
[00444] Referring to Figure 22a, there is also shown a screenshot 2200 for an interface for entering backfill promotions. At pull down menu 2204 a restaurant is chosen. A backfill promotion set is displayed at 2206 and a promotion set is chosen at 2208. A new backfill promotion may be selected by button 2210 and previous backfill promotions are displayed at 2212, including a description 2214 and an enabled column 2216 which shows whether the promotion is enabled using tick 2218. The existing promotion may also be edited by clicking edit button 2220.
[00445] Referring to Figure 22b, there is shown a screenshot of a weekend backfill promotion data entry screen 2222 in accordance with an embodiment of the invention. At 2224 the operator may enter a name and at 2226 a description of the promotion. At 2228 the operator is provided with a timing option for when backfill promotions are to be displayed and at 2229 the operator can enter a number of hours before service at which the backfill can be added. At 2230 there are displayed options that determine when backfill promotions will stop being displayed, and at 2231 a percentage can be applied by the operator. The operator may then select whether pre-order and/or prepayment is mandatory at 2232 and 2234 respectively.
[00446] The operator can also select an incentive type at the drop-down menu 2236 and can select a price adjustment value type at 2238. In the example screen shown, as the discount type is percentage, at 2240 a percentage value may be entered by the operator. The operator may then decide which items/products to apply the discount to, and may enable the discount by checking the enabled box at 2244. The entire promotion information may be saved at any time by clicking the save button 2242.
[00447] Referring to Figure 22c, there is also shown a screenshot 2242 for an interface for entering reduced price promotions. At pull down menu 2246 a set of pre-set services (which may be a single service or an ongoing, repeating service) is chosen. Further, a menu set is selected at pull down menu 2248. Correspondingly, a reduced price promotion set is selected at 2250. The relevant reduced price promotion set is displayed at 2254. A new reduced price promotion may be entered by selecting button 2252 and the previous reduced price promotions, displayed at 2254, include a description 2256 and an enabled column 2258 which shows whether the promotion is enabled using tick (not labelled). The existing promotion may also be edited by clicking edit button (not labelled).
[00448] Referring to Figure 22d, there is shown a screenshot of a late lunch promotion data entry screen 2260 (an example of a reduced price promotion) in accordance with an embodiment of the invention. At 2264 the operator may enter a name and at 2266 a description of the promotion. At 2265 the operator is provided with a timing option for when promotion is to be made available (i.e. which service or time interval) and at 2266 the operator can enter which menus the promotion should be applied to.
[00449] The operator can also select an incentive type at the drop-down menu 2268 and can select a price adjustment value type at 2270. In the example screen shown, as the discount type is percentage, at 2272 a percentage value may be entered by the operator. The operator may then decide which items/products to apply the discount to at 2274, and may enable the discount by checking the enabled box at 2276. The entire promotion information may be saved at any time by clicking the save button 2278.
[00450] Referring to Figure 22e, there is also shown a screenshot 2280 for an interface for entering follow-on promotions. At pull down menu 2284 a set of pre set conditional promotions is chosen. The relevant follow-on promotion set is displayed at 2288. A new follow-on promotion may be entered by selecting button 2286 and the previous follow on promotions, displayed at 2288, include a description 2290 and an enabled column 2292 which shows whether the promotion is enabled using tick (not labelled). The existing promotion may also be edited by clicking edit button (not labelled).
[00451] Referring to Figure 22f, there is shown a screenshot of a pre-order promotion data entry screen 2294 in accordance with an embodiment of the invention. At 2298 the operator may enter a name and at 22100 a description of the promotion. At 22104 and 22106 the operator is provided with pre-order and deposit or pre-order and payment options, and at 22108 an offer expiry time can be entered by the operator. At 22110, 22112 and 22114 various conditions may be imposed on the customer, including a deposit condition, a join CRM condition and/or a social media post condition respectively.
[00452] The operator can also select an incentive type at the drop-down menu 22116 and can select an item at 22118. In the example screen shown, as the incentive type is an item, at 22120 and 22122 an item and quantity may be selected by the operator. The operator may enable the promotion by checking the enabled box at 22122. The entire promotion information may be saved at any time by clicking the save button 22124.
[00453] Referring to Figures 22g and 22h, there is shown a screenshot 22126 (spread across two Figures) of an interface to post promotions to a calendar in accordance with an embodiment of the invention. At 22130, a meal period is selected, and at 22132 the operator selects an allocation constraint set. The operator then selects a date range using pull down menus 22134 and 22136. There is subsequently displayed at 22138 generally opening-times related constraints and menu-related constraints as part of a calendar which displays all days of the week (such as 22142). The operator can enable each day by clicking check box 22140. If the check box is selected, such as 22144, the user may select an opening time set 22146, a menu set 22148, a promotional menu set 22150, and a reduced price promotions set 22152. Similarly, the user may follow the same format for backfill promotions 22154 including for each day, such as day 22156, enabling promotions for the day by selecting check box 22158, selecting a backfill promotions set 22160, a follow-on promotions set 22162 and referring to Figure 22h, a specific flor plan may be enabled by using check box 22164 and then selected using pull down menu 22166. Lastly, a specific set of allocation rules 22168 for a day such as 22170 may be enabled using check box 22172, with the specific set of rules such as 22174 being selectable from a pull down menu. The final combination of service sets, floor plan sets, allocation rule sets and promotion sets for each particular day can be posted to the calendar using post button 22176.
[00454] Referring finally to Figures 23a-23g, 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.
[00455] 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 (The present by a user in the allocation of a space, furniture, application) 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 including management of a booking and service delivery 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)
[00456] Referring to now FIGs. 23a to 23e, 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.
[00457] The following references serve as a summary of the information referred to within the embodiment detailed by Figures 23a-23g
Information and set-up for embodiments described herein
[00458] Restaurant Set-up Rules (2378): 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.
[00459] 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.
[00460] 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.
[00461] In other words, the term "relativity" refers to quantifiable attributes of furniture/equipment.
[00462] 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.
[00463] 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.
[00464] 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.
[00465] 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.
[00466] 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 (2378) are "space", "tables" and "tables, table combinations and shadow tables" described further below: Space
[00467] 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
[00468] 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.
[00469] 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
[00470] 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.
[00471] 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.
[00472] 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.
[00473] 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
[00474] The restaurant set-up rules shown at (2378) 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 (2378) 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.
[00475] 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
[00476] 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).
[00477] 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.
[00478] 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.
[00479] 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.
[00480] 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.
[00481] 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.
[00482] 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.
[00483] Menus (2380): 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 (2380).
Channel Configurability, Differentiation and Identification
[00484] 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
[00485] 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
[00486] 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
[00487] 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
[00488] 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.
[00489] 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.
[00490] 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
[00491] Dynamic Pricing and Dynamic Product and Service Promotional Offers (2382): 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.
[00492] 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 (2382) and include the differentiation of products.
[00493] 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
[00494] 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
[00495] 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.
[00496] 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
[00497] 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.
[00498] 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
[00499] Special Events Scheduled by Venue (2384): 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 (2384).
[00500] 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
[00501] CRM (2386): 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.
[00502] 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.
[00503] 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 (2386). Embodiments and aspects of this application are supported by, and with further details provided within all the additional related patent applications:
[00504] External Websites (2388): 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 (2388).
[00505] Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications.
Forecasting and Predictive Model (2390): 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.
[00506] 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 (2390). 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
[00507] Suppliers (2392): Orders; Deliveries; Constraints, details etc. (2392) 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.
[00508] Database of Booking Requests (2394): 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.
[00509] 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., (2394) Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications.
[00510] Optimisation Quantitative and Qualitative Strategic Rules and Outcomes (2396): 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).
[00511] 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 (2396). 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
[00512] Resource Parameters (2398): 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. (2398). 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
[00513] Reporting (2331): Performance analysis; Customer satisfaction; Deliverables; Labour Analysis; Actual v. Predicted etc. (2331) 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
[00514] Database Historical Information (2333): 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 (2333) 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
[00515] External Websites (2335): 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.
[00516] Printed Operational In-Service Run Sheets (2337): 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.
[00517] Operational Requirements and Planning (2339): 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. (2339). 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
[00518] Point of Sale Integration (2341): 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.
[00519] 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 (2341) 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
[00520] 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.
[00521] 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
[00522] Stock Control, Ordering and Purchasing (2343): 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
[00523] Home Delivery and Takeaway Integrations for Production and Time Scheduling (2345): 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.
[00524] Payment Rules (2347): 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. (2347) Embodiments and aspects of this application are supported by, and with further details provided within the additional related patent applications.
[00525] Artificial Intelligence (2351): 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. (2351) 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
[00526] Alternate Payment Systems (2353): 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.
[00527] Referring to FIGs. 23a to 23e, the following references are provided as a summary of one embodiment of the information referred to within the flow chart as "Claimed Invention" 2376, "Intuitive booking allocation super highway" (2397) and booking allocation information 23026, utilising the information and constraints identified and developed la to 1v above:
[00528] Processes, methods and algorithms within the current invention
[00529] User, in one embodiment (2355)
[00530] Various Configurable Access Channels, such that the offers, products services etc., can be completely different by channel (2357)
[00531] 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. (2359)
[00532] 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. (2361)
[00533] 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. (2363)
[00534] 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. (2365)
[00535] Payment/Deposit Confirmation (2367)
[00536] Butler Service: Ordering of 3rd Party Services/Products, the changing of the order of service, the introduction of items not traditionally offered by restaurants. (2371)
[00537] 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) (2369)
[00538] 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. (2373)
[00539] 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. (2375)
[00540] Strategy-Related Booking Optimisation: An ambience re-allocation: if restaurant is not expected to fill up or other parameters apply. (2377)
[00541] 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. (2379)
[00542] 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. (2381)
[00543] 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 (2383)
[00544] 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. (2385)
[00545] 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. (2387)
[00546] Autonomous Restaurant and Complete Integration: Fully integrated information system including table and position sensors. (2389)
[00547] 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. (2391)
[00548] Payments: Fully integrated with links to original booking including part payments by table, customer and position number. (2393)
[00549] 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 (2395). 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.
[00550] Referring to FIGs. 23f to 23g, the following references are provided as a summary of the information referred to within the flow chart as "Prior Art" 2323, "Reactive Allocation" 23030 with booking allocation information 23032:
[00551] Prior Art (2323)
[00552] User (23000)
[00553] Access Channels (23002)
[00554] User/User Interfaces: Restaurant Booking Widget, Booking Form. (23004)
[00555] User requirements used in the Booking Allocation: (Prior Art) Date, time, meal period, pax (23006)
[00556] 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 (23008).
[00557] Payment/Deposit Confirmation (23010)
[00558] 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. (23012)
[00559] Dashboard: Static Floor Plan (23014)
[00560] Payments (23016)
[00561] Referring to FIG. 23f and FIG. 23g, the following references are provided as a summary of the information referred to within the flow chart as "Prior Art" 2323, "Booking Allocation Information" 23032:
[00562] 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 (23020)
[00563] Promotional Offers: Discount by time interval (23022)
[00564] Database: List of unused tables and table combinations (23024)
[00565] It will be understood that the description with regard to FIG. 23a to FIG. 23e 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. 23a to FIG. 23e 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. 23a to FIG. 23e 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.
[00566] It will be understood that the description with regard to FIGs. 23a to 23e 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 23a to 23e and the comparison to a prior art system shown in FIG. 23f and 23g 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.
[00567] 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.
[00568] The first embodiment referred to as the First Algorithm is termed the "Strategic Capacity Control" algorithm, module 2363, 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.
[00569] The second embodiment referred to as the Second Algorithm is termed the "Optimisation of Space Outcomes" module 2365, 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.
[00570] The third embodiment referred to as the Third Algorithm is termed the "Time Related Optimisation" algorithm, module 2369, 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.
[00571] The fourth embodiment referred to as the Fourth Algorithm is termed the "Event Related Optimisation" algorithm, module, 2373, 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.
[00572] The fifth embodiment referred to as the Fifth Algorithm is termed the "Full Capacity Optimisation", module, 2375, 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.
[00573] The sixth embodiment referred to as the Sixth Algorithm is termed the "Strategy and Ambiance Optimisation", module 2377, 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.
[00574] The seventh embodiment referred to as the Seventh Algorithm is termed the "Third Party Information Optimisation", module 2379 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.
[00575] The eighth embodiment referred to as the Eighth Algorithm is termed the "Pre-Service Quantitative and Qualitative" algorithm, module 2381. 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.
[00576] 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 2385. 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.
[00577] 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.
[00578] 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".
[00579] Referring to Annexures 1 to 11 the following references are provided as a summary of the measures and metrics detailed within the Annexures:
[00580] 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.
[00581] 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.
[00582] 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.
[00583] 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.
[00584] 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.
[00585] 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.
[00586] 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.
[00587] 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.
[00588] 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.
[00589] 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.
[00590] 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.
[00591] Those skilled in the art can appreciate that the structure of the claimed invention, and more specifically with the measures and metrics referred to within the annexures, that these measures and metrics can easily be converted or adopted within the other industries referred to and to which this claimed invention can be applied to.
[00592] to Figure 24a, there is shown a flow chart depicting the process flow of a personalised booking form in accordance with an embodiment of the invention. At step 2400, the operator (staff member) inputs one or more identifiers, and then selects an existing customer at step 2402. The booking retrieves CRM information at step 2404 and subsequently interacts with a booking form personalisation facility 2406. Subsequently, the operator (staff member) is presented with a number of personalised options for the customer, which may include specific promotions 2408, specific constraints 2410, specific fields being shown or hidden 2412, or a combination of two or more of the previously mentioned options as shown at 2414, 2416, 2418 and 2420. The operator (staff member) may then select the appropriate options and input the appropriate information at step 2422 and the booking is submitted at step 2424.
[00593] Referring to Figure 24b, there is shown a diagrammatic representation of a dashboard interface and a client database in accordance with an embodiment of the invention. A dashboard 2426 interacts with a client database 2434 (including a CRM 2436) via a booking form request 2432 and receives information in the form of CRM information 2454 via the booking form customer personalisation facility 2456.
[00594] The dashboard 2426 displays a booking form 2428 on an interface (not shown), the booking form utilising operator input identifier information 2430 which is sent via booking form request 2432 to the client database 2434. The CRM 2436 receives the data and identifies the relevant customer'A' 2438 including customer ID 2440, booking history 2442, membership level 2444, customer data 2446 and customer behaviour 2448, and utilising the information to identify potential promotions 2450 and booking constraints 2452. The CRM information is sent to the dashboard via 2454 and 2460 to provide, on the dashboard, specific promotions 2458, specific constraints 2460, specific input fields 2462, such that the staff member (operator) can complete and submit the booking request 2464.
[00595] Referring to Figure 24c there is shown a screenshot of a widget channel setup screen including a booking form channel in accordance with an embodiment of the invention. At screen 2466 there is shown a restaurant booking widget configurator screen. A staff member may select a restaurant by using drop down menu 2472 and select a seating period/service period type at drop down menu 2474. This causes the relevant controls for the restaurant/service period configuration to be displayed, including the category of identifiers as shown at 2476 generally, including columns having toggle switches for various parameters/constraints as generally indicated at 2470. Within the identifier's category, there is shown a membership number sub-category 2481 and an edit booking sub-category 2482, including toggle switches for a booking form column 2478, including toggle switches such as 2480, 2486 and 2488. Each toggle switch is relevant to the turning "on or off" of a particular constraint, such as constraints 2487 or constraint 2489 (for example).
[00596] Referring to Figure 25a, there is shown a flowchart depicting a process flow for an urgent email module arranged to operate within a widget or app in accordance with an embodiment of the invention. The widget, as shown in the figure, is displayed on the restaurant website 2500, where a user can access the widget by clicking on an "urgent messaging form" link 2502 to open the urgent messaging form widget 2504, which causes several fields for the input of information 2506 to be displayed. The user enters information into the fields at 2508 and clicks the send button at 2510. The email module generates an email using the user's input information at 2512, which is delivered to the restaurant's inbox (2514) at step 2516. Once the email is received at the restaurant's inbox, an email scraper 2518 scrapes the email at step 2520 and utilises the inputs to direct the message at step 2524. The message may be directed to a restaurant's dashboard for a particular service (various dashboards shown at 2526, 2554 and 2552) and are generally provided to the urgent messages module 2528 where urgent message cards are created at step 2530. If the email relates to a current service, as determined at step 2544, the relevant operators receive messages 2550 at their mobile devices 2548. If the message is not relevant to the current service, no message is sent, as shown by the 'end' at 2546.
[00597] Returning to the dashboard 2526, once the urgent message 2530 is displayed, an operator can click on the urgent message at step 2532 and the restaurant's inbox is opened at step 2534, at which time a reply can be sent at step 2558, including an option to send to a mobile device 2548 and an option to send reply notifications 2542 utilising a notifications module 2536.
[00598] Contemporaneously, a notifications module 2536 can also create and display a notification for a specific service at step 2538 and can create and display a notification for all services at step 2540. The notifications module 2536 may also receive urgent message cards to be converted into notifications 2340 from other services such as 2554.
[00599] The urgent messaging form provides a facility for booking requestors to open a direct communication channel with the operator, for rare situations where the booking requestor requires some type of personal contact. While the contact is ultimately directly sent to the operator, the content of the message is still filtered and packaged in a manner that allows the operator to deal with any query quickly and correctly. As such, the urgent messaging form is not simply a surrogate email or chat client, but rather, provides a level of integration with the autonomous booking system that avoids the possibility of the booking requestor and the operator reverting to an essentially "manual" form of communication.
[00600] Referring to Figure 25b, there is shown a partial screenshot of a pop up window or frame within a widget or app in accordance with an embodiment of the invention. When the booking requestor is navigating the website 2560 or app (not shown), they are presented with two options, namely an online booking form button 2562 and an urgent messaging form button 2564. If the booking requestor clicks on button 2564, they are taken to a pop up screen as shown on the right hand side of Figure 25b. The form 2566 includes fields for name 2568, email address 2570, date 2572, service period 2574, a subject line or topic 2576, the number of guests 2577 and a message 2578. The user can send the message by clicking send button 2580.
[00601] Referring to Figure 25c, there is shown a screenshot of a dashboard in accordance with an embodiment of the invention, incorporating a frame within the dashboard in accordance with an embodiment of the invention. When an urgent message is received, an icon appears in area 2582 and urgent messages (such as those indicated by arrows 2586 and 2588) appear in frame 2584.
[00602] Referring to Figure 25d, there is shown a partial screenshot of a further pop up window or frame within a widget or app in accordance with an embodiment of the invention. Figure 25d is a close up screenshot of frame 2584 of Figure 25c. As can be seen in pop up 2590, the pop up can be resized by using control button 2592 and displays messages such as 2594 and 2596.
[00603] Referring to Figure 25e, there is shown a partial screenshot of a further pop up window or frame within a widget or app in accordance with an embodiment of the invention. When an operator clicks on a message such as message 2594 or 2596 of Figure 25d, they are shown window 2598, which resembles a traditional message screen of an email program.
[00604] Referring to Figure 26a, there is shown a screenshot of a widget or app in accordance with an embodiment of the invention. A booking requestor, if they wish to update or cancel a booking, is directed to screen 2600, which includes a summary of the booking details at 2602, and the name and reference of the booking requestor at 2604. The requestor may change their booking details by selecting tab 2606, change their contact details by selecting tab 2608, add butler service items by selecting tab 2610, invite guests by selecting invite guests tab 2612, pre-order by selecting tab 2614, send an urgent message by selecting tab 2616 and cancel a booking by selecting tab 2618.
[00605] Referring to Figure 26b, there is shown a screenshot of a widget or app in accordance with an embodiment of the invention where the booking requestor has selected the change booking details tab 2606 of Figure 26a. The user is shown screen 2620, which is shown in close up on the right hand side of Figure 26b. The booking details are shown generally at area 2622.
[00606] Referring to Figure 26c, there is shown a screenshot of a widget or app in accordance with an embodiment of the invention. If the booking requestor changes some booking details in form 2626 and the new booking cannot be accommodated, the user is taken to dialog box 2628, which is shown in close up on the right hand side of Figure 26c. The user may elect to join the waitlist by selecting button 2630, revert to their original booking by selecting button 2632 or close the dialog box by selecting button 2634.
[00607] Referring to Figure 26d, there is shown a screenshot of a widget or app in accordance with an embodiment of the invention. If the booking requestor changes some booking details in form 2636 and the new booking is possible, the user is taken to dialog box 2638, which is shown in close up on the right hand side of Figure 26d. The new booking details are shown in area 2640 and the user can close the dialog box by selecting button 2642.
Advantages
[00608] The embodiment and broader invention described herein provides a number of advantages.
[00609] Firstly, the embodiment provides a fundamentally different way to manage instances of apps and widgets. The apps and widgets are generated with different options, different process flows etc., by a non-expert operator who may have no programming experience but is capable of creating customised instances of widgets and apps for different channels.
[00610] Furthermore, the embodiment also provides additional advantages as the options available to modify the app or widget may also themselves be modified to provide maximum flexibility. For example, in the example of a restaurant, third party requests may be input by the operator and then turned on or off as required by the operator. As will be appreciated, the computer system in the present invention provides for a greater level of control over every instance and/or channel that utilises an app or widget.
[00611] The embodiment also provides an advantage over known app or widget deployment systems, in that the embodiment can be customised in an almost infinite number of manners, as may be required for any particular instance.
[00612] For example, for avenue utilising the invention, the venue has the ability to offer special deals or propose alternate requests to a sub-set of customers (e.g. members of a particular organisation). Therefore, the embodiment provides a fundamental and crucial advantage over the prior art by enabling a specific instance of the app and/or widget that allows certain requests to be accommodated by certain customers, but not by others, in a manner that does not require any "manual" intervention by venue staff or management.
[00613] From another perspective, the embodiment described herein with regard to booking a table at a restaurant provides a user interface that permits a sophisticated and directed interaction between the embodiment and a booking engine, acting as an intelligent agent for the venue, and the booking requestor, to accommodate a booking request in a manner that maximises the interests of the venue and the booking requestor. This advantage is achieved, in part, through the use of an interface that is dynamically adaptive by, in response to venue constraint information and requestor constraint information, and also the ability by the operator to control the information and options available to the end user, to generate multiple potential solutions for different channels utilising a different user interface and different prompts to provide different menus, time durations, seats, tables, pricing levels based on different times and durations using dynamic pricing models, different rooms, and packages.
[00614] In more detail, and in the context of the embodiment described herein, the use of an algorithm to allocate a booking allows a venue to be flexible in the manner in which to allocate the bookings, and such an algorithm works synergistically with the embodiment, as the embodiment provides the ability to generate and deploy customised apps and widgets which are able to flexibly provide options and different interfaces to different groups of users, depending on the requirements imposed by the operator.
[00615] In one particular embodiment, the interface provides an integrated portal via which a booking requestor may personalise their experience within a venue through the concurrent booking of products and services not directly offered by the venue, but which are allowed by the venue. For example, the provision of a bucket of champagne next to table to be opened on arrival, the provision of flowers and a personalised card, a magician to entertain as part of the experience, a specialty cake, and/or a box of chocolates.
[00616] The embodiment is capable of offering different menus at different booking times within a service period and for different durations with the ability to charge a premium for bookings that wish to be allocated to a peak period or to stay longer than the allocated time for different channels.
[00617] Embodiments of the invention overcome a limitation inherent in the prior art, which does not allow an operator to define and deploy different versions of different apps and widgets, each app and widget being customised different "channels".
[00618] Moreover, the system advantageously allows the operator to maintain control over the app and widget, and can, in real time, enable or disable certain features in each channel through which the widget or app is deployed.
[00619] 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
[00620] 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.
[00621] 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.
[00622] 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.
[00623] 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.
[00624] 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.
[00625] 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).
[00626] 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.
[00627] 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.
[00628] 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 per 0.18 square meters person * Minimum table top size (for two) 600mm by 600mm * Table Top Fine Dining (minimum) 750mm by 750mm * Table Top Full-Service Restaurant Dining 700mm by 750mm * 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 Service 1.70 to 1.90 square 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 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 " 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 (49)
1. A computer-enabled method for the allocation of a booking, including a booking interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a customised booking interface on the remote device, comprising the steps of, a booking requestor causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of mandatory and optional input requirements, the mandatory and optional input requirements being utilised to provide instructions to render a customised booking interface having a customised set of input requirements on the remote device, whereby, upon the booking requestor providing at least a portion of the mandatory and optional input requirements via the customised booking interface, the input requirements are utilised by the server to perform an electronic search of a constraint database containing a multi-variate tree of further constraints to identify one or more further input requirements required to complete the booking, the further constraints being utilised to provide further instructions to further customise the booking interface, whereby the process of identifying and providing input requirements is iterated until all mandatory input requirements have been completed by the booking requestor and transmitted to the server, whereby the input information is provided to a dynamic booking module arranged to allocate bookings, whereby the booking module utilises the constraint information to attempt to allocate the booking request and if successful, generates booking allocation information, and upon receiving the relevant booking allocation information, the booking interface provides the booking allocation information to the booking requestor.
2. A computer-enabled method in accordance with claim 1, whereby the booking allocation comprises the further step of determining all previously allocated booking requests, creating a virtual pool of allocated booking requests, the pool including the request to be allocated, sorting all booking requests into an allocation order, and re-allocating all bookings from the pool of booking requests utilising an allocation algorithm, whereby if all booking requests are allocated, the booking interface confirms the received booking request.
3. A method in accordance with claim 1 or 2, comprising the further step of the booking module utilising the confirmed booking information to generate an optimised allocation instruction set, the instruction set being capable of being displayed on an interface accessible by one or more operators associated with the booking.
4. A method in accordance with claim 3, whereby the optimised allocation instruction set is rendered as a graphical representation of a floor plan of a venue.
5. A method in accordance with any one of claims 1 to 4, whereby the identifier includes sub-identifiers.
6. A method in accordance with claim 5, whereby the sub-identifiers include a unique code associated with a specific instance of the user interface.
7. A method in accordance with claim 5 or 6, whereby the sub-identifiers include information identifying the booking requestor.
8. A method in accordance with any one of claims 5 to 7, whereby the sub identifiers include information identifying the geographical location of the remote device.
9. A method in accordance with any one of claims 5 to 8, whereby the sub identifiers include information identifying a preferred geographic area associated with the booking requestor.
10. A method in accordance with any one of the preceding claims, whereby the booking interface is represented by a graphic representing a volumetric framework.
11. A method in accordance with any one of the preceding claims, whereby the constraints include at least one of an availability by one of a menu and time selected by the booking requestor.
12. A method in accordance with any one of the preceding claims, whereby the constraints include an availability by a package selected by the booking requestor.
13. A method in accordance with any one of the preceding claims, whereby the constraints include an availability by a number of guests selected by the booking requestor.
14. A method in accordance with claim 13, whereby the constraint includes an availability by an odd number of guests selected by the booking requestor.
15. A method in accordance with any one of the preceding claims, whereby the constraints include an availability by a presence of children as selected by the booking requestor.
16. A method in accordance with any one of the preceding claims, whereby the constraints include an availability by an occasion selected by the booking requestor.
17. A method in accordance with any one of the preceding claims, whereby the constraints include an availability by a specific table selected by the booking requestor.
18. A method in accordance with any one of the preceding claims, whereby the constraints include an availability by specific class selected by the booking requestor.
19. A method in accordance with any one of the preceding claims, whereby the constraints include an availability by a promotion selected by the booking requestor.
20. A method in accordance with any one of the preceding claims, whereby the constraints include by a booking duration selected by the booking requestor.
21. A method in accordance with any one of the preceding claims, whereby the constraints include additional items arranged to supplement or enhance a dining experience that can be supplied by a venue.
22. A method in accordance with any one of the preceding claims, whereby the constraints include additional items arranged to supplement or enhance a dining experience that can be supplied by a third-party supplier to the venue.
23. A method in accordance with any one of the preceding claims, whereby the constraints include additional items arranged to supplement or enhance the dining experience that a venue would allow a booking requestor to bring into the venue
24. A method in accordance with any one of the preceding claims, whereby the constraints include the provision of incentives for a booking requestor not to leave the booking process prior to the completion of the required mandatory information for the processing of the booking request.
25. A method in accordance with any one of the preceding claims, whereby the constraints include pre-determined promotions associated with one or more of a booking source, booking identifier, customer identifier, other identifier or sub identifier.
26. A method in accordance with any one of the preceding claims, comprising the further steps of determining if an additional payment or a pre-payment is required for at least one of the date, time, week, menu, number of guests, children, occasion, booking duration, promotion, and additional items selected by the booking requestor, communicating the requirement to the booking requestor and processing the payment of any pre-payment amount via a payment system.
27. A method in accordance with any one of the preceding claims, comprising the further step of providing a third-party interface arranged to identify third parties authorised by the booking requestor to access information regarding at least one of the booking request and the booking.
28. A method in accordance with any one of the preceding claims, comprising the further step of providing a third-party interface arranged to identify third parties authorised by the booking requestor to pre-order and pre-pay for selected items as part of the booking.
29. A computer enabled method in accordance with any one of the preceding claims whereby the system includes a booking requestor interface for a booking requestor associated with a venue to input the plurality of multi-variate tree of inter-related constraints and offers.
30. A computer enabled method in accordance with any one of the preceding claims whereby the system includes a booking requestor interface for a booking requestor associated with a venue can input the plurality of decision tree, inter related payment or part payment constraints.
31. A computer enabled method in accordance with any one of the preceding claims further including the step of accessing an artificial intelligence module arranged to receive the booking request information and review one or more of the plurality of constraints to determine whether variation of the one or more constraints to allow a variation to the one or more input requirements and constraints is more likely to result in acceptance of the booking request.
32. A computer enabled method in accordance with claim 31, comprising the further step of, if the booking requestor has not entered optional information and the optional information increases the probability of finalising and completing the booking request, the artificial intelligence module is arranged to offer an incentive to the booking requestor to provide optional information.
33. A computer enabled method in accordance with claim 31 or 32, comprising the further step of, if the one or more of the plurality of requested information is varied and the varied constraints result in achieving a desired outcome, the varied constraints are saved and are used for all subsequent booking requests from booking requestors with similar identifiers and/or sub-identifiers.
34. A computer enabled method in accordance with any one of claims 30 to 33, whereby the interface includes a request message whereby a response is required from the booking requestor before the interface allows the booking requestor to continue with the booking.
35. A computer enabled method in accordance with any one of claims 30 to 34, whereby the interface accesses a database, whereby information from the database is utilised to determine the structure of the interface.
36. A computer enabled method in accordance with any one of claims 30 to 33, whereby the booking requestor interface portions are selectable or variable by the booking requestor directly.
37. A computer enabled method in accordance with any one of the preceding claims, whereby the customised user interface is one of a graphical user interface or an audible/speech recognition user interface.
38. A computer enabled method in accordance with any one of the preceding claims, further comprising the step of providing a communications channel, whereby the communications channel is arranged to relay a message from the booking requestor to an operator associated with the venue.
39. A computer enabled method in accordance with claim 38, whereby the communications channel is provided via an input form integrated into the widget, the input form including at least one field arranged to identify at least one aspect of the information contained in the message.
40. A computer enabled method in accordance with claim 38 or 39, whereby the message, upon receipt, is processed by an urgent message module, whereby the urgent message module formats the message into an appropriate format for display to the operator associated with the venue.
41. A computer enabled method in accordance with any one of claims 38 to 40, comprising the further step of displaying the message on a dashboard viewable by the operator.
42. A computer enabled method in accordance with any one of claims 40 to 41, whereby the urgent message module is arranged to, upon receipt of a message, send a notification to one or more electronic communications devices associated with one or more operators.
43. A computer-enabled method for the provision of a communications channel arranged to interact with a booking requestor to effect the instructions of the booking requestor via a computing system, the method including the steps of utilising a booking requestor interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a booking requestor-specific interface on the remote device, comprising the steps of, a booking requestor causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of input mandatory and optional requirements and offers, the input mandatory and optional requirements and offers being utilised to provide a customised booking requestor interface to the remote device, including the provision of offers associated with the identifier; whereby, upon the booking requestor providing at least a portion of the input mandatory and optional requirements via the customised interface, the input requirements are utilised by the server to provide offers and search through the multi-variate tree of inter-related further constraints, the multi-variate tree being utilised to determine one or more further input requests displayed on the booking requestor interface associated with the remote device, whereby the process of providing input requirements and traversing the multi-variate tree is iterated until at least all mandatory input requirements have been completed; whereby when all requested input information and additional optional information is captured, such that all input information is in compliance with at least the mandatory information required by the server to proceed, the input information is transferred to a processing module; whereby, the processing module undertakes a process required to effect the instructions of the booking requestor.
44. A computer-enabled method including a booking requestor interface accessible via a remote device, the remote device being in communication with a server, the method being arranged to generate a booking requestor-specific interface on the remote device, comprising the steps of:
a booking requestor causing the remote device to communicate with the server, the remote device providing to the server an identifier, the identifier being utilised by the server to identify, in a database in communication with the server, one or more of a plurality of pre-defined selectable constraints that, upon selection, generate a plurality of mandatory and optional input requirements, the mandatory and optional input requirements being utilised to provide instructions to render a customised booking requestor interface to the remote device, the customised booking requestor interface including a layout and information unique to the identifier;
whereby, upon the booking requestor providing at least a portion of the mandatory and optional input requirements via the customised interface, the input requirements are utilised by the server to perform an electronic search of a constraint database containing a multi-variate tree of inter-related further constraints, the multi-variate tree being utilised to determine one or more further input requirements which are utilised to provide instructions to render a further customised booking requestor interface to the remote device, whereby the process of providing input requirements and traversing the multi-variate tree is iterated until all mandatory input requirements have been completed;
whereby when all requested input information and additional optional information is inputted by the booking requestor, the input information is transferred to a processing module;
whereby, the processing module, upon performing the relevant processing steps, confirms processing and provides relevant information to the booking requestor interface.
45. A computer enabled method in accordance with claim 44, whereby the instruction includes one or a combination of a restaurant booking, a service provider booking, a home delivery service, a shopping/ecommerce service, an airline, a train service, a car rental service, a hotel, accommodation, travel services, cruise services, gyms, hair and beauty services, libraries, workspaces and a communication process where there is a requirement to book a service or purchase a product, or any other services that require the booking of an appointment, including any composite or combination service.
46. A computer enabled method in accordance with any one of the preceding claims, comprising the further step of providing an email send an email to an email address associated with a booking requestor, the email including data arranged to allow the booing requestor to utilise the data to access the booking system such that the booking requestor may access past or current bookings and edit past or current bookings, whereby information input by the booking requestor is captured.
47. A computer enabled method in accordance with claim 46, further comprising an urgent message portal accessible via the email message.
48. A computer enabled method in accordance with claim 47, whereby the data is utilised to render a graphical user interface.
49. A computer enabled method in accordance with any one of claims 46 to 48, further comprising the step of providing a volumetric space/time framework.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AU2021201205A AU2021201205A1 (en) | 2019-04-29 | 2021-02-24 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service |
Applications Claiming Priority (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AU2019901431A AU2019901431A0 (en) | 2019-04-29 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service | |
| AU2019901431 | 2019-04-29 | ||
| AU2019902681A AU2019902681A0 (en) | 2019-07-27 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service | |
| AU2019902681 | 2019-07-27 | ||
| AU2019903510 | 2019-09-20 | ||
| AU2019903510A AU2019903510A0 (en) | 2019-09-20 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service | |
| AU2020200607A AU2020200607A1 (en) | 2019-04-29 | 2020-01-29 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service |
| AU2021201205A AU2021201205A1 (en) | 2019-04-29 | 2021-02-24 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2020200607A Division AU2020200607A1 (en) | 2019-04-29 | 2020-01-29 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| AU2021201205A1 true AU2021201205A1 (en) | 2021-03-11 |
Family
ID=73028673
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2020200607A Abandoned AU2020200607A1 (en) | 2019-04-29 | 2020-01-29 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service |
| AU2021201205A Abandoned AU2021201205A1 (en) | 2019-04-29 | 2021-02-24 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2020200607A Abandoned AU2020200607A1 (en) | 2019-04-29 | 2020-01-29 | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service |
Country Status (2)
| Country | Link |
|---|---|
| AU (2) | AU2020200607A1 (en) |
| WO (1) | WO2020220067A1 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2018202759A1 (en) | 2017-10-31 | 2019-05-16 | Grand Performance Online Pty Limited | A system, method and computer program for optimising and allocating resources in a space for defined periods of time |
| US20210304142A1 (en) * | 2020-03-31 | 2021-09-30 | Atlassian Pty Ltd. | End-user feedback reporting framework for collaborative software development environments |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170220957A1 (en) * | 2016-02-01 | 2017-08-03 | Flo, LLC. | Restaurant reservation and table management system and method |
| WO2018217165A2 (en) * | 2017-05-25 | 2018-11-29 | Areco International Pte. Ltd. | System and method for implementing a centralized customizable operating solution |
| WO2019084605A1 (en) * | 2017-10-31 | 2019-05-09 | Grand Performance Online Pty Ltd | Autonomous and integrated system, method and computer program for dynamic optimisation and allocation of resources for defined spaces and time periods |
| JP7072068B2 (en) * | 2017-12-29 | 2022-05-19 | ブロック， インコーポレイテッド | Application programming interface for structuring distributed systems |
-
2020
- 2020-01-29 AU AU2020200607A patent/AU2020200607A1/en not_active Abandoned
- 2020-04-28 WO PCT/AU2020/050407 patent/WO2020220067A1/en active Application Filing
-
2021
- 2021-02-24 AU AU2021201205A patent/AU2021201205A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| AU2020200607A1 (en) | 2020-11-19 |
| WO2020220067A1 (en) | 2020-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2019203498A1 (en) | A system, method and computer program for optimising and allocating tables in a space | |
| US20220222591A1 (en) | A computer-enabled method, system and computer program for providing an intuitive user interface arranged to create a dynamic floor plan utilisable by an allocation algorithm to perform the task of allocating a space, furniture, equipment or service | |
| AU2024202810A1 (en) | Autonomous and integrated system, method and computer program for dynamic optimisation and allocation of resources for defined spaces and time periods | |
| AU2021201199A1 (en) | A computer-enabled method, system and computer program for providing an intuitive user interface arranged to create a dynamic product list integrable into a service provision process to perform the task of delivering a complex service and managing an associated transaction | |
| AU2021201929A1 (en) | A computer-enabled method, system and computer 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 | |
| AU2024202217A1 (en) | A computer-enabled method, system and computer program for dynamically altering constraints utilised in the management of a space, furniture, equipment or service | |
| AU2021201205A1 (en) | A computer-enabled method system and computer program for generating a dynamic user interface for use by a user in the allocation of a space, furniture, equipment or service | |
| AU2022200093A1 (en) | An autonomous, integrated computer-enabled method, system, and computer program utilising an artificial intelligence engine for dynamic allocation and optimisation of space, furniture, equipment and/or services | |
| US20220188709A1 (en) | Computer-enabled method, system and computer program for dynamically altering constraints utilised in the management of a space, furniture, equipment or service | |
| AU2021202226A1 (en) | A computer-enabled method, system and computer program for providing an intuitive user interface arranged to create a dynamic floor plan utilisable by an allocation algorithm to perform the task of managing a function or event | |
| AU2021201930A1 (en) | A computer-enabled method, system and computer program for providing an intuitive user interface arranged to create a dynamic floor plan utilisable by an allocation algorithm to perform the task of organising and operating a provision of a service | |
| AU2021201972A1 (en) | 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 | |
| AU2021202258A1 (en) | A computer-enabled method, system and computer program for autonomously allocating and managing a space, furniture, equipment and/or a service via an electronic device | |
| AU2021202093A1 (en) | 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 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MK5 | Application lapsed section 142(2)(e) - patent request and compl. specification not accepted |