GB2603509A

GB2603509A - Retailer process management system

Info

Publication number: GB2603509A
Application number: GB2101647.2A
Authority: GB
Inventors: Al-Hamoud Ihsan
Original assignee: Ordergo Ltd
Current assignee: Ordergo Ltd
Priority date: 2021-02-05
Filing date: 2021-02-05
Publication date: 2022-08-10
Also published as: GB202101647D0

Abstract

A Retailer Process Management System RPMS and method of operating an RPMS. The RPMS includes at least a table occupancy module and a booking module. The table occupancy module receives one or more images of a table 202, wherein the images are received from one or more image capturing apparatus. The received images are analysed to determine a predicted occupancy state for the table 203. A booking occupancy state is determined for the table from the booking module and an actual occupancy state is determined for the table based on at least the predicted occupancy state and the booking occupancy state 208,209,212,213. The method may also include a machine learning module which analyses the received images to determine the predicted occupancy state. If the actual occupancy differs from a booking occupancy state, the booking may be modified, and a notification may be sent to a user of the RPMS 210.

Description

Retailer Process Management System

Field of the Invention

The present invention relates to an improved Retailer Process Management System (RPMS) and, in particular, to the use of machine learning to determine occupancy of tables in a restaurant.

Background to the Invention

Traditionally, restaurants used a Point of Sale (POS) system which has many drawbacks and disadvantages, such as requiring manual input and often requiring paper printouts of orders which is inefficient and may lead to orders being delayed or lost.

Furthermore, a restaurant typically takes bookings for tables via a consumer entering the restaurant to make a booking, a consumer phoning the restaurant to make a table booking or a consumer can make an online table booking. The table bookings may be allocated for a set duration of time which may be longer than the consumer is actually at the restaurant meaning that the table is under-utilised and is inefficiently used. Also, if the restaurant is busy then staff may not notice a table is unoccupied which also prevents further consumers from booking or using the table.

Aspects of the present invention seeks to address, at least in part, one or more of the disadvantages and problems described above.

Summary of Invention

According to a first aspect of the present invention there is provided a method of operating a Retailer Process Management System, the Retailer Process Management System includes at least a Table Occupancy Module and a Booking Module, the method comprising: receiving at the Table Occupancy Module one or more images of a table, wherein the images are received from one or more image capturing apparatus; analysing the received one or more images; determining a predicted occupancy state for the table based on the analysis of the received one or more images; determining a booking occupancy state for the table from the Booking Module; and determining an actual occupancy state for the table based on at least the predicted occupancy state and the booking occupancy state.

The Retailer Process Management System may further comprise a Machine Learning Module and wherein the Machine Learning module may analyse the received one or more images to determine the predicted occupancy state.

If the determined predicted occupancy state is unoccupied and the booking occupancy state is occupied, the method may further comprise applying by the Table Occupancy Module one or more algorithms; and the step of determining the actual occupancy state for the table may be further based on the applied algorithms.

The one or more algorithms may include waiting a predetermined period of time before determining a further predicted occupancy state for the table based on an analysis of further images received from the one or more cameras; and if the further predicted occupancy state is unoccupied the actual occupancy state may be determined as unoccupied.

The one or more algorithms may include identifying from the Booking Module any notification messages relevant to the table; and if the notification messages indicate 15 that the table is occupied then the actual occupancy state may be determined as occupied.

If the determined predicted occupancy state for the table is occupied and the booking occupancy state is unoccupied, the method may further comprise determining the actual occupancy state as occupied.

If the determined actual occupancy state of the table differs to the booking occupancy state in the Booking Module for the table then the method may further comprise modifying the Booking Module to set the table to the actual occupancy state.

The method may further comprise sending a notification of the modification to the Booking Module for the table to a user of the Retailer Process Management System.

The Booking Module may further maintain a waiting list of one or more consumers; and wherein if the actual occupancy state for the table is determined to be unoccupied the method may further comprise sending a notification to a consumer device of a consumer on the waiting list.

According to a second aspect of the present invention there is provided a Retailer Process Management System, comprising: at least a Table Occupancy Module and a Booking Module; at least one image capturing apparatus, wherein each image capturing apparatus has a line of sight to one of a plurality of tables; and wherein the Table Occupancy Module is configured to: determine a predicted occupancy state for the table based on the analysis of the received one or more images; determine a booking occupancy state for the table from the Booking Module; and determine an actual occupancy state for the table based on at least the predicted occupancy state and the booking occupancy state.

The Retailer Process Management System may further comprise a Machine Learning Module wherein the Machine Learning module may be configured to analyse the received one or more images to determine the predicted occupancy state.

If the determined predicted occupancy state is unoccupied and the booking 15 occupancy state is occupied, the Table Occupancy Module may be further configured to: apply one or more algorithms; and determine the actual occupancy state for the table further based on the applied algorithms.

The one or more algorithms may include waiting a predetermined period of time before determining a further predicted occupancy state for the table based on an analysis of further images received from the one or more cameras; and if the further predicted occupancy state is unoccupied the Table Occupancy Module may be further configured to determine the actual occupancy state as unoccupied.

The one or more algorithms may include identifying from the Booking Module any notification messages relevant to the table: and if the notification messages indicate 25 that the table is occupied then the Table Occupancy Module may be further configured to determine the actual occupancy state as occupied.

If the determined predicted occupancy state for the table is occupied and the booking occupancy state is unoccupied, the Table Occupancy Module may be further configured to determine the actual occupancy state as occupied.

If the determined actual occupancy state of the table differs to the booking occupancy state in the Booking Module for the table then the Table Occupancy Module may be further configured to modify the Booking Module to set the table to the actual occupancy state.

The Table Occupancy Module may be further configured to send a notification of the modification to the Booking Module for the table to a user of the Retailer Process 5 Management System.

The Booking Module may be further configured to maintain a waiting list of one or more consumers; and wherein if the actual occupancy state for the table is determined to be unoccupied the Booking Module may be further configured to send a notification to a consumer device of a consumer on the waiting list.

According to a third aspect of the present invention there is provided a computer program product comprising computer readable executable code to implement any of the features or aspects described hereinabove.

Drawings Embodiments of the present invention will now be described, by way of example only, and with reference to the accompanying drawings, in which: Figure 1 shows a block diagram of a Retailer Process Management System according to one or more embodiments of the present invention.

Figure 2 shows a flowchart according to one or more embodiments of the present invention.

Detailed Description

With reference to Figure 1, a Retailer Process Management System (RPMS) 101 is implemented on a cloud computing environment 102. The RPMS 101 may be connected to a data/communication network 103 via a communication link 104. The communication link 104 may be any suitable communication link 104 such as a wireless communication link, a wired communication link or any combination thereof.

The data/communication network 103 may be any suitable data/communication network, such as the internet, one or more wide area networks, and so on.

Any number of restaurants and/or takeaway outlets 104,105 may be registered with the RPMS 101 to utilise the functionality provided by one or more modules of the RPMS 101. The RPMS 101 may include any number of modules, such as a Booking Module (BM) 106, a Table Occupancy Module (TOM) 107, a Machine Learning Module (MLM) 108, a Marketing and Promotional Module (MPM) 109, a Product Search Module (PSM) 110, an Ordering Module (OM) 111, an Intelligent Reporting Module (IRM) 112, and an Administrator Module (AM) 113. As would be understood, the above mentioned list of modules for the RPMS 101 is not exhaustive and may further include any additional modules as required by the given restaurant. Each restaurant and/or takeaway outlet 104, 105 may have access to all of the modules of the RPMS 101 and/or may utilise one or more of the available modules of the RPMS 101 depending on the services offered and/or the requirements of each restaurant and/or takeaway outlet 104, 105.

In Figure 1, the various modules of the RPMS 101 are shown as being implemented on a cloud computing environment 102. However, as will be appreciated, the RPMS 101 may alternatively or additionally be implemented by one or more servers as required. Alternatively or additionally, the one or more modules may be distributed such that one or more modules may be implemented on one or more servers/computing devices 114 located locally at one or more of the restaurants and/or takeaway outlets 104, 105 either as a standalone module providing the functionality locally at the restaurant and/or takeaway outlet 104, 105, or as a backup module that is synchronised with the corresponding module of the RPMS 101 in case the connection with the RPMS 101 is unavailable, thereby enabling the module functionality to operate. For example, the TOM 107 and/or MLM 108 modules may be implemented by the RPMS 101 remote to the restaurant 104 or the TOM 107 and/or MLM 108 modules may be installed on a server/computing device 114 located at the restaurant 105 and are operatively connected to the RPMS 101 via one or more networks. Alternatively, each restaurant and/or takeaway outlet 104, may have the complete RPMS 101, along with the modules required by the restaurant and/or takeaway outlet 104, 105 implemented on one or more servers/computing devices 114 located at the restaurant and/or takeaway outlet 104, 105. Therefore, the RPMS is flexible and can be configured to be a remote system, a local system, or any combination thereof.

The modules of the RPMS 101 may provide the functionality for the restaurant and/or takeaway outlet or may be synchronised with, or able to modify, each restaurant and/or takeaway outlet's individual existing or third party systems. For example, the BM 106 may provide the table booking functionality for a restaurant 104 or the BM 106 may be synchronised with and/or be able to modify an existing booking system that is being used by the restaurant 104. The modules of the RPMS 101 may integrate with third party systems via one or more Application Program Interface (API).

Restaurants typically provide a table service to consumers, that is the consumer may consume a meal at a table in the restaurant, and the restaurant may also provide additional services such as takeaway services to consumers. In relation to providing a table service to consumers, restaurants have conventionally been inefficient at monitoring and making available tables for booking by consumers. In order to improve the efficiency of each restaurants table service the RPMS 101 may monitor the occupancy state of each table within a restaurant.

In this regard, the RPMS 101 may be operatively connected to, or communicatively coupled to, one or more image capture apparatus 115, one or more Point of Sale is (POS) devices 116, and one or more Receiving Order System (ROS) devices 117 within a given restaurant via at least one external and/or internal data/communication network 103, 118. The internal data/communication network 118 may be any suitable data/communication network, for example, a wired local area network, a wireless local area network (e.g. Wi-Fi), Bluetooth, or any combination thereof.

The image capture apparatus 115 may be any suitable apparatus for capturing an image or images, for example, the image capture apparatus may be a camera and/or an infrared camera. The one or more image capturing apparatus, e.g. cameras, 115 may be positioned at suitable locations within the restaurant 104 and directed towards one or more tables 119. Each of the one or more image capturing apparatus may be installed within the restaurant with a clear line of sight to each table that a corresponding image capturing apparatus is monitoring. The location of each image capturing apparatus may be determined based on floor plans for the restaurant and/or at installation of the image capturing apparatus in the restaurant.

Each table 119 within a restaurant may have one or more cameras 115 directed at the respective table to take optical images, infrared images and/or videos, which in the following description of the embodiments will collectively be referred to as images.

The cameras 115 are operatively connected to the RPMS 101 via the internal data/communication network 118 and/or the external data/communication network 103, such that the images captured by the cameras 115 are transmitted to and received by the TOM 107 of the RPMS 101. As mentioned hereinabove, the TOM 107 may be implemented on the cloud computing environment 102 or the TOM 107 may be located at the restaurant 104 on a local server/computing device 114. The internal and/or external data/communication networks 103, 118 may be any suitable type of data/communication network to enable images captured by the cameras 115 to be transmitted to and received by the TOM 107, for example, the internal and/or external data/communication network 103, 118 may be an optical network, a wired network, a wireless network (e.g. Wi-Fi. Bluetooth), or any combination thereof. The images captured by the cameras may be stored within the cloud computing environment and/or may be stored on a server and/or may be stored using a mirrored server solution.

The TOM 107 may be, include, or be operatively connected to, a Machine Learning Module (MLM) 108. The TOM 107 may determine an actual occupancy state of each table 119 in the restaurant using the MLM 108. A function of the TOM 107 is to determine the actual occupancy state by identifying whether a given table 119 in the restaurant 104 is an unoccupied (i.e. vacant or available) table or is an occupied table in a restaurant. This is advantageous as it allows unoccupied tables to be released, or made available, for booking by future consumers more frequently and in a more efficient and effective manner. The TOM 107 may also be able to determine one of several possible actual occupancy states of each table in the restaurant, for example, in addition to occupied or unoccupied the TOM 107 may also be able to determine the occupancy state of a given table as being cleared and/or cleaned, a table prepared (e.g. laid) for a consumer, a table unprepared (e.g. not laid) for a consumer, temporarily unoccupied (e.g. the consumers have temporarily left the table), the number of consumers located at the table, the consumers are running late for their booked table, consumers/staff walking past the table, amongst any other occupancy states as required by the restaurant. The accuracy and intelligence of the determinations of the occupancy state determination may increase and improve over time as more images are captured and analysed by the TOM 107 and the MLM 108. In other words, by analysing more images of the tables over the time that the cameras are installed the TOM 107 and MLM 108 may learn to identify and determine multiple different occupancy states. The occupancy states to be determined for a given restaurant may be predetermined and set by a policy defined by the restaurant. The policy may be defined using the AM 113 which allows flexibility for each restaurant based on the requirements and needs of each restaurant.

The actual occupancy state of each table 119 in a restaurant 104 can be determined by the TOM 107 substantially simultaneously for multiple tables, or one table at a time. The actual occupancy state of a given table may be determined by the TOM 107 continuously, or at, or after, a predetermined time period. For example, the actual occupancy state of each table may be determined substantially continuously, or each table actual occupancy state may be determined after a predetermined time, e.g. every 30 seconds, every 1 minute, every 5 minutes, every 10 minutes, every 15 minutes, every 20 minutes, every 30 minutes, every 45 minutes, every 60 minutes, and so on. As will be appreciated, the predetermined time can be any suitable predetermined time as required in order to efficiently and effectively monitor the occupancy of each table in the restaurant. The cameras may constantly monitor the tables within a restaurant and either provide images in real time to the TOM 107 or at the predetermined times to enable the TOM 107 to determine the occupancy state as frequently as required.

The method of determining the actual occupancy state of one or more tables will be described with reference to the flowchart of Figure 2.

The TOM receives one or more images from one or more cameras positioned within the restaurant such that each of the one or more cameras may capture images of one respective table within the restaurant. The TOM may receive, for each table, one or more images from one or more cameras positioned with a line of sight of, or directed to, each table. One camera positioned to capture images of each table would be sufficient but in order to increase the effectiveness of the table occupancy state determination two or more cameras may be used at different positions and with a different line of sight to each table.

The following description relates to the actual occupancy state determination of one table within the restaurant but, as will be appreciated, the following description will apply to each table within the restaurant.

The one more cameras record an image of a table within the restaurant 201. The images may be recorded at any suitable predetermined time period, for example, every 1 minute, every 5 minutes, every 10 minutes, and so on.

The TOM receives the captured images of the table 202 and, via the MLM, analyses the images to determine a predicted occupancy state for the given table 203. In an example, the table may include four chairs to seat four consumers. Two cameras are positioned with a different line of sight to the table, e.g. at opposite sides of the table, so that the two cameras capture images of the table from a different perspective and a different view. The MLM is trained to classify the images based on image feature characteristics and output a table occupancy state prediction of whether the table is occupied or unoccupied based on the analysis of the received is images. The table predicted occupancy state will be unoccupied if it is determined from the images that no consumers are located at the table (whether standing or seated depending on the table configuration). The table predicted occupancy state will be occupied if it is determined from the images that consumers are located at the table (whether standing or seated depending on the table configuration).

The TOM receives the table predicted occupancy state from the MLM to identify whether the table predicted occupancy state is occupied or unoccupied 204.

If the table predicted occupancy state is unoccupied (i.e. not occupied), the TOM determines a booking occupancy state from the BM 206, as the BM maintains an entry for each table which indicates whether the table is expected to be occupied or 25 unoccupied.

The BM may maintain a log of all bookings made for each table within the restaurant, where the log for each booking for each table may include several parameters such as the time of the booking, an expected duration of the table booking, the number of consumers, and any notification messages specific to the booking (e.g. the consumers are running late for their booking). The duration of the table booking may be predetermined or configured by the restaurant, via the AM, based on the average time consumers typically spend at a table in the restaurant, which may be further based on several additional factors such as the number of consumers, time of day of the booking, and any special occasion given for the table booking.

There may be a number of reasons why the table predicted occupancy state was unoccupied whilst the BM has the table set to occupied. For example, the consumer(s) may have temporarily left the table to visit the toilets, to take a telephone call outside, or any other reason to be away from the table.

Thus, if the booking occupancy state is occupied and the predicted occupancy state is unoccupied then the TOM applies one or more algorithms in order to determine the actual occupancy state 205. The one or more algorithms applied may include waiting a predetermined period of time to allow consumers to return to the table. The predetermined period of time may be any suitable predetermined period of time, for example, 1 minute, 2 minutes, 5 minutes, 10 minutes, and so on. The predetermined period of time may be set by the restaurant via the AM. After the predetermined period of time has elapsed the TOM may receive a further image from the camera(s) and the MLM may make a further table predicted occupancy state based on the further images received from the camera(s). If the further table predicted occupancy state is again unoccupied then the table actual occupancy state is determined as unoccupied 208. The TOM may then modify the BM to set the table as unoccupied and make available the table for booking by further consumers 208. A notification may then be transmitted to one or more members of staff at the restaurant to notify them of the change in occupancy state of the table in the BM 210.

In some embodiments, the applied algorithms 205 may alternatively or additionally identify from the BM a notification message relating to the table booking. The notification message may, for example, specify that the consumers are running late and therefore the table occupancy state should remain as occupied so that the TOM does not set the table occupancy state as being unoccupied in the BM, and therefore the actual occupancy state is set to occupied. If a new arrival time is provided then the BM may be modified to reflect the change in times for the booking of the table.

If the table predicted occupancy state is unoccupied and the booking occupancy state is also unoccupied 206 then the TOM determines that the actual occupancy state is unoccupied 209 and no modification to the BM for that table is required.

If the determination of the table occupancy state prediction is occupied 204 then the TOM determines the booking occupancy state from the BM 211. If the booking occupancy state is determined to be occupied then the actual occupancy state is determined to be occupied and no modification to the DM for that table is required. 212.

However, if the table booking occupancy state is determined to be unoccupied (i.e. available) then the TOM determines that the actual occupancy state is occupied and modifies the BM to set the given table as occupied and therefore unavailable for booking by further consumers 213. A notification may then be transmitted to one or more members of staff at the restaurant to notify them of the change in occupancy state of the table in the BM 210. This may be necessary for several reasons, such as a consumer enters the restaurant to consume a meal without prior booking and/or if the BM had not been updated accordingly by the members of staff.

In the above embodiments, the predicted occupancy states and actual occupancy is states of occupied or unoccupied where determined by the TOM using the MLM. However, further occupancy states may be determined, e.g. table being cleaned, table set ready for new consumers, and so on, along with parameters relating to the table, such as the number of consumers occupying the table, based on the images from the cameras and the analysis of the received images by the MLM.

The MLM 108 is based on any suitable Machine Learning Framework and applies known techniques for image recognition and prediction. Therefore, a detailed description of the MLM 108 is not provided but a brief summary is provided for reference. The MLM 108 may be implemented as a Neural Network Model or as a Convolutional Neural Network.

Using a Neural Network Model the MLM 108 is initially trained using a data set of images that are labelled with a corresponding occupancy states (e.g. occupied or unoccupied). The initial data set of images may be a general set of images relating to occupied or unoccupied tables or may be a set of images specific to the tables of a given restaurant again relating to occupied or unoccupied tables. Alternatively, the MLM 108 may be trained with a general set of images and then once the system is implemented for a given restaurant the MLM 108 may subsequently be further trained with a set of images specific to the tables of that restaurant.

For each image of the training data set, pixel features are extracted where the features relate to characteristics of the image. An image is comprised of a number of pixels wherein each pixel is represented by a number, or a set of numbers, that indicate the colour, or bit, depth. The colour depth indicates the maximum number of potential colours that can be used in the image, for example, in an (8-bit) greyscale image (i.e. a black and white image) each pixel has one value that ranges from 0 to 255. However, images will now typically be a Red, Green, Blue (RGB) image meaning each pixel will be a combination of RGB colours with a set of numbers representing the RGB components.

Therefore, each known labelled image of the training set is converted to a number of pixel features, typically an image may be represented by hundreds, if not thousands, of features. The MLM 108 is trained by analysing the pixel features using a network of filters so that the MLM 108 is able to recognise that the training image matches the known labelled output for that training image (e.g. occupied or unoccupied).

Once the MLM 108 is trained using the training data set of images, the MLM 108 can then make a prediction of the occupancy state of a table from an image taken by a camera directed towards the table. The pixel images of the features of the table image received from the camera are extracted and the extracted image is analysed by the network of filters and a prediction is made by the MLM 108 as to whether the table is occupied or unoccupied (or any other occupancy state that is to be determined).

As mentioned hereinabove, the MLM 108 may alternatively be implemented using a Convolutional Neural Network (CNN) which operates in a different manner to that of the Neural Network Model described above. In a CNN the first stage of the training, using the initial labelled training data set of images as described above, involves a Convolution layer in which uses a small boxes to define features in the image. For example, the boxes may be a small number of pixels such as a 2x2 pixel box that define a feature in the image, for example, each feature may characterise a particular shape in the original image and there may be any number of features. The image is scanned for each feature, e.g. the 2x2 pixel box scans the image to identify areas of the image that match the feature. If there is a perfect match then a high score is recorded for that location of the box, and if there is a low match or no match then a low score or a zero score is recorded for that location of the feature box. This process of scanning the image for various different features is typically called filtering. The filtered images, one for each feature, are then stacked together to become a convolution layer.

The filtered images for each feature are then pooled in order to shrink the image size. During pooling a window, e.g. a 2x2 pixel window, scans through the filtered image of each feature and assigns the maximum score of that 2x2 window to a 1x1 box in a new image. This is repeated for each filtered image corresponding to each remaining feature such that after pooling, a new stack of smaller filtered images is generated for each feature.

In the final layer of the CNN the stack of smaller filtered images is then split and subsequently stacked into a single combined list, where each value in the single list corresponds to the labelled image e.g. occupied or unoccupied. Once the CNN is trained an image from the camera directed to a table would be subject to the same process, in order to then make an occupancy state prediction, e.g. occupied and unoccupied (or any other occupancy state that is to be determined).

The MLM 108 once trained by either the Neural Network Model or the CNN may be subjected to a number of test images in order to determine the accuracy of the occupancy state prediction, where the number of test images are suitable to determine the accuracy, for example, hundreds or thousands of images and the test image may also be used to improve the training of the MLM 108.

The MLM 108 may be further trained on images showing the table being cleaned, the table set for new consumers, an unset table, and various number of consumers at a given table so that the MLM 108 may predict further occupancy states or parameters relating to the table.

The test images may be obtained from the cameras in the restaurant during an initialisation period. The TOM 107 may not be operational (e.g. go live) until the resulting accuracy from the testing during the initialisation period has reached an accuracy threshold, e.g. 90%, 95%, or 99%. The initialisation period may be any duration necessary to reach the accuracy threshold and may be dependent on the number of test images acquired from the cameras within the restaurant. For example, the initialisation period may be any period covering days or weeks, and typically the test or initialisation period may be approximately 7 days, in order to reach the accuracy threshold and then become operational. The initialisation period may be reduced if the TOM 107 and MLM 108 utilise intelligence and learning from images obtained and analysed from different restaurants that are also subscribed to the RPMS 101. Thus, over time, based on the learning from multiple restaurants the initialisation period for a newly subscribed restaurant may be reduced.

Returning now to Figure 1, the POS devices 116 may include one or more of mobile devices, tablet devices, touch screen devices, and computer devices. The POS devices 116 may be positioned at different locations within the restaurant and/or be to mobile such that they can be carried by members of staff of the restaurant.

The POS devices 116 may receive as input one or more food and beverage orders for consumers. The food and beverage orders inputted to the POS devices 116 may be transmitted to and received by one or more modules of the RPMS 101 via the internal and/or external data/communication networks 103, 118.

Alternatively, or additionally, a consumer device 120, for example a consumer mobile device, tablet, touch screen device or computing device, may include an application or a web based application 121 that corresponds to, or is substantially similar to, the POS device software enabling the consumer to directly input, on their consumer device 120 via the application 121, their food and beverage order for the restaurant.

The consumer device 120 may then transmit the food and beverage order to the OM 111 of the restaurant, where the consumer may be located external to the restaurant (e.g. making a takeaway food order), or the consumer may be located within the restaurant, (e.g. located at a table within the restaurant). An advantage of enabling a consumer, via the application 121 on their consumer device 120, to input their food and beverage order directly to the OM 111 of the RPMS 101 is that the consumer does not need to wait for a member of serving staff to attend their table and take their food and beverage order, which is more efficient as there are no unnecessary delays between a consumer choosing their food and beverage order and the order being taken and received by the OM 111 of the RPMS 101. A further advantage is that serving staff can be more efficient in serving prepared food and beverage orders to consumers, more efficient on cleaning tables in preparation for new consumers and other duties that are assigned to the serving staff.

The ROS devices 117 may include one or more of mobile devices, tablet devices, touch screen devices, and computing devices. The ROS devices 117 may be positioned at different locations within the restaurant and may be allocated to specific functions of the restaurant. For example, a first ROS device may be located at a Bar area, a second ROS device may be located at the Starters kitchen area, a third ROS device may be located at the Main Meal kitchen area, and a fourth ROS device may be located at the Dessert kitchen area. As will be appreciated, there may be any number of ROS devices 117 positioned at one or more locations within the restaurant as required by the layout of the restaurant and any services offered by the restaurant. Therefore, if a consumer food and beverage order is input to a POS device 116, or a consumer device 120, and transmitted to the OM 111 via the data/communication networks 103, 118, the OM 111, on receiving the order from the POS device 116, may determine the relevant ROS devices 117 to which respective order data relating to the food and beverage order is transmitted. The ROS device(s) 117 on receiving the respective order data can display the order data. For example, a food and beverage order input to the POS device 116, or the consumer device 120 via application 121, includes a salad starter, a steak starter, a burger main and two drinks. This order is received by the OM 111 which identifies the respective order data for Starters kitchen area, Main Meal kitchen area and the Bar area. The identified respective order data is then transmitted to the ROS device at the respective area of the restaurant and displayed for the relevant staff member(s) to prepare the food and beverage order for the consumer. The OM 111 will also be able to cater for more complex orders, such as starters being ordered as main meals, consumer's allergy requests, consumers customising orders to their preference, and so on. The OM 111 can identify the more complex orders and provide the additional information to the relevant area of the restaurant to be displayed on the relevant ROS device to ensure that all orders are appropriately and timely actioned.

The OM 111 may also track the orders received and provide status updates and notifications to the POS device 116 and/or the consumer device 120 via application 121. For example, the OM 111 may provide an estimated time at which one or more parts of the order may be completed to the consumer device 120 and may provide a notification to the POS device 116 when one or more parts of the order have been prepared enabling a staff member to collect and deliver the prepared part of the order to the consumer. This is advantageous as the consumer is kept updated on the status of their order and the member of staff can deliver the prepared parts of the order to the consumer in a timely manner.

Furthermore, the RPMS 101 is a paperless system which is advantageous in that orders cannot become lost, misplaced or given in an incorrect order to the relevant sections of the restaurant.

A consumer may also use the application 121 on their consumer device 120 to operatively connect to the BM 106 in order to make a table booking. The consumer may input into the application 121 various booking parameters relating to the potential table booking, for example, the booking parameters may include the date of the table booking, the time of the table booking, the number of people for the table booking, a consumer name, a consumer contact telephone number and any special requests. As will be appreciated, there may be any number of booking parameters that the consumer may have to provide as required by the particular BM 106 and/or the given restaurant. Furthermore, the RPMS 101 will be compliant with General Data Protection Regulation (GDPR) or Data Privacy laws applicable in the country of operation in order to protect consumer's data privacy by storing and using data provided by a consumer in accordance with the local requirements. The RPMS may, in fact, only store or retain the consumer's mobile telephone number and not store or retain any further personal or sensitive data relating to the consumer.

On receiving the table booking parameters, the BM 106 determines whether a table is available that matches the received booking parameters.

If a table is available that matches the booking parameters then the BM 106 zs allocates and reserves a table for the consumer and sends a notification via the application 121 on the consumer device 120 to confirm the table booking.

If a table is not available that matches the received booking parameters then a notification is sent to the consumer via the application 121 on the consumer device 120 informing the consumer that no table is available. The BM 106 may additionally send a notification via the application 121 on the consumer device 120 to enquire as to whether the consumer would like to register for any future updates regarding table availability, should a table become available that matches, or substantially matches, the received booking parameters. The consumer can then register via the application 121 in response to the notification so that the consumer does not need to keep re-entering and submitting the booking parameters to check as to whether a table becomes available. Thus, the BM 106 can further effectively maintain a waiting list for consumers wishing to visit the restaurant and, should a table cancellation be received that makes a table available that matches the booking parameters of the consumer booking request, the BM 106 may send a notification to the consumer via the application 121 on the consumer device 120 to notify the consumer that a table is available. The notification from the BM 106 may further specify a deadline by which the consumer must respond in order to confirm the table booking. Prior to the deadline the BM 106 may provisionally reserve the table for the consumer. If the consumer responds to the notification via the application 121 then the BM 106 makes the table reservation for the consumer. However, if the consumer responds negatively or does not respond prior to the deadline then the BM 106 will mark the

table as available.

As mentioned hereinabove, the RPMS 101 may include several further modules as required for the registered restaurants and/or takeaway outlets. Therefore, different restaurants and/or takeaway outlets may include one or more of the modules depending on their requirements.

Several of the modules of the RPMS 101 may include a machine learning aspect which may be implemented by the MLM 108 or one or more further machine learning modules. Machine Learning is a facilitator relating to prediction, and may be defined as: 171 = f (X" fl) + e, where Y, is a dependent variable, f is a function, X, is an independent variable, 13 are unknown parameters, and ei are error terms. The 13 coefficient is the degree of change in the outcome variable (y-axis) for every 1-unit of change in the predictor variable. If the 13 coefficient is negative, the interpretation is that for every 1-unit increase in the predictor variable, the outcome variable will decrease by the 13 coefficient value.

In embodiments, the RPMS 101 may additionally include an MPM 109 which facilitates the restaurant/takeaway outlet 104, 105 to send push notifications to market their services, meals or send promotion discounts to their existing consumers. The MPM 109 may use a conventional recommendation engine to provide recommendations for potential meals, restaurants, or takeaway outlets that the consumer may like based on tracked or historical data relating to the given consumer and/or further consumers. The MPM 109 may alternatively use further functionality of the MLM 108 to predict potential recommendations for each consumer based on tracked or historical data relating to the given consumer and/or further consumers.

Thus, the MPM 109 of the RPMS 101 enables each restaurant to send marketing and/or promotional push notification messages to all consumers that have used their services in the past and have either downloaded the application 121 to their consumer device 120 or have provided a mobile telephone number to the restaurant for the purpose of receiving notifications from the restaurants and/or takeaway outlets 104, 105.

Consumers may also have the ability to add one or more restaurants as favourites in the application 121, which would enable the consumers to receive notifications from a number of specific restaurants/takeaway outlets 104, 105 of their choice, and/or to decline future notifications from one or more restaurants/takeaway outlets 104, 105 should they so wish.

In order to prevent too many notifications being sent to any one consumer, each restaurant/takeaway outlet, or the RPMS 101, may limit the number of notifications in any one period, for example, over a single day, over a week, or over a month. For example, the RPMS 101 may limit the number of notifications pushed to a given consumer to a single notification per day and therefore the notifications from different restaurants may be collated into one notification or the recommendation engine may determine the premium push notification to send from a premium restaurant/takeaway outlet depending on the consumer choices for the notifications and/or on the subscription level of the restaurant/takeaway outlet 104, 105. Thus, the MPM 109 can intelligently only send one marketing/promotional push notification to each mobile device per day.

The MPM 109 has several advantages including improving the relationship between demand and supply, e.g. by improving the relationship between the restaurant/takeaway outlet (supply) and the consumer (demand). For example, a consumer that enjoys burgers will be sent promotional information based on restaurants/takeaway outlets in the consumer's area and meeting the prediction from the machine learning module. The use of hidden reviews enables the MPM 109 to identify the best dishes a restaurant/takeaway outlet prepares according to consumer preferences so that the MPM 109 can specify the best dishes a restaurant/takeaway outlet does in a certain area. This equates to finding the best supplier to the consumer's demand. Hidden reviews are maintained in a Cloud System Database where access is enabled by the Cloud Function System which contains a set of machine learning algorithms wherein the hidden reviews will be a feature of these algorithms (serving as input data).

The MPM 109 has the advantage that such push notifications provide direct and tailored marketing to consumers and reduces the need for restaurants to invest as substantially in offline marketing such as leaflets.

In embodiments, the RPMS 101 may additionally include a Product Search Module (PSM) 110. The PSM 110 enables consumers to search for and locate the type of food they wish to purchase across multiple restaurants and/or takeaway outlets 104, 105, and/or list the available food items in an order from highest rated to lowest rated from the different restaurants/takeaway outlets 104, 105. The PSM 110 may indicate the highest rated food item based on multiple restaurant/takeaway outlet menus along with hidden consumer reviews, highest sales, and any other factors that may be considered. The PSM 110 may also utilise functionality of the MLM 108, or include a separate MLM specific for the PSM 110, in order to predict the highest rated food item for a given type of food that the consumer wishes to purchase based on the above parameters. The MLM may include a recommendation engine based on historical sales, orders and/or hidden reviews. In relation to the MLM functionality described above 13 represents the weight of the features (x-axis) which is historical data, hidden reviews, and so on. These features will influence the y-axis (the prediction) differently at different times wherein p is updated by time.

Furthermore, the PSM 110 enables the consumer to choose different food items from different restaurants/takeaway outlets 104, 105 at the same time in a single order and pay for the combined food order with a single transaction.

The PSM 110 on receiving the order from the consumer, transmits the order data relevant to a particular restaurant/takeaway outlet 104, 105 to the OM 111 corresponding to the particular restaurant/takeaway outlet so that the restaurant/takeaway outlet can fulfil their part of the consumers food order. The PSM 110 may also split the monetary aspect of the transaction between the different restaurants/takeaway outlets depending on the items purchased and make the respective payments.

The PSM 110 may further enable consumers to find the highest rated food item across retailers in a localised area to the consumer based on the location of the consumer device 120. The PSM 110 may include a search engine that utilises hidden consumer reviews, where hidden user reviews are reviews left by other consumers that have previously posted about a particular restaurant/takeaway outlet, and/or a specific food item offered by different restaurants/takeaway outlets. The hidden consumer reviews are typically kept out of public viewing but are accessible by the PSM 110. Hidden reviews are maintained in a Cloud System Database where access is enabled by the Cloud Function System which contains a set of machine learning algorithms wherein the hidden reviews will be a feature of these algorithms (serving as input data).

If the restaurant/takeaway outlet is not open during the time of the product search then results from that restaurant/takeaway outlet are not included or provided to the consumer. Similarly, if the consumer location is outside of any restaurant/takeaway outlet delivery range then the results from that restaurant/takeaway outlet are not included or provided to the consumer.

Thus, the PSM 110 provides the advantages of offering the consumer convenience and flexibility in ordering food items from multiple restaurants/takeaway outlets without having to review every restaurant/takeaway outlets menu separately.

In embodiments, the RPMS 101 may additionally include an Intelligent Reporting Module (IRM) 112. The IRM 112 may include, or be operatively connected to, a machine learning module, e.g. MLM 108, to provide various reports, projections and predictions to maximise and optimise the performance of the restaurant and/or takeaway outlet. The IRM 112 may provide an accurate projection of future turnover based on one or more previous periods, e.g. the previous weeks, months, quarters etc. The IRM 112 may further provide a prediction of demand and/or sales based on historical seasonal behaviour of consumers. The prediction of demand/sales by the IRM 112 may further include defining a future time period for the prediction, wherein the future time period could be set by the restaurant/takeaway outlet as required, which may be utilised to maintain availability and supply of stock by either automatically ordering required stock or providing the appropriate report, along with ensuring adequate levels of staffing based on the predicted sales. The IRM 112 may also take into account any promotional/marketing notifications or campaigns to predict the impact on restaurant/takeaway outlet turnover. The IRM 112 may adjust future predictions based on exceeding or underperforming of actual results in relation to the previously predicted results.

The IRM 112 may enable the planning of product/produce purchasing and resources (e.g. staff) against sale predictions based on historical data. The results of any marketing promotions may also be used to give predictions on product/produce volume expectations and staff planning. The MLM may utilise the information to provide improved predictions and such information could also enable a restaurant/takeaway outlet to expand on a certain dish type as a means of increasing sales/revenue.

The use of machine learning technology maximises the effectiveness of reporting to optimise the performance and forecasting of the restaurant/takeaway outlet. This enables intelligent predictions for the future in a particular range or period. For example, for the next day prediction (to ensure inventory and staff resource allocation is effective), the machine learning may compare day to day but also cater for particular seasonal and special periods like Christmas, or events like a sports match. For a prediction over the next week to allow for effective and accurate planning of supplier orders (for inventory) and resource (staff) the predictions may effectively be seven individual day predictions, where the machine learning may automatically adjust future day predictions based on the exceeding or underperforming of actual results based on the current or previous day's prediction.

This reporting feature becomes a useful tool for the restaurant/takeaway outlet owners/managers to manage their business in the most effective way. By increasing revenue through optimised inventory and staff costs (through accurate prediction models), the business will increase profitability.

Thus, the IRM 112 advantageously enables a more efficient and effective management along with an accurate prediction of demand/sales, stock, and staffing levels by utilising machine learning.

In embodiments, the RPMS 101 may additionally include an Administrator Module (AM) 113. The AM 113 enables the restaurant/takeaway outlets 104, 105 owners/managers personalise and manage the functionality of one or more modules of the RPMS 101 by setting certain parameters relevant to each of the one or more modules.

The invention can be further understood with reference to the following paragraphs of description.

Should there be a problem with the external data/communication network and/or the internal data/communication network for an extended period in a restaurant/takeaway outlet using the RPMS services, the RPMS solution may implement a local/cloud database synchronisation feature that will enable service to continue, without service impact.

The cloud computing environment implementing the RPMS may hold on to messages where connection is broken, and to deliver to the destination address once connection is re-established. This is viable for short outages lasting no more than a minute or so. However, for outages that last longer (such as cable breaks etc.), the service impact for the RPMS would have far greater impact.

Any service outage may occur between the Network Provider and the restaurant/takeaway outlet router, and/or between the cloud computing environment and the Network Provider for a backhaul issue.

Once the service outage is fixed and connection is re-established the local database would synchronise with the RPMS in the cloud computing environment to enable the orders being included in reporting, analysis, archiving etc. Should WiFi and/or mobile data signal go down, rendering it impossible to use a handset to make an order, online ordering remains possible through a Desktop Application via the local database.

This has the advantage of mitigating the risk to availability and service disruption and for WiFi loss or mobile signal loss.

The RPMS local/cloud synchronisation solution solves the technical problem where service disruption from WiFi/Internet outage lasts more than a few minutes, where the delay would be deemed an issue.

The Local database server may be a physical server with mirrored disks located on the premises (e.g. the premises of the restaurant/takeaway outlet) which is kept synchronised with one or more modules of the RPMS on the cloud computing environment, preferably at all times. The local/cloud synchronisation feature enables the order to be sent on the local LAN (Intranet) to the local server, whereupon the order will be sent to ROS without delay. This solution prevents any service disruption resulting from the connection break.

The restaurant/takeaway outlet owner/manager may have the option on a web app/dashboard/administration module to switch between local or cloud should they detect any significant drop in WiFi/Internet connectivity.

Both the Receiver Order Station (ROS) and Table Status Tracker (TST)/order module need to be able to receive orders from either local/cloud database. Similarly, an additional UX on the Consumer Mobile App (CMA), e.g. the application on the consumer device, may need to be added to accommodate the menu and ordering process via the local database server.

The CMA scanning one OR code may trigger a menu (and subsequent ordering) through the RPMS on the cloud computing environment. Another QR code may trigger the menu from the local server (via the LAN (Intranet)) where the order would be similarly made and processed. Instructions may be provided on a table or elsewhere in a restaurant/takeaway outlet explaining the scenarios when both OR codes are to be used.

Note, whilst the restaurant/takeaway outlet may provide WiFi access details, consumers having unlimited data on their phones may use 3G/4G/5G data connections to make the order. In such an example an order placed on 3G/4G/5G data connection should go to the RPMS but should the Internet be down at that moment, the order will be put on hold and only processed (i.e. sent to ROS) when the connection is re-established.

Where WiFi and mobile data signal loss (for Internet connectivity) are experienced, the RPMS facilitates an order being placed via a Desktop Application. The only consideration is that a staff member would need to present the Desktop Application to the consumer.

The synchronisation feature exists to support all services i.e. eat in, collection and delivery. The local/cloud synchronisation feature is designed to maintain uninterrupted service. Removing service interruption that may result from broadband/backhaul outage; an uncontrollable for the RPMS solution.

The RPMS may additionally include a Retailer and Supplier Smart Enterprise Resource Planning (ERP) system which includes a dashboard for both the restaurants/takeaway outlets and their suppliers. As inventory levels reach a minimum threshold an order can be automatically placed with a supplier to restock, or at a minimum raise attention to the restaurant/takeaway outlet manager or owner to action. This feature is advantageous as it avoids the restaurant/takeaway outlet owner having to check inventory levels without compromising the restaurant/takeaway outlet. By developing a hub for the restaurant/takeaway outlet and each of their suppliers an automatic link for ordering can be activated against defined thresholds. By understanding the inventory stocking levels of each item/produce and the amount used in preparing each dish, the RPMS, or a module thereof, may maintain an accurate account of all stock levels, and as configured can send automated orders to specific suppliers to restock levels.

This re-ordering is achieved far quicker than the restaurant/takeaway outlet owner/manager themselves could achieve, the system helps mitigate produce associated as in high demand. Where one supplier is not able to fulfil the demand, a second (or multiple) suppliers can be activated to make up the difference.

Utilising the same 'supply and demand' approach as other Machine Learning feature implementations, the system also compares behaviour of similar inventory and ordering patterns or previous and similar periods (e.g. a year ago), as well as recent trading and consumer behaviour.

The system aims to perform the responsibility of re-stocking inventory autonomously in a way that enhances performance and reduces waste which enhances environmental sustainability improvements and a more eco-friendly solution.

The Retailer and Supplier Smart ERR is designed to optimise running of the restaurant/takeaway outlet and making the most effective decisions on inventory ordering and remove reliance on the restaurant/takeaway outlet manager/owner in having to make decisions to re-stock inventory levels (food produce and beverage).

The RPMS may additionally record the temperature of all fridges within a restaurant/takeaway outlet using sensors connected to the fridges. Records will be archived for the appropriate time before being written over. This solves the problem of restaurants/takeaway outlets having to manually measure temperatures of their fridges to confirm appropriate produce is adequately refrigerated.

The RPMS may also include one or more security features. For example, the entire code is encrypted and located behind the cloud computing environment hosting system. The RPMS may also include a bespoke DDoS which through the encryption will prevent any Cross-Origin Resource Sharing (CORS) or Subresource Integrity (SRI) attack. The encryption also hides the technology behind the RPMS.

In the foregoing embodiments, modules may interact in order to provide additional advantages. For example, the TOM 107 may interact with the MPM 109 in that it learns the habits of consumers' movements, frequency of booking particular restaurants, food orders, and so on in order to send proactive notifications related to booking offers at the consumers favourite restaurant. A further example is that the Retailer and Supplier Smart ERR may interact with the intelligent reporting module within the RPMS. The Retailer and Supplier Smart ERR may also interact with the marketing and promotion module to identify which meals are being promoted and the impact this will have on stock levels.

In the foregoing embodiments, features described in relation to one embodiment may be combined, in any manner, with features of a different embodiment in order to provide an RPMS that provides restaurants and/or takeaway outlets with a more efficient and effective management system. Note that, the above description is for illustration only and other embodiments and variations may be envisaged without departing from the scope of the invention as defined by the appended claims.

Claims

Claims 1. A method of operating a Retailer Process Management System, the Retailer Process Management System includes at least a Table Occupancy Module and a Booking Module, the method comprising: receiving at the Table Occupancy Module one or more images of a table, wherein the images are received from one or more image capturing apparatus; analysing the received one or more images; determining a predicted occupancy state for the table based on the analysis of the received one or more images.determining a booking occupancy state for the table from the Booking Module; and determining an actual occupancy state for the table based on at least the predicted occupancy state and the booking occupancy state.
2. The method of claim 1, further comprising a Machine Learning Module 15 wherein the Machine Learning module analyses the received one or more images to determine the predicted occupancy state.
3. The method of claim 1 or claim 2, in which if the determined predicted occupancy state is unoccupied and the booking occupancy state is occupied, the method further comprises: applying by the Table Occupancy Module one or more algorithms; and the step of determining the actual occupancy state for the table is further based on the applied algorithms.
4. The method of claim 3, wherein the one or more algorithms include waiting a predetermined period of time before determining a further predicted occupancy state for the table based on an analysis of further images received from the one or more cameras; and if the further predicted occupancy state is unoccupied the actual occupancy state is determined as unoccupied.
5. The method of claims 3 or 4, in which the one or more algorithms include identifying from the Booking Module any notification messages relevant to the table; and if the notification messages indicate that the table is occupied then the actual occupancy state is determined as occupied.
6. The method of any one of the preceding claims, in which if the determined predicted occupancy state for the table is occupied and the booking occupancy state is unoccupied, the method further comprises: determining the actual occupancy state as occupied.
7. The method of any one of the preceding claims, in which if the determined actual occupancy state of the table differs to the booking occupancy state in the Booking Module for the table then the method further comprises: modifying the Booking Module to set the table to the actual occupancy state.
8. The method of claim 7, further comprising; sending a notification of the modification to the Booking Module for the table to a user of the Retailer Process Management System.
9. The method of any one of the preceding claims, in which the Booking Module further maintains a waiting list of one or more consumers; and wherein if the actual occupancy state for the table is determined to be unoccupied sending a notification to a consumer device of a consumer on the waiting list.
10. A Retailer Process Management System, comprising: at least a Table Occupancy Module and a Booking Module, at least one image capturing apparatus, wherein each image capturing apparatus has a line of sight to one of a plurality of tables; and wherein the Table Occupancy Module is configured to: determine a predicted occupancy state for the table based on the analysis of the received one or more images; determine a booking occupancy state for the table from the Booking Module; and determine an actual occupancy state for the table based on at least the predicted occupancy state and the booking occupancy state.
11. The Retailer Process Management System of claim 10, further comprising a Machine Learning Module wherein the Machine Learning module is configured to analyse the received one or more images to determine the predicted occupancy state.
12. The Retailer Process Management System of claim 10 or 11, in which if the determined predicted occupancy state is unoccupied and the booking occupancy state is occupied, the Table Occupancy Module is further configured to: apply one or more algorithms, and determine the actual occupancy state for the table further based on the applied algorithms.
13. The Retailer Process Management System of claim 12, wherein the one or more algorithms include waiting a predetermined period of time before determining a further predicted occupancy state for the table based on an analysis of further images received from the one or more cameras; and if the further predicted occupancy state is unoccupied the Table Occupancy Module is further configured to determine the actual occupancy state as unoccupied.
14. The Retailer Process Management System of claims 12 or 13, in which the one or more algorithms include identifying from the Booking Module any notification messages relevant to the table; and if the notification messages indicate that the table is occupied then the Table Occupancy Module is further configured to determine the actual occupancy state as occupied.
15. The Retailer Process Management System of any one of claims 10 to 14, in which if the determined predicted occupancy state for the table is occupied and the booking occupancy state is unoccupied, the Table Occupancy Module is further configured to: determine the actual occupancy state as occupied.
16. The Retailer Process Management System of any one of claims 10 to 15, in which if the determined actual occupancy state of the table differs to the booking occupancy state in the Booking Module for the table then the Table Occupancy Module is further configured to: modify the Booking Module to set the table to the actual occupancy state.
17. The Retailer Process Management System of claim 16, in which the Table Occupancy Module is further configured to; send a notification of the modification to the Booking Module for the table to a 5 user of the Retailer Process Management System.
18. The Retailer Process Management System of any one of claims 10 to 17, in which the Booking Module is further configured to maintain a waiting list of one or more consumers; and wherein if the actual occupancy state for the table is determined to be unoccupied the Booking Module is further configured to send a notification to a consumer device of a consumer on the waiting list.
19. A computer program product comprising computer readable executable code to implement a method according to any one of claims 1 to 9.