WO2018142107A1

WO2018142107A1 - System for monitoring activity

Info

Publication number: WO2018142107A1
Application number: PCT/GB2018/050200
Authority: WO
Inventors: Giacomo POPPI
Original assignee: Alitica Ltd
Priority date: 2017-02-02
Filing date: 2018-01-24
Publication date: 2018-08-09
Also published as: GB201701753D0

Abstract

A system for monitoring activity in a hospitality establishment comprising a plurality of tables is disclosed. The system comprises a sensor unit (806) for attachment to a table, and a central activity monitor (814). The sensor unit comprises a vibration sensor (402) for sensing vibration of the table at different points in time to produce vibration data, and means (408) for transmitting the vibration data to the central activity monitor. The central activity monitor (814) comprises means for receiving the vibration data, and a processor (605) configured to process the vibration data to determine different types of activity at the table. This may allow a breakdown of different stages of consumption of a meal or beverage to be obtained.

Description

SYSTEM FOR MONITORING ACTIVITY

Field

The present invention relates to a system for monitoring activity, and to a sensor unit for use in such a system. The invention has particular, but not exclusive, application in monitoring activity in a hospitality establishment such as a restaurant or bar. Embodiments of the invention relate to an activity sensor and system. In particular, but not exclusively, a movement sensor and system for sensing movement characteristic of a dining activity.

Background

When a customer/s visit a restaurant, public house ("pub"), bar or other table service establishment they may be guided to an empty table by a waiter and seated or find a vacant table themselves. The customers will then decide on the food and drinks to be ordered from the menu. When the waiter determines that the customers have finished looking at the menu, they return to the table and take the order from the customers. The order is typically then entered into a Point of Sale system (PoS) or on a notepad so that it can be relayed to the kitchen or food/beverage preparation area for the order to be tracked and fulfilled.

Subsequently, the waiter will return with the food and/or drinks for the fulfilled order and at which point the customers are left alone to begin the meal. The time intervals between the waiter's interactions with the customers i.e. to offer desserts/coffee, bringing the bill etc., is a judgement on the waiter's behalf. This is determined by factors the waiter can observe visually such as customer behaviour and attitude at the table or aurally if called to the table. Such behaviour may be, for example, that the customers are still eating or whether their plates are empty and the like. Waiting staff will be expected to monitor tables in such a way while simultaneously serving other tables, refilling drinks, clearing tables and generally caring for other customers.

One drawback of this conventional approach is that there will be occasions when a waiter fails to notice that the customers they are responsible for are ready to be served; when they misjudge the status of the table; and the like. This leads to the customers having to wait, which will usually give rise to a bad customer experience and potentially bad reviews on websites or other public forums.

For managers of hospitality establishments, forecasting what customer levels are likely to be and thus stock to keep in at a given time is a very important aspect of their position. There may be external events that can affect the demand for their establishments' services and customer levels such as forecasting, or at least improved forecasting would be very useful. In particular, where perishable items such as food and drinks are part of the inventory accurate forecasting is needed to reduce the amount of waste. Waste can be due to over-ordering such as when customer levels do not reach the expected levels upon which ordering was based. On the contrary, if there is an increase in demand due to external factors, under-ordering can cause problems such as a reduced menu or reduction of tables due to stock shortages. This may lead to a possible lower overall customer experience which should be avoided. Stock ordering is closely related to, and typically follows forecasting the number of customers the establishment will be likely to have on any given day, and so is also a key interest of an establishment's manager.

Another challenge of managing a hospitality establishment is the accurate forecasting of the number of staff to have in on a given shift. Too many and the establishment will lose money, too few and they will struggle to serve the customers to a satisfactory level.

What can be seen is that most of the management, and service is based solely upon human observations and the managers' experience. There is a lack of live data upon which to make managerial and service decisions. There is also a lack of operational visibility, which means such observations and experience may be difficult to integrate into business administration and financial systems. This leaves a lot of room for errors and miscalculations leading to loss of money and poor customer service. Waiter served businesses typically do not have access to analytics about their businesses typically because of the cost of these tools or the lack of trained staff who can use data- analytic tools. Management strategies or marketing campaigns are implemented and the results can only be observed after weeks or months from when it is implemented. With one or more

embodiments of the present invention, one may be able to see day by day the impact of strategic decisions on performance or advertising. E.g. A) Lowering prices across an entire chain and observing the impact on customer demand. B) Improving the quality of the food and observing the reaction in customer satisfaction. C) Increase in employee salaries, and observing the increase in staff performance, etc. Currently there are already attempts to try and introduce software and computer systems to enhance the hospitality industry. For example in: Point of Sale

Terminals/Systems, inventory management systems, reservation and check-in and self-service systems.

Aspects and embodiments of the present invention have been devised with the foregoing in mind. Summary

According to one aspect of the present invention there is provided a system for monitoring activity in a hospitality establishment comprising a plurality of tables, the system comprising: a sensor unit for attachment to a table, the sensor unit comprising a vibration sensor for sensing vibration of the table at different points in time to produce vibration data, and means for transmitting the vibration data to a central activity monitor; and

a central activity monitor comprising means for receiving the vibration data, and a processor configured to process the vibration data to determine different types of activity at the table.

The present invention may provide the advantage that, by sensing vibration of the table at different points in time to produce vibration data, and processing the vibration data to determine different types of activity at the table, it may be possible for the system to identify various stages of consumption of food or beverages at the table. This in turn may be used to provided notifications to staff to help improve the customer experience and/or metrics which may be used by management to increase operational efficiency.

The central activity monitor may be, for example, a central station such as a computer located within the hospitality establishment, a separate server, a processor hosted by a cloud computing platform, or any other suitable processing means.

Preferably the system includes a plurality of sensor units, with at least one sensor unit for each table for which activity is to be monitored.

The processor may be configured to assign an activity status for each of the different types of activity. This may provide a convenient way of organising information concerning the status of the table in a way which can be readily understood.

The different types of activity may be different stages of consumption of a meal or beverage. For example, the different types of activity may comprise at least one of: table vacant; customers seated; customers being attended; order placed; customers eating or drinking; customers finished eating or drinking; table vacated; table cleaned. Of course, the skilled person will appreciate that various other stages or sub-stages may also be determined. Thus, the processor may be configured to provide a breakdown of different stages of consumption of a meal or beverage.

Preferably the processor is arranged to analyse values of the vibration data at different points in time, to determine different types of activity at the table. Thus, the processor may be arranged to analyse variations in the vibration data over time, and this may be used to determine different types of activity at the table. As well as the vibration data itself, other factors such as the previous status of the table, time elapsed since certain events, proximity of waiting staff, and/or inputs derived from other systems, may be used in determining the type of activity at the table.

In one embodiment of the invention, average vibration levels over a period of time are used to distinguish between different types of table activity. Thus, the processor may be configured to produce an average value of the vibration data over a predetermined period of time, to compare the average value with a reference value, and to determine a type of activity at the table in dependence on the result of the comparison. This embodiment is based on the recognition that different types of activity at the table will result in different vibration levels at the table when averaged over a period of time. Thus, by comparing the average value with one or more reference values, a relatively simple and convenient way of determining the type of activity may be provided.

In another embodiment of the invention, which may be used separately or in conjunction with the embodiment described above, a mathematical model is used to determine the type of activity. Thus the processor may be configured to apply the vibration data to a mathematical model to determine the type of activity. The mathematical model may be a machine learning model, which may be pre- trained on reference data. For example, the mathematical model may be a neural network model. This may allow underlying patterns in the vibration data to be identified more accurately. Thus this embodiment may allow more accurate determination of the different types of activity to be achieved, although at the cost of some additional processing.

The processor and/or the sensor unit may be configured to process the vibration data using a filtering algorithm, such as a Kalman filter. This may help to reduce the influence of noise and anomalous vibration.

The system may further comprise a user interface for displaying the determined type of activity at the table. The user interface may be provided on the same device as the processor, or on one or more separate processing devices such as a tablet or laptop computer. The user interface may be arranged to display information indicating the current statuses of the tables in the hospitality establishment. For example, a floorspace map could be displayed showing the tables and their current statuses. Where action is needed, this could be indicated on the display, for example by displaying alerts or changing the colour of a table on the display. This may allow staff to be notified of anomalies and/or forgotten duties, and help to ensure efficient usage of tables. Furthermore, the user interface may assist kitchen staff to schedule the preparation of meals. The means for receiving the vibration data may be a receiver and/or may be part of a

communications (transceiver) module, such as a wireless local area network module. The communications module may permit the central activity monitor to transmit as well as to receive information.

The central activity monitor may be configured to generate a service alert in dependence on the determined type of activity at the table. The service alert may be sent to one or more members of staff, in order to alert them that action is needed. For example, the central activity monitor may be arranged to transmit the service alert to a mobile communications device associated with a member of staff. This may help to ensure that prompt action is taken, leading to improved customer experience and more efficient usage of the tables. Alternatively or in addition, the service alert may be displayed on a user interface.

The service alert may indicate an action to be taken by that member of staff. For example, the service alert may indicate that the member of staff should attend a particular table.

The service alert may also be generated in dependence on other factors such as time elapsed since a particular event. Thus, for example, if it is determined that customers have been seated at a particular table but have not ordered for a predetermined period of time, or if it is determined that the customers have finished eating for a predetermined period of time, then the service alert may indicate to the member of staff that they should attend that table.

The sensor unit may further comprise a processor and associated memory. The processor may be configured to temporarily store the vibration data in the memory and/or carry out some preprocessing of the data prior to transmission.

The vibration sensor may be an accelerometer, such as a three-axis accelerometer (although a one or two axis accelerometer could be used instead). Such devices are readily available, and thus provide a convenient and inexpensive way of sensing vibration. If desired, the sensor unit may include two or more vibration sensors, in order to sense vibration at different parts of the table. At least one of the vibration sensors could be provided externally to the sensor unit.

The means for transmitting the vibration data may be a transmitter and/or may be part of a communications (transceiver) module, such as a wireless personal area network module. For example, the module may be a Bluetooth Low Energy module, or any other appropriate module. This can allow a relatively low cost and low power module to be used, thereby prolonging battery life. The sensor unit may include a temperature sensor for sensing the ambient temperature to produce temperature data. In this case, the sensor unit may be configured to transmit the temperature data to the central activity monitor. This may be done, for instance, together with the vibration data or using the same communication means as that used to transmit the vibration data.

The system may comprise a user interface for displaying an indication of temperature based on the temperature data. For example, the temperatures at different locations in the hospitality establishment may be displayed. This can allow the temperatures in different locations in the hospitality establishment to be monitored centrally, allowing staff to take the appropriate action if temperature levels are not comfortable.

The user interface used to display temperatures may be the same as that used for displaying the type of activity at the table. Thus, for example, the user interface may display a floor plan showing the various tables, the statuses of the tables, and the temperatures at the tables. This can allow staff to quickly gain an overview of the conditions in the hospitality establishment.

Preferably the sensor unit comprises an internal clock. In this case the sensor unit may be configured to transmit timestamps, indicating the times at which the vibration data and/or the temperature data were collected, to the central activity monitor. For example, the vibration data and/or the temperature data may be transmitted to the central activity monitor in packets of data together with the relevant time stamp. This can allow the central activity monitor to accurately record vibration levels against time, regardless of any delay in transmitting the vibration data to the central activity monitor.

The internal clock may be configured to be synchronised with the clock of an external device, such as a mobile communications device. This can help to ensure synchronisation between the various devices in the system.

The sensor unit may be configured to detect a user action and, in response, to transmit a service request signal to the central activity monitor indicating that the table needs attending. The central activity monitor may be configured to generate a service alert on receipt of the service request signal. The service alert may be, for example, transmitted to a mobile communications device, or displayed on a user interface.

The user action may be, for example, an action which produces a predetermined pattern of vibrations. In this case, the sensor unit may be configured to detect the predetermined pattern of vibrations. For example, customers may be informed that they should knock at the table three times if they wish to summon a waiter. In this case, the sensor unit may be configured to detect a pattern of three knocks, and to transmit the service request signal when this pattern is detected.

Alternatively or in addition, the central activity monitor may be configured to determine the predetermined pattern from the received vibration data, and to generate a service alert in response thereto.

In another example, the user action may be the pushing of a button. For example, the sensor unit may comprise a button which may be pushed by a customer when they wish to summon a waiter. It will be appreciated that any other suitable way of detecting a user action could be used instead.

The system may further comprise a portable device arranged to be carried by a member of staff, and configured to communicate with the sensor unit. Preferably the portable device and the sensor unit are arranged to communicate with each other using a wireless personal area network. This can allow communication to be carried out at low power, thereby prolonging battery life.

Preferably at least one of the portable device and the sensor unit is configured to determine proximity of the portable device to the sensor unit, and to transmit a signal indicative of said proximity to the central activity monitor. This may allow the central activity monitor to infer when the table is being attended by the member of staff, based on the signal indicative of proximity. The signal may be a simple indication of the fact that the portable device is close to the sensor unit. Alternatively, the signal may include an estimation of the distance between the portable device and the sensor unit. In this case the central activity monitor may be able to determine which portable device is closest to the table. This in turn may allow the central activity monitor to generate a service alert for the most appropriate member of staff.

In order to allow proximity detection, one of the portable device and the sensor unit may be configured as a beacon that broadcasts an identifier, and the other of the portable device and the sensor unit may be configured to receive the identifier and to determine the proximity of the portable device to the sensor unit based on receipt of the identifier, for example, using signal strength.

The processor may be configured to determine the type of activity at the table based additionally on a signal indicative of proximity of the portable device to the sensor unit. This may help to provide a more accurate determination of the status of the table, by taking into account factors such as whether or not a member of staff is in proximity to a table, how close the member of staff is to the table, and the amount of time which has elapsed since a member of staff attended the table. Furthermore, service alerts may be generated based at least in part on the time elapsed since a member of staff attended the table.

In one embodiment of the invention the portable device is a mobile communications device, such as a mobile phone or other portable processing device with transmission capabilities. The mobile communications device may have an application installed to control participation of the device in the system. This can allow a device which is already available to be part of the system.

The mobile communications device may be configured to receive the vibration data from the sensor module, and to transmit the vibration data to the central activity monitor. For example, the mobile communications device may be configured to receive the vibration data from the sensor unit over a wireless personal area network, such as Bluetooth, and to transmit the vibration data to the central activity monitor over a wireless local area network, such as Wi-Fi, or over a cellular network. In this way, the functionality of the mobile communications device can be used to relay the vibration data from the sensor module to the central activity monitor. This can allow the sensor unit to use a low power wireless personal area network, which may prolong battery life.

The mobile communications device may be arranged to receive a service alert from the central activity monitor, and to provide an indication of an action to be taken to a user of the device based on the service alert. For example, the mobile communications device may vibrate, and/or may display a message. The message may indicate an action to be taken, for example, which table is to be attended.

In another embodiment, the portable device is a dedicated device which includes a communication means, such as a wireless personal area network module, for communicating with the sensor unit. This can allow the management to provide a simple and inexpensive device to the staff, without the need for the staff to use their own devices. The device may also be provided with additional functionality, such as the ability to receive service alerts and indicate them to the user.

In any of the above arrangements, but particularly in the case where the portable device is dedicated device, the system may further comprise a gateway device configured to receive the vibration data from the sensor unit, and to transmit the vibration data to the central activity monitor. For example, the gateway device may be configured to receive the vibration data from the sensor unit over a wireless personal area network, and to transmit the vibration data to the central activity monitor over a wireless local area network or a cellular network. This may allow the sensor units to transmit at low power, thereby prolonging battery life, while ensuring that all sensor units are able to communicate with the central activity monitor. The gateway device may be any suitable communications device capable of communicating with both the sensor unit and the central activity monitor, such as a mobile phone, tablet or laptop, or a dedicated device.

The central activity monitor may be configured to communicate with another system, such as a point of sale system, an inventory management system, a reservations system, a check-in system or a self-service system, for example, using the appropriate application programming interface (API). For example, the central activity monitor may be able to link to a point of sale system's (API) in order to retrieve details of a customer's order. This may allow additional information to be made available to the system for use in analysing activity.

The central activity monitor may be arranged to receive an input from another system, and the processor may be configured to determine the type of activity at the table based additionally on the input from the other system. For example, the number of courses which have been ordered may be used in determining the type of activity.

In a typical hospitality establishment, there may be many periods of time in which a table is not being used. At such times it is unnecessary to transmit vibration data frequently, and doing so would shorten battery life. In one embodiment, the sensor unit may be operative in a first and second mode, wherein in said first mode the sensor unit is operative to sense vibration at a first periodicity and in said second mode the sensor unit is operative to sense vibration at a second periodicity comprising shorter intervals than said first periodicity, and wherein the sensor unit is operative to invoke said second mode when a vibration value exceeds a threshold. This can allow the sensor unit to preserve battery life when the table is not being used.

This aspect of the invention may also be provided independently and thus, according to another aspect of the invention, there is provided a sensor unit configured to sense vibration at a table, said sensor unit operative in a first and second mode wherein:

in said first mode said sensor unit is operative to sample vibration at said table at a first periodicity, and

in said second mode said sensor unit is operative to sample vibration at said table at a second periodicity comprising shorter intervals than said first periodicity; and

said first mode is responsive to sampling a vibration exceeding a background threshold level to invoke said second mode.

Viewed from another aspect, there is provided a sensor module (sensor unit) configured to sense vibration at a sense station; said sensor module operative in a first and second mode wherein in said first mode said sensor module is operative to sample vibration at said sense station at a first periodicity and in said second mode operative to sample vibration at said sense station at a second periodicity comprising shorter intervals than said first periodicity and store a vibration sample with a vibration characteristic value satisfying a criterion, said first mode responsive to sampling a vibration having a said vibration characteristic value exceeding a first threshold value to invoke said second mode.

Typically, the sensor module may further be operative in said second mode to invoke said first mode responsive to sampling a vibration having a vibration characteristic value less than a second threshold value for a vibration characteristic measurement time interval.

The sensor module may further be operative in said second mode to calculate the variance of a plurality of vibration characteristic values derived from a corresponding plurality of vibration samples. The sensor module may further be operative to collect said plurality of vibration samples within a time window of a length such that at least two said time window may fit within said vibration characteristic measurement time interval. Optionally, said criterion is said vibration sample comprises a vibration characteristic value falling above a lowest range of said variance.

The lowest range may be the bottom 50%, preferably the bottom 33%, more preferably the bottom 25%, yet more preferably the bottom 12.5% and even more preferably the bottom 6.25% of the variance.

Optionally, the sensor module may be configured to sense G force. The sensor module may comprise an accelerometer. The sensor module may be operative to detect vibration in two or more transverse directions.

Optionally, the sensor module may comprise a communications module and operative to transmit a vibration data signal representative of said vibration characteristic value to a system

communications module of a sensor system. The sensor module may be optionally operative to transmit said vibration data signal responsive to receiving a signal indicative of said system communications module ready to receive said signal.

The sensor module may be operative in a calibration mode to: take a first plurality of vibration calibration samples over a sample period; assign a greatest vibration characteristic value of said plurality of vibration calibration samples as a vibration characteristic threshold value; periodically take vibration samples after said sample period; take a second plurality of vibration calibration samples over a subsequent sample period responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and assign a greatest vibration characteristic value of said second plurality of vibration calibration samples as a vibration characteristic threshold value.

Viewed from another aspect, there is provided, a sensor module configured to sense vibration, operative in a calibration mode to: take a first plurality of vibration calibration samples over a sample period; assign a greatest vibration characteristic value of said plurality of vibration calibration samples as a vibration characteristic threshold value; periodically take vibration samples after said sample period; take a second plurality of vibration calibration samples over a subsequent sample period responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and

assign a greatest vibration characteristic value of said second plurality of vibration calibration samples as a vibration characteristic threshold value.

Viewed from a further aspect, there is provided a sensor system, comprising: a sensor module, a communications module and operative to transmit a vibration data signal representative of said vibration characteristic value to a system communications module of the sensor system, the sensor system further comprising a central station configured to receive said vibration data signal; and wherein said central station is configured to assign an activity status for the sense module from an analysis of one or more of said vibration data signal communicated from the sensor module.

Alternatively, the sensor system may comprise a sensor module, comprising a communications module and operative to transmit a vibration data signal representative of said vibration

characteristic value to a system communications module of a sensor system. The sensor module may be operative to transmit said vibration data signal responsive to receiving a signal indicative of said system communications module ready to receive said signal. The sensor module may further be operative in a calibration mode to: take a first plurality of vibration calibration samples over a sample period; assign a greatest vibration characteristic value of said plurality of vibration calibration samples as a vibration characteristic threshold value;

periodically take vibration samples after said sample period; take a second plurality of vibration calibration samples over a subsequent sample period responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and assign a greatest vibration characteristic value of said second plurality of vibration calibration samples as a vibration characteristic threshold value; and a central station configured to receive said vibration data signal; and wherein said central station is configured to assign an activity status for the sense module from an analysis of one or more of said vibration data signal communicated from the sensor module. Optionally, said central station may comprise said systems communication module. The system communications module may be comprised in a mobile communications device associated with a service presence of said sensor system, said mobile communications device operative to transmit said vibration data signal onwards to said central station. Said central station may be configured to infer an activity type from an analysis of one or more of said vibration data signal communicated from the sensor module.

Optionally the sensor system may further comprise a sense station and wherein said sensor module is configured to sense vibration of said sense station.

Optionally the sensor system may comprise a platform, said sensor module operatively coupled to said platform to sense said vibration. The platform may optionally comprise a table, a service bar or a seat. The sensor module may be configured to sense vibration of said platform.

In sensor system according to any of the above aspects, said mobile communications device may be configured to receive a wireless signal transmitted from said sensor module, said mobile communications device operative to determine proximity of said mobile communications device to said sense station and transmit a signal indicative of said proximity to said system communications module.

Optionally, said wireless signal may be a low power wireless signal, such as a BLE signal.

Optionally, said mobile communications device may be configured to transmit a handshake signal indicative of said service presence proximal to said sense station.

The central station may optionally be configured to record a vibration present state for said sense station based on one or more of said vibration data signal received at said central station; determine absence of said vibration present state for said sense station; and generate a first service alert responsive to determination of absence of said vibration present state for said sense station.

Optionally, said central station may further be configured to determine said vibration present state duration and generate said alert for said vibration present state duration exceeding a time period commensurate with the consumption of a meal course and or a beverage. The central station may further be configured to: receive said service signal indicative of a service presence at said sense station; and record a service present state for said sense station based on one or more of said service signal received at said central station.

Optionally the sensor system may be further configured to determine an identity of said service presence from said service signal and optionally further configured to transmit said first service alert to said mobile communications device corresponding to said identity of said service presence.

The sensor system may further be configured to: determine end of said service present state;

monitor elapsed time from said end of said service present state; and generate a second service alert if said elapsed time exceeds a threshold time without said central station receiving a said vibration data signal.

Optionally, said central station is further configured to transmit said second service alert to a said mobile communications device corresponding to said identity of said service presence.

Central station may further be configured to store said service presence identities and set a status indicative of a service presence identity corresponding to a service presence signal received from said sensor.

The sensor module may optionally be configured to be operative to transmit signal sensor identity signal responsive to receiving said wireless signal from said mobile communications device.

In the above aspects the term "sensor module" is preferably used interchangeably with "sensor unit".

According to another aspect of the invention, there is provided a method of monitoring activity in a hospitality establishment comprising a plurality of tables, the method comprising:

sensing vibration of a table at different points in time to produce vibration data;

transmitting the vibration data to a central activity monitor;

receiving the vibration data at the central activity monitor; and

processing the vibration data to determine different types of activity at the table.

Viewed from a further aspect, there is provided a method of operating a sensor module configured to sense vibration at a sense station, said method comprising said operating said sensor in a first and second mode wherein in said first mode said sensor module is operative to sample vibration at said sense station at a first periodicity and in said second mode operative to sample vibration at said sense station at a second periodicity comprising shorter intervals than said first periodicity and store a vibration sample with a vibration characteristic value satisfying a criterion, said first mode responsive to sampling a vibration having a said vibration characteristic value exceeding a first threshold value to invoke said second mode.

Optionally, the method may further be operative in said second mode to invoke said first mode responsive to sampling a vibration having a vibration characteristic value less than a second threshold value for a vibration characteristic measurement time interval.

Optionally, the method may further be operative in said second mode to calculate the variance of a plurality of vibration characteristic values derived from a corresponding plurality of vibration samples.

The method may further the operative in said second mode to collect said plurality of vibration samples within a time window of a length such that at least two said time window may fit within said vibration characteristic measurement time interval.

Optionally, said criterion is said vibration sample comprises a vibration characteristic value falling above a lowest range of said variance.

The lowest range of said reference is the bottom 50%, preferably the bottom 33%, more preferably the bottom 25%, yet more preferably the bottom 12.5% and even more preferably the bottom 6.25% of the variance.

The method may further comprise sensing G force. Optionally, the method may further comprise detecting vibration in two or more transverse directions.

The method may further comprise transmitting a vibration data signal representative of said vibration characteristic value to a system communications module of a sensor system.

Optionally, the method may comprise transmitting said vibration data signal responsive to receiving a signal indicative of said system communications module ready to receive said signal.

Optionally, the method may further comprise invoking a calibration mode comprising: taking a first plurality of vibration calibration samples over a sample period; assigning a greatest vibration characteristic value of said plurality of vibration calibration samples as a vibration characteristic threshold value; periodically taking vibration samples after said sample period; taking a second plurality of vibration calibration samples over a subsequent sample period responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and assigning a greatest vibration characteristic value of said second plurality of vibration calibration samples as a vibration characteristic threshold value.

According to a further aspect there is provided a method of operating a sensor module configured to sense vibration, comprising invoking a calibration mode comprising: taking a first plurality of vibration calibration samples over a sample period; assigning a greatest vibration characteristic value of said plurality of vibration calibration samples as a vibration characteristic threshold value; periodically taking vibration samples after said sample period; taking a second plurality of vibration calibration samples over a subsequent sample period responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and assigning a greatest vibration characteristic value of said second plurality of vibration calibration samples as a vibration characteristic threshold value.

According to a further aspect there is provided a method of operating a sensor system comprising: invoking transmitting a vibration data signal representative of said vibration characteristic value to a system communications module of a sensor system, receiving at a central station said vibration data signal; and assigning at said central station an activity status for the sense module from an analysis of one or more of said vibration data signal communicated from the sensor module.

Alternatively there is provided a method of operating a sensor system; comprising: invoking transmitting said vibration data signal responsive to receiving a signal indicative of said system communications module ready to receive said signal, further comprising invoking a calibration mode comprising: taking a first plurality of vibration calibration samples over a sample period; assigning a greatest vibration characteristic value of said plurality of vibration calibration samples as a vibration characteristic threshold value; periodically taking vibration samples after said sample period; taking a second plurality of vibration calibration samples over a subsequent sample period responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and assigning a greatest vibration characteristic value of said second plurality of vibration calibration samples as a vibration characteristic threshold value.

Optionally, said central station may comprise said system communications module. Said system communications module may be comprised in a mobile communications device associated with a service presence of said sensor system, said mobile communications device operative to transmit said vibration data signal onwards to said central station. Said central station may be configured to infer an activity type from an analysis of one or more of said vibration data signal communicated from the sensor module.

Optionally, the method may comprise sensing vibration at a sense station.

Said sense station may optionally comprise a platform, said sensor module operatively coupled to said platform to sense said vibration. Said platform may comprise a table, a service bar or a seat. Said sensor module may be configured to sense vibration of said platform.

Optionally said mobile communications device is configured to receive a wireless signal transmitted from said sensor module, said mobile communications device operative to determine proximity of said mobile communications device to said sense station and transmit a signal indicative of said proximity to said system communications module. Said wireless signal may be a low power wireless signal, such as a BLE signal.

Optionally, said mobile communication device may transmit a handshake wireless signal indicative of said service presence proximal to said sense station.

Optionally, the method further comprises at said central station: recording a vibration present state for said sense station based on one or more of said vibration data signal received at said central station; determining absence of said vibration present state for said sense station; and generating a first service alert responsive to determination of absence of said vibration present state for said sense station.

The method may further comprise at said central station determining said vibration present state duration and generating said alert for said vibration present state duration exceeding a time period commensurate with the consumption of a meal course and or a beverage.

The method may further comprise at said central station: receiving said service signal indicative of a service presence at said sense station; and recording a service present state for said sense station based on one or more of said service signal received at said central station.

Optionally, the method may further comprise determining an identity of said service presence from said service signal.

Optionally, the method may further comprise at said central station transmitting said first service alert to said system communications module corresponding to said identity of said service presence. Optionally, the method may further comprise at said central station: determining end of said service present state; monitoring elapsed time from said end of said service present state; and generating a second service alert if said elapsed time exceeds a threshold time without said central station receiving a said vibration data signal.

Optionally, the method may further comprise at said central station transmitting said second service alert to a said mobile communications device corresponding to said identity of said service presence.

Optionally, the method may further comprise at said central station storing said service presence identities and setting a status indicative of a service presence identity corresponding to a service presence signal received from said sensor.

Optionally, the method may further comprise at said sensor module transmitting said signal sensor identity signal responsive to receiving said handshake wireless signal from said system

communications module.

Optionally, said central system may comprise a server accessible over a communications network, such as the internet.

Features of one aspect of the invention may be provided with any other aspect. Any of the apparatus features may be provided as method features and vice versa.

Brief description of the figures:

One or more embodiments in accordance with aspects of the present invention will now be described, by way of example only, and with reference to the following drawings in which:

Fig. 1 is a schematic diagram of a restaurant from overhead;

Fig. 2a is an illustrative graph representing measured table vibration vs. time throughout a meal in a food establishment;

Fig. 2b is a process flow control diagram illustrative of a process to determine if a waiter is attending a table;

Fig. 3 is a schematic diagram of the wireless network between sensors and internet connected devices;

Fig. 4 is a schematic block diagram of the vibration and temperature sensor;

Fig. 5 is a schematic block diagram of the staff mobile devices;

Fig. 6 is a schematic block diagram of the backend server and data management architecture; Fig. 7 is a schematic diagram of the frontend services, website and mobile application; Fig. 8 is a schematic diagram showing data management and structure in the backend server; Fig. 9 is a schematic illustration of a diagram displaying the temporal vibration data of a two and three course meal;

Fig. 10 is an illustrative graph of activity for the sensor as a function of time;

Fig. 1 1 a is an illustrative state diagram of the sensor unit for an embodiment of the invention;

Fig. 1 1 b is an illustrative state diagram of the mobile device for an embodiment of the invention;

Fig. 1 1 c is an illustrative state diagram of the backend server for an embodiment of the invention;

Fig. 12 is an illustrative state diagram of the sensor calibration on start-up for the inactivity threshold;

Fig. 13 illustrates placement of the sensor unit under a table;

Fig. 14 is a schematic diagram showing parts of a system in another embodiment of the invention; and

Figure 15 shows an example of accelerometer readings collected by a sensor unit during a typical meal.

Overview

Embodiments of the present invention provide a system for monitoring activity in a hospitality establishment such as a restaurant, cafe, public house or bar. The system includes an inexpensive sensor unit, capable of monitoring vibration levels at a table, and determining the presence of waiting staff at the table. A sensor unit is placed beneath each table. By analysing table vibrations, the system is able to determine the stage of a meal a customer is at. Optionally, a corresponding portable device is carried by each member of staff on duty. By analysing signal intensity between a sensor unit and a staff device, the system is able to determine the proximity between waiting staff and the tables they attend. The result is a network of interconnecting devices collecting behavioural information from restaurant environments. The data is then used to derive metrics about customer experience, customer service, employee performance and operational efficiency, and to provide notifications to staff.

The sensor unit consists of a Bluetooth Low Energy (BLE) module, a high precision acceleration sensor (e.g. a three-axis accelerometer) and a temperature module. The unit may act both as a central and a peripheral Bluetooth device; that is, information can be sent sensor unit to sensor unit, sensor unit to external device, and/or external device to sensor unit.

Figure 13 illustrates placement of the sensor unit under a table in a hospitality establishment. If desired, two or more sensor units may be placed under the same table. This may be desirable for large tables or where a table has discontinuities in its surface, or to provide redundancy. Alternatively, the sensor unit could be placed on the top surface of the table. In this case the sensor unit may be provided with additional functionality, such as a button which may be pressed to summon a waiter.

As the sensor unit has a Bluetooth module, other Bluetooth-enabled devices will be able to determine the approximate distance to the sensor unit. Essentially, the sensor unit acts as a beacon that broadcasts its identifier to nearby portable electronic devices (for example, using the iBeacon protocol). The system is then able to determine when a member of staff is in proximity of a table if they are carrying a personal device on them.

The sensor unit tracks the real local time, by synchronising with staff devices when necessary. This allows the packages of data sent to include timestamps corresponding to when data was collected.

The most significant type of data collected by the sensor unit comes from its acceleration sensor. By capturing the acceleration of the axes at specific time intervals, backend servers are able to calculate the activity of a restaurant table at a given time through the use of statistical data analysis.

An additional type of information which is collected is that obtained by the temperature module. Temperatures in different areas of a restaurant can change significantly (indoors/outdoors) and it may be useful to keep track of this for additional insights.

Description

In general outline the sensor is in a form where the sensor collects vibration data related to indicate the most likely status of the table. The sensor may be paired with Bluetooth capable devices the waiting staff may have available or are issued with, this allows restaurants to streamline their service and for the software to determine when members of staff are attending a table using a proximity determination based on Bluetooth (RSSI) signal strength or the fact that a Bluetooth signal was detected. Detailed analytics derived from the sensor and waiter proximity data will be enhanced with external events to form a method for predictive resourcing. The table may be considered a sense station because it is the vibration at or associated with that table that is being sensed by the sensor.

Fig. 1 shows an embodiment of the invention and is an overhead schematic of a restaurant area 100. There are five tables 106, 108, 117, 118, 136. Each table has a vibration sensor and in the described embodiment a temperature sensor as well which may be housed as one device 116 and may be mounted on the underside of the table. It is to be noted that an embodiment in accordance with the present invention may comprise only a vibration sensor. The position of the sensors 116 is not limited to the underside, but merely an implementation detail of the current embodiment disclosed here. The sensor 116 collects vibrational and temperature data and possibly other environment data specific to the table it is mounted on. This collected data may then be transmitted using Bluetooth Standard Version 4.2 134 or with any other suitable relatively local wireless communication protocol or system to other sensors within range. When there is a Wi-Fi connected device, such as mobile phone, laptop, tablet, smart watch or custom device etc. within range of the sensors, such a device may connect to the sensors with its own Bluetooth connection. The device may act as a conduit for sensor data to be transferred to a backend server; the sensor data is transferred to the device via Bluetooth and then via Wi-Fi or other internet connected method to the backend server. The staff devices are not limited to the above mentioned examples, and may include custom built devices or the dining area may have a wireless local area network (LAN) to which the sensors may connect.

Another feature of the described embodiment is the collection of proximity and step count data regarding the waiters that are currently working in the venue. The waiters are shown as dark grey circles 104 and 112 are carrying the aforementioned Bluetooth capable devices (not shown) which can connect wirelessly to the sensors 116 that are mounted to the tables. These devices may be smart phones, tablets, smart watches or any other similar custom built devices. The relative distance 114 a waiter is from the tables is recorded by the waiter's device and sent through Wi-Fi or Bluetooth onto an internet connected machine such as a computer workstation depicted in 122. This is not limited to the work station 122 but could be the waiter's devices themselves, using the mobile network for example.

Using the device's own accelerometer the step count can be calculated. For example, Apple's HealthKit API for iPhone devices. Two main reasons include, but are not limited to, providing an additional measure of staff activity and can activate BLE searching based on when movement is detected.

A waiter's device is configured to also timestamp the proximity data as it collects it. This may then be used to determine when the waiter is attending the table, shown by 112. Other methods of determining the proximity data may include using an NFC tag placed on the table which a waiter may tap and or swipe with their smartphone or Bluetooth Low Energy (BLE) capable device or merely be detected by proximity of the waiter's device to the NFC tag. This will improve the accuracy of detecting when a waiter approaches a table. Such an NFC tag may be included in a sensor of the sensors mounted at the edge of the table, the waiters tap the device when attending the table. A typical scenario could be:

- Customers are seated

- Waiter approaches table

- Waiter swipes smartphone over NFC tag at the edge of the table (optional)

- System records waiter is attending the table

- System provided with table information: Table status, orders placed, how long customers have been waiting, edit order options, payment methods and the like.

This would not remove the benefit from the analysis of proximity data, but would improve the accuracy of detecting when a waiter approaches a table, and allow a waiter to gain access to table information easily.

Using the sensor data and waiter proximity data, the backend server is configured such that it may output a prediction of the current status of the table. The table shown in 106 has two customers 102 seated and eating a meal, which is indicated by the plates 132. The sensor 116 detects the vibration associated with the seating and eating a meal and transfers data corresponding to the vibration via the wireless network to the backend server for analysis. Table 118 shows no customers seated and plates 132. The backend server compares historical sensor and proximity data and determine that it has been vacated and needs cleaning. The backend server will send a notification 126 to a waiter near to the table, for example waiter 112. Table 108 shows three customers 110 seated, with no plates. This could mean that they have either just entered the restaurant; have eaten one of the courses and had the plates removed; be awaiting another course to be delivered; or could be awaiting the bill after finishing the meal. Table 117 shows an empty table ready to be used. Table 136 is a customer eating one of the courses of the meal.

During the course of the meal, sensor 116 will have been collecting vibrational and temperature data; transferring it to the waiter's mobile device and then, via an active internet connection, to the backend server. The backend server will determine the most likely table status, log it and push notifications 130 or 126 to the waiters' mobile device which may be a smartphone with an installed smartphone application configured for the described embodiment of the invention. Some of the possible push notifications 130 or 126 may include but are not limited to: indicating to a waiter to clear and clean a table; indicating to a waiter the customers have finished eating and therefore need service; indicating to a waiter to take the customers' order; indicating to a waiter to turn the temperature up or down; indicating a predicted period until the table is ready and so on. The push notifications (126, 130) may be tailored to the specific needs of the table at the current time. This is based upon the predicted status of the table under review derived from the sensor data and waiter proximity data. Push notifications (126, 130) may be configured to look like SMS text messages and mobile alerts, but they only reach users who have installed the application associated with the push notifications. Optionally or additionally system settings may be

customisable to determine the periodicity and mode of notifications. For example, a restaurant might decide that 6 minutes is the ideal waiting time before taking a customer order. Notifications will be sent according to that preference. Each mobile platform has support for push notifications— iOS, Android, Fire OS, Windows and BlackBerry all have their own services. Optionally, push

notifications may be communicated via a text message system such as SMS or a message system such as "What's App" in single or group message configuration.

Waiters will see a notification as a banner or pop-up alert on their mobile device. The push notifications will be convenient to notify the waiter of actions to be taken on a table. This may include sounds and/or haptic feedback such as vibrations from the user's mobile device. Unread notifications may appear as a red badge on the software application icon on the mobile device.

Haptic feedback is another way notifications will be notified. One example the invention may allow a kitchen staff member to call waiters to inform them a meal is ready to be served to a table. The member of kitchen staff could access the mobile device application, tap a button and the closest available waiter will be notified that food is ready to be served. This could be sent as an easily remembered 2/3 buzz vibration which allows waiters to be provided notifications without having to look at their mobile devices.

Another feature of the described embodiment is the ability to give the manager 120 analytics and statistics of the restaurant 124. This is all available through bespoke software and mobile Bluetooth device application.

Fig. 2a schematically illustrates the vibrational data collected by the sensor for a particular table. It is used as an example to illustrate how the status of the table may be determined, by way of example only. This specific vibrational data is typically unique to or at least representative or indicative of a particular situation and table and may vary between other tables and situations. The graph axes show vibrational data as a function of time with the waiter proximity data overlaid on top. The y-axis is an arbitrary scale for the vibrational energy data collected in sensor 116 and labelled average acceleration because vibration is measured by an accelerometer in the described embodiment. The grey vertical bars 222-230 indicate when the waiter is within a distance deemed to be sufficiently proximal to the table that it may be assumed, or at least treated as if, they are attending the table. For example in time region 204 the waiter is assumed and recorded to be serving the table as marked on the graph with the grey vertical bar. The data line 232 shows the measure of the vibration energy (average acceleration) as a function of time. The horizontal smooth lines correspond to zero activity, and the horizontal 'sinusoidal' line corresponds to vibrations detected by the sensor. The higher the horizontal sinusoidal line is on the y-axis, the greater the vibration energy.

The vertical dashed lines are used to split the graph for the purposes of description and

convenience. In region 202 there is no vibration detected and hence the backend server will determine that the table is vacant. This means the table status is 'available'. In region 204 the table goes from some measured background or zero vibration energy detected to substantial or significant vibration energy detected and this is represented by the sudden increase in signal detected by the sensor. Simultaneously, a waiter is detected nearby through a Bluetooth connection with table 222 and is assumed to be serving table 222. The backend server will have received no vibration signal or at least a vibration signal; representative of a vibration energy less than the threshold indicative that there was no significant or substantial table vibration present before the waiter approached, and received a vibration signal having sufficient vibration energy after the waiter is detected having left the proximity of the table, leading to a result that customers have been seated.

Region 206 shows a relatively constant vibration energy detected, with some variation about a horizontal trend. As a waiter approaches the table, 224, the waiter's proximity to table 224 is detected by the waiter's mobile device. The waiter then goes away from the table indicated by a loss of or low level of Bluetooth signal from the table 224 sensor. This most likely means the waiter has taken the order from the customers. The backend server is configured to identify proximity detection of a waiter going to a table having significant vibration energy and the loss of proximity detection as an interaction between the waiter and customers at the table comprising the taking of an order. In some embodiments Point of Sale data obtained during or just after period 206 may be inspected by the backend server to confirm whether or not an order has been placed. While the customers are waiting for the food to arrive, vibration energy is still detected and can originate from a number of sources such as a customer leaning on the table, moving the cutlery etc.

Column 226 shows that the waiter approaches again, followed by a large increase in vibrational energy detected by the sensor after the waiter leaves the table. This is seen in region 210 where there is a sharp increase in vibrational energy detected. The backend server receives signals indicative of the vibration energy sensed by the sensor and will use the previous status of the table, 'awaiting food', the fact the waiter has just approached and left the table and the increase in vibrational energy sensed at the table to change the status to "eating" as the sequence of detected events infers the customers are eating. "Eating" is assumed to be the table status in 212 also. Region 214 shows a significant decrease in the vibration data, back to a level comparable to region 206 when the customers were not eating. The backend server is configured such that it will determine the most likely table status is 'finished eating'.

During this time region, the waiter approaches, 228, the table. Due to the previous table status being that the customers have finished eating, the backend server is configured to determine that the waiter is most likely taking plates away; bringing the bill; or taking dessert/coffee orders. Again, similar to region 204 and 206, even though the customers are not eating, there is still a baseline vibration at the table. The customer then leaves the table in region 216, indicated by the sharp drop in vibration energy detected by the sensor, down to the zero/background measurement. There is an increase in vibration energy detected in region 218 while the waiter is attending the table for the entirety of the measured vibration (230). The backend server will know that the table was recently vacated after customers finished eating a meal at it, therefore this will indicate the table is being cleaned.

Finally, there is a decrease in the detected vibration energy back to zero or below a threshold energy, the threshold defining the separation between what is deemed background vibration energy and vibration energy indicative of relevant activity at the table, after the waiter leaves the table in region 220. The back end server is configured to respond to such a decrease by setting the status of the table to 'available'.

This is only one example of a single situation in which the vibration and proximity data has been used to determine the current status of the table it is mounted on. Other examples could include two or three course meals which are shown in Fig. 9a and Fig. 9b respectively. The backend server will be able to use pattern recognition to identify these signatures and accurately identify the table status with high precision. The pattern recognition may be aided by data optimisation and data clustering algorithms. Different levels of granularity of data could be used, and different vibration dimensions may be analysed in different ways to determine a table's activity. For example, moving averages, maximum/minimum time buckets, derivatives, percentiles, cluster analysis and so forth could be used.

Fig. 2b shows an illustrative flow chart 201 of the decision process made by the backend server for determining if a waiter is attending a table. The initial waiter status 203 is to 'not attending a table' and conditions must be met in order to confirm a waiter is 'attending a table'. The first condition 205 requires the distance between the sensor and the waiter's mobile device to be less than the distance to all other sensors. The second condition 207 requires the distance between the table and the waiter's mobile device, which in the described embodiment utilising Beacon "Eddystone" technology, to be less than 3m. The distance is measured using the received signal strength indication (RSSI) and beacon technology such as "Eddystone" converts the RSSI into the most likely distance from BLE object (waiter mobile device). This measure is what we are comparing against by stating "less than 3m". The final condition 209 requires the waiter to be stationary which is decided by measuring the number of footsteps taken by the waiter. Optionally, if the number of steps detected on the waiter's mobile device does not increase and conditions 205 and 207 are satisfied, then the waiter status is 'attending the table to which the sensor is attached'. The table number and time may be recorded when this status is set.

Fig. 3 shows a schematic illustrating the network connections between the sensors and the waiting staff personal devices. There is a general area 300 with the vibration and temperature sensors in the area 314 and Wi-Fi or Mobile Network and Bluetooth capable devices in area 320. The personal devices 312 may be staff mobile devices such as a mobile phone, smart watch or tablet; or a static device such as computer workstation or laptop within Bluetooth smart 4.1 + range of the sensors.

The devices 312 may be able to connect to the internet through Wi-Fi 310, Ethernet connection 322 or mobile networks 308. They can connect with Bluetooth Low Energy (BLE) to the vibration and temperature sensors in area 314 and transfer data to and from them.

The sensors within general area 314 are attached to tables (not shown) and can connect wirelessly to each other with Bluetooth represented by the dotted lines 306 between them. When one of the devices within 312 is within the range of a sensor such that they connect with the sensor via Bluetooth, vibration energy data collected by the sensors will be transferred to the devices 312 through the Bluetooth connection.

The sensors, as do all BLE Devices, "advertise" their "services" at fixed intervals which is predefined by hardware manufacturer and can be changed by a system implementer to optimise battery life. Devices 312 or other Bluetooth devices can scan for the sensors at fixed intervals as well, and notify/connect the sensor when they are in range. Sensors are woken up by motion activity and remain awake until all data has been collected off them and no motion is detected. When this happens, they can send data to the phone 312, or choose not to if there is not enough worthwhile data to be sent.

If one of the sensors within 314 is not within Bluetooth range of any of the devices within 312 then it may transfer its collected data through another sensor that is within range of a device. For example, if the vibration and temperature sensor 302 is not within the communications range of devices 312 but is within Bluetooth range of sensor 320 then sensor 320 is used to act as a conduit for the data 302. The data collected by 302 will be transferred over Bluetooth connection 306 to sensor 320. Sensor 320 is within range of the devices 312 and therefore transmits the data collected by 302 via Bluetooth.

Similarly, sensor 316 is also not within the range to transfer its data to devices 312 in one step, and therefore can 'daisy chain' through another sensor which is within range of a staff mobile device. This may be 318 or 320 depending on the shortest route or other determined path. This can occur for a plurality of sensors, and requires only one sensor to be within Bluetooth range of an internet connected device 312 (this is called an 'end point'). The number of 'hops' for the data to travel to reach an endpoint may be minimised by using Graph Theory or other similar techniques. Although this is a specific example of how the data transfer is achieved, one skilled in the art may envisage other decision structures or algorithms to determine the route used.

Typically, the range of Bluetooth smart 4+ is up to about 100 m, therefore the likelihood of having to daisy chain between sensors will be very low.

Fig. 4 shows a schematic block diagram of the components of the vibration and temperature sensor unit 400. The sensor unit 400 includes a small battery driven circuit supported on a PCB comprising the vibration monitor shown in block 402. The vibration monitor is a 3 dimensional acceleration sensor (ST Microelectronics LIS2HH12 accelerometer: 3-axis "pico" accelerometer) with scales capable of +/- 2g, 4g, and 8g accuracy and can measure accelerations with output rates of 10- 800Hz. The accelerometer works on a voltage range of 1 .71 -3.6V which means when the battery begins to run out, it will still work. Additionally, the ST Microelectronics LIS2HH12 accelerometer has an integrated first-in, first-out (FIFO) buffer allowing the user to store data in order to limit intervention by the host processor. The temperature sensor 404 within 400 has a precision of +/- 0.5°C. Both sensors 402 and 404 operate at low power and are optimised to give increased battery life. To increase the battery life, the sensor will automatically be on standby mode until a waiter's mobile device connects to it via Bluetooth.

A processor 405 executes sensor control software 406. The sensor control software 406 measure the battery level with an on board internal voltage reference. The vibration and temperature sensor unit also includes an on board Bluetooth transceiver 408 which is able to connect to other sensor units or internet connected devices shown as 312 in Fig. 3. In the described embodiment, the Bluetooth transceiver has a Cortex M4 processor running at 64MHZ. It contains flash memory and 12kb of RAM. The receiver sensitivity is -96dBm and transmitter power of +4dBm. Its typical current consumption is 5mA, but falls to just 1 .6uA when idle. The Bluetooth transceiver also works on a voltage range 1 .71 -3.6V.

Both the temperature sensor and accelerometer communicate with the Bluetooth transceiver through a common bus I2C interface. This is a dual bidirectional bus comprising a clock and a data line. Each device contains its own unique individual address so it alone can be identified for data transfer ahead of fitting and pairing to a waiter's portable Bluetooth device in advance. The connection between the sensor unit and a waiter's Bluetooth capable device will be automatic in response to downloading the application associated with the sensor.

The vibration and temperature sensor 400 also contains a real time counter (RTC) and which can be used with the 32kHz crystal to improve the accuracy of the RTC. The counter will still run when the main clock is switched off which allows the device to be powered down when not in use.

The sensor 400 boots to standby mode when a battery is inserted. It will then display a red light, while it waits until another device (a waiter's phone, or a computer etc.) configures it by setting the clock on the device by writing to its GATT characteristics (defined attribute types containing a single logical value, Bluetooth Low Energy Specifications>GAT XML> GATT Characteristics) via Bluetooth Low Energy. Once the time is set the device will go into its main loop where it monitors for vibration. Optionally, no lights may be visible in a vendible product in order to avoid the product being obtrusive.

In one embodiment of the invention, the time will not be resynchronised and will be left after initial activation on start-up. In other embodiments a staff member's phone may connect to devices to pull data off them, it may also write the time to the device. Error checking/correction in the

Bluetooth/Bluetooth Low Energy protocol and on the device will ensure the time was written properly. This method can be applied at specified intervals as well (all day for the first Monday of the month, or every X connections), rather than every time.

The PCB is a four layer board with single tracks on the outer layer and two inner ground and power planes. This is to reduce crosstalk and noise and provide the support ground plane required for the antenna. In the described embodiment the PCB is 1 .6mm thick with 1 oz (0.028 kg) copper and measures 30mm by 20mm.

The vibration data collected by the accelerometer 402 is reduced before sending it for further processing. For example, the table vibration is averaged every 0.5 seconds of data collected. The difference between an empty table and an individual placing their arm on the table, can be distinguished statistically. The system determines a baseline when the table is inactive. If there is human intervention, this characteristic will be straightforward to identify. For example, if over the span of 20 seconds, this characteristic is determined as "Yes" every 5 seconds it is indicative of persons being present at the table, e.g. one or more people are sat at a table.

The two behaviours or "modes" discussed above are used interchangeably depending on the situation. If a table is vacant, it is useless to collect data as it would be a waste of storage space and battery life. If someone is seated at the table, the vibration level exceeds a background vibration level threshold and the sensor switches to a collect vibration data mode.

The data is then sent to the backend server and processed and analysed which may include using a filter such as a Kalman Filter, or similar filters. This is to help distinguish between anomalous vibration data and table activity, one example being a customer leaving the table to attend the bathroom. The Kalman Filter, or similar filter, reduces the impact on the data from anomalous table activity. The process consists of collecting the vibration data, averaging the XYZ components of the accelerometer, determining a baseline threshold vibration below which vibration data will be discarded, averaged data stored and finally the Kalman filter is applied to determine the average level of activity over time, reducing further the generation of inaccuracies.

The averaged XYZ component values yield a vibration level indicative of table activity. The averaged vibration level provides a characteristic which may be used to distinguish between the types of table activity. If, for example, over the span of 120 seconds the average level of table activity is 3, the table is vacant. If it is 10, someone is sat at the table. If it is 40, someone is eating at the table. More specifically, the sensor collects data and aggregates it at 10 second intervals. Two measures are derived from this: cumulative variance of readings and the number of readings collected above the inactivity threshold. Both these are used to validate the level of human activity with the table.

The baseline threshold for table activity for discriminating between someone walking by the table and actual activity on the table, sets a threshold value that if exceeded will cause the sensor unit to transmit the data to a staff personal device. Even the light touch of a hand on to the table is easily distinguishable from background noise because the difference in the vibration data measured by the accelerometer is statistically significant. For example, when a table is empty the measured acceleration is around +/-0.002g. When a person taps the table with a light touch the accelerometer in the sensor 400 will measure a signal up to +/- 0.02g which is 10 times that of an empty table. Such a difference in vibration is easily statistically distinguishable. One embodiment of the invention uses the staff members' mobile phones or other portable Bluetooth device to connect to the sensors shown in 400. Fig. 5 is a block diagram of the aforementioned staff device. This of course includes a Bluetooth transceiver 502 which can be connected wirelessly with one or more sensor units to transfer the collected data. Waiter proximity data is gathered by using iBeacon technology, which uses relative signal strength to determine the distance of staff to tables. The custom software 510 is downloaded onto the mobile phone 500 and operates to implement data collection and perform some analysis. There is a minimum amount of analysis on the waiter device, e.g. mobile phone, to reduce power consumption.

Software 510 contains Staff Information Interface 504 which shows the analysed information gathered by the sensors and iBeacon technology that may be pertinent to them. Part of the software contains a section for calibration of the sensor units before they begin to collect vibration and temperature data. 508 shows this. Another function of 508 is to provide the world clock data for the sensors, i.e. it will calibrate the timestamps that will be used in the sensor unit. The software may also contain a unit 506 for controlling the Wi Fi transceiver 512. Wi Fi transceiver 512 transfers received data to the backend server through the internet.

Application workload is divided across the active members of staff. For example, if a staff member's mobile phone 500 has a lower battery level than other members of staff, data from the sensors will be uploaded more frequently on other devices.

Optionally, through staff information interface 504 members of staff might be asked to confirm whether or not a situation has occurred in the work place. These would be simple yes or no questions that will be sent out when waiters are inactive. I.e. when waiters are not busy, they may be asked simple questions to improve the accountability of the system. For example, a member of staff might be asked to confirm that "table 5" has been cleaned, or asked how many people are sitting down at table 2, or some other table service activity. Optionally, to reduce manual intervention to a minimum integration of PoS systems with a system such as described herein may be implemented so that manual validation becomes unnecessary or at least infrequent.

Fig. 6 shows a schematic block diagram of the backend server and data management unit 600. The vibration, temperature and proximity data is sent to the database 604 from the internet connected devices 500 with Wi-Fi, Ethernet or mobile networks. The database stores all data collected and the data is analysed by data scientists 602 or Analytic software 606 running on processor 605.

The analysed and processed data is returned to the frontend services 700 which may include a website 702 or client dashboards 704, where client is defined as managers/members of staff. This is depicted in Fig. 7, which is an illustrative block diagram showing the frontend services delivered to the client. The analysis may include, but not be limited to, current table status; average customer wait time; average meal time; performance of staff on the floor; table turnover; restaurant location; number of customers; number of tables; and the like. Such analysis may be conducted in terms of location, employees, customers, order and or tables for example.

A mobile application 704 is installed on the devices 500 and collects the proximity data of the waiters. It is capable of relaying push notifications 128 generated from the backend server 600 to the waiters' devices. For example, if the status of a table is deemed such that the customers have left the table, and there is a long period of it not being cleared away, it will show in a convenient manner this information to the waiter. In general, notifications will be kept to an absolute minimum; i.e. only sent when there is a significant service inefficiency occurring. Other table status may be communicated to the waiters' devices, for example tables need cleaning, customers have been waiting too long, next available table (when restaurant is full), staff member has called in sick, shift has finished, and customers have left a tip and so on. Another instruction or status could be derived from the temperature data collected, letting the waiter know that the local temperature in the proximity of the table is too high or too low. In an ideal situation, notifications will be kept to an absolute minimum and only sent when there is a significant service inefficiency occurring

Managers 120 will be able to access more data through an online website and or mobile device application. This will include the analytics derived from the backend server, for example table turnover; staff performance; stock management; customer experience etc. The data will be able to be accessed by company owners to see how different branches may be performing and so be provided with comparisons and insights between them.

An embodiment of the invention is shown in a schematic diagram in Fig. 8. The system shown in Figure 8 may include components such as those described above with reference to Figures 4 to 7. Referring to Figure 8, general data network 800 consists of the tables 802 with sensors 806 connecting wirelessly with Bluetooth 804 or other similar short range wireless network. Devices 808 have an active internet connection as well as Bluetooth transceiver to send the data collected by the tables using internet connection 810 to backend server 814. The backend server 814 is able to store the processed data in data storage devices such as servers or cloud devices. The

embodiment may have a row-for row temporary storage in a fast noSQL layer, such as Redis. That database would be used to perform backend calculations establishing table state, and

periodic/longer term data would be stored in a database such as PostgreSQL. External data sources 816 are also obtained over the internet and contain information such as weather forecast; trending news/events; economic trends; local events; map information and so on. These are used to provide predictive resourcing based upon comparison of current resource and consumer data (table sensor data) with the knowledge of future external events.

In one embodiment of the invention, an external information source 816 may show an external event near to the restaurant which may be used to give insights into stock management, staff requirements or other data based on prior data analysed by the backend server 814 and stored in database 812. For example, if event A has occurred at a time before the backend server 814 will compare historical data collected from the sensor units, staff proximity data and other sources such as stock management software or point of sale software to give insights to the managers of the establishment in relation to event A, for example, if more than usual of a particular item or dish was sold when event A occurred last time, a restaurant manager may adjust stock ordering

appropriately. In particular, the table activity (vibrational data) may be compared to determine if there was a particularly high throughput of customers i.e. the peaks in the table activity occurred more frequently than usual, or that throughput was slower, i.e. the peaks in the vibration data occur less frequently that usual. Optionally, the activity may illustrate a particular meal format was preferred or more popular during event A, e.g. two course, three course, see Figs. 9a and 9b. This will inform a manager of the likely level of staff required and stock levels. The backend server 814 will provide this information to the managers through the website and or mobile application.

The backend server 814 will send analysed data and insights back to the staff devices 808 through internet connection 810. This will then be able to be accessed by managers via the frontend services 700 in the form of a website or mobile device application. The web application may include a dashboard to visualise the highlights from the insights.

The insights are made available with different levels of granularity such that there are different scales or levels in the set of data. Some illustrative insights are explained in the following paragraphs.

The location opening times can be determined from the proximity data of the staff, table activity and/or background vibrational level. The software is configured to store the timestamps and, over time, with the assistance of statistical analysis, identify the most probable opening or closing times. The users of the software may be asked to confirm this by inputting the opening times manually, and once done the software will be able to suggest opening and closing times based on historical data. For example, it may indicate that the user should open the establishment later based on inactivity logged after current opening times. Important/urgent internal communications can be facilitated through the notification system. For example, if a particular item of the menu is not available all members of staff could be notified at the same time. If a manager is out of the premises but wanted to remind a member of staff of a particular duty, he/she will be able to do so easily. If the company owner wants to make a quick announcement to the entire company, he/she can do so. For example, staff bonuses, important company news, notify members of staff that their efforts are being noticed, etc.

The method of how the acceleration data is collected by the sensor 400 will be described herein with reference to Fig. 10. The sensor 400 only records motion data when people actually cause it (i.e. vibration energy exceeding the threshold level, with minimal background noise). A graph 1000 of activity vs. time is illustrated in Fig. 10, and in this instance, the activity is indicated by the acceleration/g-force data detected by the sensor 400.

When not in operation, the sensor 400 is in low power mode or 'sleep state' 1006, which is to preserve battery life and reduce the amount of data being taken. At a given time, the sensor 400 will be awoken and will take a reading of g-force from the accelerometer for 0.1 -2.0 seconds at the sampling rate of 10-800 Hz; this is called a poll state and is indicated on Fig. 10 by reference numeral 1002. If the measurement of the g-force during the poll state 1002 is below the threshold, then the sensor 400 will be switched back to sleep state 1006 until it switches back to poll state 1002. The time between each subsequent poll state 1002 is called the poll rate 1008. However, if motion above a threshold is detected by the sensor 400 on the first 10 measurements during the poll state 1002, it will proceed with collecting data for the entire 2 second period.

Poll state 1002 occurs responsive to the sensor collecting g-force data above the background noise threshold. In the poll state, which may be considered an active state, readings are taken at a frequency of 50Hz until no readings are recorded above the threshold for greater than 30 seconds. The prolonged poll state collects additional data that is used to validate the accuracy of the readings and confirm average level of table activity. The poll rate 1008 may eventually be optimised

(minimised) based on general location activity. For example, if none of the sensors in a restaurant detect any activity across all tables, the most likely outcome is the restaurant is closed. If this is the case, the polling rate 1008 could be decreased to preserve battery life of the sensor 400.

On each cycle of the sampling (poll state 1002) loop, the sensor samples the g-force affecting each of the axes of the sensors x, y, and z. It then compares this to the previous sample taken (if there is one) by summing the absolute difference between samples for each axis between the consecutive samples. For example, given two samples from the device's accelerometer ( y ζ ) and (x₂, y₂, z₂), the sensor would calculate a difference D between these samples by performing the following calculation:

Each difference D is stored in a 'sliding window' list, which contains the 5 most recent D values at any given time. This will now be referred as the 'difference window'.

When the difference window is 'full' (once it contains at least 5 values), the variance (σ²) of values within that window is calculated for example using Welford's method for computing variance. This method performs a variance calculation in a single pass (single observation of data points), which is more computationally friendly for low-power sensors of the type which would typically be employed in embodiments of the present invention.

Once the variance is calculated, values in the bottom 6.25% (1 /16th - based on current hardware used in the described embodiment) of the average variance range are discarded. This is similar to a low pass filter which removes noise in the vibration data collected by the sensor 400. Anything not cut off by that filter is considered to be observable vibration by the sensor.

In one embodiment of the invention, the sensor 400 is programmed to automatically determine a magnitude or frequency threshold of background noise data: it will initialise a variable "threshold" == 0 at startup. The sensor may only process acceleration data above this threshold. When the table activity is consistently low and out of working hours this threshold will be gradually be adjusted until no data is being recorded. The threshold will be raised to a point where all incoming data is above what could be caused by background noise. All data collected should be a consequence of human activity (with minimal background noise / minor anomalous background noise). Here the definition of low will be: low ==< 1 /1 6th of the data collected for example - I.e. when the table is vacant.

In another embodiment of the invention, the hardware has an activity/inactivity functionality that puts the entire sensor 400 into low power mode when no activity is being detected.

The sensor 400 is configured to calculate its inactivity threshold when being set up by a member of staff. In such a threshold configuration mode, the sensor 400 collects accelerometer readings for 3- 4 seconds, and takes the highest point as an initial threshold. When the table is "inactive" for a set period, ('X' minutes), the sensor 400 restarts the threshold configuration mode to recalibrate the inactivity threshold to improve accuracy.

When the accelerometer readings fall below the determined inactivity threshold for 30 consecutive seconds, the accelerometer reading rate drops to a frequency of 10 Hz or less (thereby reducing accelerometer power consumption to 50 uA) and the firmware puts the system on chip (abbreviated as SoC herein)/Processor (nRF52832) into low power mode (power consumption down to 2 uA). The SoC may reside on a PCB which also supports the accelerometer or may be integrated with the accelerometer. Either configuration may be termed hereinafter as an "accelerometer device" or may be termed or included within the term "sensor". When the accelerometer detects an accelerometer reading above the threshold, it generates an interrupt that wakes both the processor and the accelerometer. When this happens, the accelerometer collects readings at frequency of 50 Hz and the SoC resumes its main loop (collecting, storing, sending data).

The SoC will only be placed in low power mode once all the data previously collected and still stored on the SoC has been transmitted to a waiter's device.

This will allow the accelerometer device to minimise the power consumption. The accelerometer device will only store/send data when the table is determined as being active. When a table is vacant, the accelerometer device will go into low power mode (which will be most of the time).

In a yet another embodiment, an inactivity threshold is calculated for each axis whereby the accelerometer collects a reading for each axis at the same time. For this embodiment these values are between -32767 and + 32767. This means that when completely still the accelerometer does not report (0, 0, 0), but has at least one non-zero value , eg a measurement of (0, 0, 12000). Here the reading in the z axis represents the tilt of the table.

The absolute value of these readings are compared to the axis's inactivity threshold (i.e. the accelerometer axis reading present when the table is vacant and still). The accelerometer reading following calculations are based on a datum accelerometer equivalent to the axis threshold reading. This allows all accelerometer readings to be comparable to one another. The measurement (1 , 1 , 1 ) would mean all axes were subject to the same force - this makes a difference as the following calculations use averages.

Once the inactivity threshold has been subtracted from the axis samples, the samples are aggregated and averaged out: (ABS(X1 ) + ABS(Y1 ) + ABS(Z1 ) )/3. Multiple samples are then compared to obtain the intended output variance. If any of the axis samples exceed their thresholds, the sample is stored. Else, it is discarded because no significant activity is detected.

In a further yet another optional embodiment, when the sensor 400 time is set, it records 3 seconds of table activity - assuming the table is empty. The reading with the highest variance is set as the threshold.

The sensor has a self-calibrating functionality. I.e. when no activity detected above "the initial threshold" for more than 5 consecutive minutes (when the table is most likely vacant), the sensor records 3 seconds worth of accelerometer readings. The threshold would initially be defaulted at the bottom 10 percentile of accelerometer readings. From these readings, it selects the sample with the highest variance from the previous one.

This operation is repeated multiple times, with differing thresholds around the default value, over the first few hours of the sensor being set up - The highest concentration of samples, collected during this threshold establishment procedures, are averaged and set as the threshold, (i.e. take the average of highest variance samples, removing anomalies).

This sets a threshold of activity based on the activity equal to when the table is vacant. To determine an activity threshold, typically under programmatic control of a processor or coded in firmware, sample readings are taken in multiple instances when the table is believed to be vacant. A concentration of similar outputs (+-10% variance) is taken as indicating a likely correct activity threshold.

The following is an illustrative scenario for two people at a one-course meal according to an embodiment of the invention.

1 ) Table Vacant

Two customers enter the restaurant. The table where they will be sat is currently vacant and therefore readings being collected from the sensor are below the activity/inactivity threshold. At this stage, the SoC in the sensor is in low power mode (not sending/storing data). Customers are welcomed by a waiter and accompanied to their table. The mobile device belonging to the waiter is currently in the "search for sensors" state, it collects the proximity data for tables in the vicinity of the waiter. The "search for sensors" state is likely to be the most frequent state the device is in, and will collect proximity data throughout the entire meal. The backend server will not have received new requests for the table where the two new customers are to be seated at this stage, so will be either processing batch events or idle. 2) Customers Seated

This status indicates the start of the meal. When the customers are seated, the movement of chairs and contact with the table will generate a vibration that exceeds the a sleep mode threshold and cause the sensor to switch to "active mode". The sensor is configured to collect acceleration samples at a frequency of 50 Hz and begins processing/sending the information to waiter devices/mobile phones in range. When this occurs, the waiter device/mobile phone further processes this information (ie formatting the data into HTTP requests). The HTTP requests are sent to the backend server through an internet connection. The backend server processes the request and updates the portal's metrics, storing useful information in the database. If the waiter needs to be notified about any processed metric, they will be sent a notification from the backend. This procedure will be similar throughout the entire meal.

Ongoing low table activity is detected at the table, yet comparatively higher than when the table is vacant. Customers may be looking at menus or having a drink - which may increase the reported table activity. The backend server processes the collected data and validates it against a set of conditions. For example, if the table was previously vacant and the table is active for over 1 minute, customers can be said to have been seated.

3) Being Attended (optional)

The restaurant's administrator has enabled the "being attended" table status, allowing the proximity data collected to be used to derive when a waiter attends a table. This status can be set multiple times throughout a meal. Note: this status would require all members of staff to have a

device/mobile phone enabled to have the mobile application on the device for it to work effectively.

The waiter will take the customer's orders and will have to stand next to the table to do so. In this example meal scenario, the waiter has forgotten to attend the customers. Here, the backend server is programmed to check whether a table has been forgotten and sends a reminder notification alert to the waiter's device. Determination of whether or not a table has been forgotten is made based on the time a customer is seated, ie the table acticity status is moved from inactive to active, and a waiter being determined from proximity data as attending the table.

The restaurant's administrator/manager can select their preferred time between when a customer is seated and when the order needs to be checked. This allows a restaurant to customise "wait interval" timings for different stages of a meal. For example, a bar may want a waiter to approach customers 3 minutes after they have been seated, restaurants may want to have waiters approach customers after 6 minutes. The customer service can be customised/modelled significantly to suit the target audience.

Having received the reminder, the waiter heads towards the table and takes the customers' orders. When this happens, the backend server will process the incoming data and validate it against conditions. For example, if the waiter is within 3 m of the table's sensor for more than 20 seconds and the table's status is "customers seated", the backend server will change the table status to "Being Attended".

4) Order Placed (optional)

The customers are attended by a waiter and place their food/drink order. If either the PoS system is linked to the system and/or the "Being attended" table status is enabled, the system will be able to determine when customers have placed their orders. This can be achieved by either linking a PoS System API to the backend server (allowing the system to check if an order has been placed at a specific table), or allowing the backend server to validate conditions to establish the status. For example, the backend server may check if the table has been attended between 3-6 minutes after they were seated. If so, it is likely they have placed an order/have been attended.

5) Customers Eating

After 10 minutes, the waiter returns to the table carrying the two main courses ordered by the customers. The customers start eating and the table activity increases in terms of both (a) number of samples exceeding the inactivity threshold and (b) the cumulative variance of the samples.

The significant increase in table activity alerts the backend server that the customers are eating. The table status is set following the validation of some conditions. For example, in order to change the table status to "customers eating", the table activity must remain above the low activity samples collected when customers were seated for at least 2 minutes.

6) Customers Finished Eating

10 minutes later, the customers have finished eating and they continue their conversation at the table. A waiter could be notified if the plates have not been collected within the indicated timeframe set in the system's settings.

The table activity returns to 'low' and the system can validate the incoming data against present conditions to change the table status to reflect the decline in activity.

When the waiter attends the table, the customers also ask for the bill. 7) Table Vacated

The waiter returns to the table with a credit card machine to take the customers payment. Following the payment, the customers get up and leave the table. The table activity returns below the inactivity threshold and, after 30 seconds, the SoC within the sensor returns to low power mode. The backend server validates the data against a set of conditions to change the table status to "Table Vacated".

8) Table Cleaned (Optional)

Having received the payment, the waiter returns to the counter giving the customers some space to pack up and leave. After 5 minutes, the waiter has forgotten to clear up the table. Since the restaurant also enabled the option receive reminders about tables being cleared for the following customers, the waiter receives a notification reminding the waiter to clear the table.

Once completed, the table is ready for the next customer(s). The mobile devices collect the last data off of the sensors and then stop accepting BLE updates.

In the arrangement described above, the vibration data may be supplemented by external sources of information to validate the "stage of a meal" and/or improve accuracy. For example, if a table is marked as "Customer seated" and a spike in activity is detected, the system may check to see that the PoS system has indeed received a food order at the table before marking it as "customers eating". Alternatively, the system could check that a waiter has attended the table (for example using Bluetooth signal intensity between sensor devices and mobile PoS) to validate that the waiter has actually brought food/drinks to the table.

Fig. 1 1 is an illustrative example of a state diagram for visualising how the three components of the invention interact together: Sensor unit 400, Mobile devices 500, and backend server 600.

The state diagram is split into three rows corresponding to the sensor, mobile device, and backend server respectively.

Sensor State Diagram Description (Fig. 11 a)

The "start" condition 1102 is initialised from the moment the device is set up/enters its main loop. I.e. the sensor's time has been set, the sensitivity and activity/inactivity threshold has been calibrated, the Bluetooth operation has been configured, etc. The sensor's firmware starts in "low power mode". When the accelerometer detects activity below the activity/inactivity threshold, the System on Chip (SoC) enters a low power mode and the accelerometer decreases the sampling rate to 10 Hz. When activity is detected 1104 over the inactivity threshold, the device resumes its main loop/active mode. When the sensor is in active mode, it collects 1106 and stores 1108 samples at 50 Hz. At this point it is important to note that, when determining the activity/inactivity threshold, an activity threshold is identified for each axis. If none of a sample axis' readings exceeds its threshold, the sample is discarded. This means only the relevant data to be transmitted from the sensor (i.e. only data representing human interaction).

Once the sensor collects a sample, it processes this data 1110. Rather than sending the 50 samples per second per axis collected (50 Hz per axis), the data is aggregated and/or analysed 1110. Samples are aggregated at 10 second intervals, requiring a single array of 10 bytes every 10 seconds to be processed/sent. As discussed in the previous passages, the cumulative variance of consecutive readings, over a given period, together with the count of samples exceeding the thresholds satisfying a system setting is used to determine is sensing should continue or not. This may reduce the data being sent significantly whilst giving an accurate indication of table activity. This will also reduce power consumption on both the sending and receiving devices.

Once the samples have been processed, the sensor 400 attempts to establish a Bluetooth connection 1112 with a staff mobile device that has accepted to receive Bluetooth Low Energy Characteristic updates to send the data 1116. If no connection is available the sensor stores the data in the mobile device memory, typically flash memory, to be sent at a later point in time.

Following completion of either of these conditions, the loop restarts 1114. However if there is no activity detected for a certain time, and all the data is sent to the mobile device, the sensor 400 will reenter low power mode 1102.

Mobile Device Diagram Description (Fig. 11 b)

The "start/idle" condition 1117 of the mobile device section of the diagram is initialised following a member of staff downloading and logging into the mobile application. From this point, the devices scan for sensors in proximity at fixed intervals of time 1118. Optionally, the sensor may scan for devices only when footsteps/movements are detected.

When sensors are detected in range, the mobile device connects to the sensor and receives data from sensor 1120. The waiter's proximity and current timestamp are recorded 1122. This is later used by the backend server to determine when members of staff attend tables, together with other useful metrics (e.g. the percentage of time on floorspace). In addition, the mobile device is set to accept BLE characteristic updates from sensors in range. This means that, when a sensor is in range, it will send processed samples of data to the mobile device 1120. Once the data is available on the device, the data needs to be processed again 1123. One example of such processing is, but not limited to, formatting the samples into HTTP requests be sent 1126 to the backend server (via an internet connection) 1124. The information may be stored until enough data has been collected or time has passed to justify the sending of data to reduce power consumption.

Once the data has been sent/stored, the device resumes scanning for Bluetooth Low Energy devices in range at regular intervals.

Backend Diagram Description (Fig. 11 c)

The "start" condition 1127 of the backend section of the diagram is initialised from the moment the server is set up. Once initialised, the backend processes its regular batches to derive metrics - This is an ongoing process that may be run on completely separate threads/machines to the rest of the backend's request processing.

The regular batches are used to further process the data stored in the database. For example, if the system needs to create a monthly average of the table turnover, presenting a monthly average from 10 second intervals of data will not be feasible in the frontend - it would require to send large amounts of data and the devices rendering this information would require a lot of data to be processed. This will lead to inefficient loading/applications crashing etc. The optimal balance between front and backend processing, storing pre-processed information is used where necessary.

When the backend server receives an incoming request connection 1128, the received data 1130 is processed 1132. Live metrics are updated at this stage 1134, allowing the server to return notifications / processed metrics to the mobile devices 1136. The data is also formatted and stored in the database for the batches to further-process the received data 1130.

Fig. 12 is an illustrative flow chart of the calibration method and determination of the inactivity threshold of sensor 400 according to an embodiment of the invention. Following switch on, sensor 400 is automatically in "inactive mode 1202" and therefore collects data at 10 Hz and the processor is powered down immediately. The activity/inactivity threshold is set to the minimum value of 1 for each of the X, Y, Z axes 1204. This is an arbitrary measure that awakens the device when any movement is detected by the accelerometer. Once the sensor 400 detects the vibration 1206 greater than the previously set minimum X, Y, Z threshold, the sensor 400 will then enter active mode and collect data at 50 Hz 1208. These X, Y, Z samples aren't stored, the program

immediately calculates the absolute of the difference between the current X, Y, Z readings and the previous ones 1210. If the X, Y, Z samples are greater than the minimum set threshold 1210 then the sensor 400 subtracts the three axis thresholds (if threshold not set, this is == 0) 1214, adds together the three axis values calculated in step 1214 and divides by three to calculate the average (step 1216). This calculated value of 1216 is now saved as a variable called "Cumulative Difference Variable (CDV)" 1218. Sensor 400 then adds "1 " to the "Cumulative Readings Variable (CRV)" 1220 which is the total number of readings detected above the thresholds over 10 seconds. Step 1222 determines that steps 1208-1220 to determine the CDV and CRV is performed over a 10 second window, and hence 500 readings at 50 Hz. The CDV, CRV and the start time of the 10 second interval is stored and is represented by block 1224 in the illustrative flow chart diagram.

The sensor 400 now repeat steps 1208-1226 to acquire 3 CDV measurements. If there are three consecutive CDV measurements with a percentage difference of less than 10% to one another, the readings are said to be consistent with the little vibration in table activity and therefore highly likely to be vacant 1228. The sensor 400 then collects XYZ acceleration difference samples of 3 seconds at 50 Hz and sets the highest different sample as the XYZ inactivity threshold. This is represented by boxes 1230 and 1232 in the flowchart diagram respectively. The inactivity threshold is only calculated once the sensor confirms that the table is highly likely to be vacant.

Following the calculation of the first inactivity threshold, steps 1208-1226 is performed again and if the acceleration difference readings has a percentage difference less than 10% to one another, it confirms that there was no significant changes both before and after the inactivity threshold was calculated. I.e. highest probability that no-one interfered with the calibration process.

Further embodiments

Figure 14 shows parts of a system in another embodiment of the invention. The system shown in Figure 14 may include components such as those described above with reference to Figures 4 to 8. Parts which are in common with the previous embodiments are given the same reference numerals and are accordingly not described further.

Staff devices

In the embodiments described above, the system optionally requires staff members to carry a mobile device with an application installed to collect and forward information used for monitoring activity. In the embodiment of Figure 14, the mobile device is replaced with an optional staff sensor device 822 which is carried by a member of staff. The staff sensor devices 822 of this embodiment are dedicated devices which are supplied by the management to staff members. Referring to Figure 14, in this embodiment a plurality of staff sensors 822 is provided, each of which is clipped onto each member of staff on duty. Each staff sensor 822 is a dedicated device with a Bluetooth Low Energy module similar to that of the sensor unit 806. The staff sensors 822 connect wirelessly with the sensor units 806 using Bluetooth links 824. This enables the staff sensors 822 and/or the sensor units 806 to determine proximity of the staff sensors to a table 802. Thus, using techniques similar to those described above, the staff sensors can be used to determine when staff members attend tables, their movement activity and ultimately provide additional performance metrics.

Gateway device

In the embodiment of Figure 14, rather than using mobile devices carried by staff members to relay information from the sensor units to the backend server, one or more gateway devices 826 are provided to perform this function. Each gateway device 826 includes its own Bluetooth Low Energy module, a processor, a Wi-Fi transceiver and optionally a cellular network transceiver. A gateway device 826 is installed at an appropriate location in the hospitality establishment where it is within range of some or all of the sensor units 806.

In operation, a gateway device 826 continuously scans for sensor units 806 using the Bluetooth protocol. If a gateway device finds a sensor unit with data that needs retrieving, it connects to it and retrieves the data. The retrieved data is then uploaded via Wi-Fi 810 or a cellular network to the backend server 814. The backend server receives the data and stores it in its database 812.

In this arrangement, the sensor units may form a "mesh network". As a consequence, it each sensor does not necessarily need to be in range of a gateway device. Sensor devices can relay data on to one another until it reaches a gateway device.

Portal

In the arrangement shown in Figure 14, a portal 828 is provided for providing information to managers and senior staff members. The portal 828 is a front-end interface through which processed data from the backend server 814 is displayed. The portal may be provided, for example, on a computer such as a laptop connected to the backend server 814 via a Wi-Fi or local area network connection. The portal is password protected and may link directly to the database 812 to retrieve and display information. The portal may be used to provide the frontend services described above with reference to Figure 7.

In one embodiment, a section of the portal 828 shows a live summary of the restaurant's current state. For example, a floorspace map could be provided which shows which tables are in use, if customers have placed an order, if they have been waiting too long, predictions of how busy the restaurant will get throughout the day, etc. The intention here is to notify staff of anomalies and/or forgotten duties.

The portal 828 may also be configured to display an analytics dashboard. In this case, a section of the portal shows retrospective operational and customer insights. This allows managers to view statistics on an organisational, regional or restaurant level. It shows table turnover analysis, peak hour analysis, customer behaviour insights (average meal time breakdowns), and highlight trends over time. This information may be comparable between restaurants to help identify areas of improvement / changes needed to ensure consistent levels of service.

Interactions

In embodiments of the invention, additional functionality is provided to enable customers to interact with waiting staff.

In one embodiment, the sensor unit 806 is programmed to recognise a particular pattern of vibrations which are provided by the customer. For example, the customer may be informed that they should knock at the table three times if they wish to summon a waiter. In this case, with reference to Figure 4, the sensor control software 406 in the sensor unit is programmed to compare vibration data from the vibration monitor 402 with reference data representing a pattern of three knocks stored in its memory, in order to determine whether a customer has knocked three times. If the sensor control software 406 detects that a customer has knocked three times, then it sends a signal indicating that the table needs attending to the backend server 814 via the gateway 826 or a staff mobile device 808. The backend server 814 then transmits a notification to the relevant staff device indicating that they should attend the table. The notification may be received, for example, on mobile device 808 or a mobile PoS device.

Alternatively, the "knock three times" function may be replaced with other interactions. For example, if the sensor unit 806 is placed on the top surface of the table, then it may include a button on it. The button can be clicked by customers when they wish the table to be attended. For example, the sensor units may be masked as table numbers, which could be pressed down as a button to call a waiter, resulting in the table number flashing to confirm the call. When the button is clicked, the sensor unit sends a signal indicating that the table needs attending to the backend server 814 using the techniques described above. The backend server 814 then transmits a notification to the relevant staff device indicating that they should attend the table. In the above arrangements, the mobile device's Bluetooth signal may be used to determine the distance between the sensor devices and the members of staff. This information may be used to select the most appropriate member of staff to attend the table, thereby increasing customer satisfaction and operational efficiency. Furthermore, it may also allow the system to collect information such as the time difference between when a customer is looking for assistance

(ordering/paying/asking for a food or drink item etc.) and when the waiters actually attend the tables.

The sensor units may also act as a mean of identifying and connecting customers, the tables they are seated at and the business. A customer could, for example, place their phone above a sensor unit which would trigger a notification on their phone. This would cause a notification to pop up and, when swiped, it would open the customer's browser with the options of ordering, paying, calling a waiter, leaving a review associated to the data collected during their meal etc. Similar functionality could be achieved through applications such as Web-Bluetooth and Google Eddystone.

Interface with other systems

The system may also be configured to handle third party application programming interfaces (APIs). For example, if an order is placed on a restaurant's point of sale (PoS) system, the backend server 814 may link to the PoS's API 830 and retrieve the details of the order. Similarly, the backend server may link to a reservation system's API. Data from other systems may be used as additional inputs by the backend system when determining activity or providing metrics.

Machine Learning

In embodiments of the invention, a machine learning processor is provided as a separate element of the system.

Referring to Figure 14, a machine learning processor 832 is shown which is connected to the database 812. The machine learning processor 832 may be, for example, a separate server, or a processor hosted by a cloud computing platform such as Amazon Web Services (AWS). In operation, the machine learning processor 832 reads data from the database 812, compares the readings to machine learning models, and writes the results to the database 812.

As an example, if the state of a table changed from "table vacant" to "activity detected", the machine learning processor 832 retrieves the data from the database 812, determines the probability that a person has just sat down, and stores the result in the database 812. The portal 828 is then able to display the result. The machine learning processor 832 may use, for example, a neural network. A neural network is a network of nodes organised in layers. In a multilayer feed-forward network, each layer of nodes receives inputs from the previous layers. The inputs to each node are combined using a weighted linear combination. The result is then modified by a nonlinear function before being output to the next layer. A backpropagation algorithm is used to calculate the weights in each layer.

In order to provide the machine learning models used by the machine learning processor 832, a machine learning process is performed in advance. In one embodiment, a supervised machine learning process is carried out which comprises the following steps:

1 ) Set up sensor units and gateway device in restaurant.

2) Set up cameras across restaurant.

3) Tag event times using the live camera feed (e.g. customer seated, customer starts eating, etc).

4) Develop binary classification and multi class classification models by mapping the tagged data to the accelerometer readings collected by the sensor units.

5) Run the models to determine whether tables are active/inactive (or other meal states) as data is stored by the machine learning processor.

Figure 15 shows an example of accelerometer readings collected by a sensor unit during a typical meal. In Figure 15, various event times have been tagged using a camera feed. These tagged event times can be used as part the supervised machine learning process.

Figure 15 shows an example of a meal selected at random, and shows one example of the way the data could be processed and presented. However different levels of granularity of data could be used, and different vibration dimensions may be analysed in different ways to determine a table's activity.

Insofar as embodiments of the invention described above are implementable, at least in part, using a software-controlled programmable processing device such as a general purpose processor or special-purposes processor, digital signal processor, microprocessor, or other processing device, data processing apparatus or computer system it will be appreciated that a computer program for configuring a programmable device, apparatus or system to implement the foregoing described methods, apparatus and system is envisaged as an aspect of the present invention. The computer program may be embodied as any suitable type of code, such as source code, object code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language, such as C, C++, C#, Fortran 95, Java, BASIC, Perl, Matlab, Pascal, Visual BASIC, JAVA, .NET, HTML, HTML5, CSS, CSS3, NodeJS, Javascript, Postgres, Swift, Python, Ruby, ActiveX, assembly language, machine code, and so forth. A skilled person would readily understand that term "computer" in its most general sense encompasses programmable devices such as referred to above, and data processing apparatus and computer systems in whatever format they may arise, for example, desktop personal computer, laptop personal computer, tablet, smart phone or other computing device.

Suitably, the computer program is stored on a carrier medium in machine readable form, for example the carrier medium may comprise memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analogue media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD) subscriber identity module, tape, cassette solid-state memory. The computer program may be supplied from a remote source embodied in the communications medium such as an electronic signal, radio frequency carrier wave or optical carrier waves. Such carrier media are also envisaged as aspects of the present invention.

As used herein any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

In addition, use of the "a" or "an" are employed to describe elements and components of the invention. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise. In view of the forgoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention. For example, the vibration and temperature sensors may be in separate housings. Optionally, an embodiment of the invention may comprise just a vibration sensor. A filter other than a Kalman filter may be utilised. Also, a method other than the Welford method may be used for calculating invariance. Various adjectives and terms have been used when describing the sensing of vibration. In general outline, devices measure the magnitude of vibration or typically the total vibrational energy. However, each of those may be referred to as a level of vibration, vibration, acceleration and such like. None of the terms should necessarily be construed in any limited technical or scientific sense but used to refer to detectable vibration unless the context requires otherwise.

For example, one or more embodiments may comprise a user interface such as provided by an application on a smartphone which a member of kitchen staff may use to call a waiter. The member of staff could access the application, tap a button and the closest available waiter will be notified that food is ready to be served. This could be sent as an easily remembered 2/3 buzz vibration - allowing waiters to be provided with notifications without having to look at their devices. There are a number of scenarios where this may useful to let a member of staff know they are needed and is not limited to food or drink service.

Although the term "accelerometer device" has been used in respect of some of the described embodiments, the concept of an accelerometer alone, or accelerometer and system on chip supported on a common substrate (PCB) or an accelerometer integrated with a system on chip may be applied to any of the described embodiments or embodiment or implementation of the present invention. One or more embodiments have been described with reference to a backend server where the data analysis is conducted. Communications with the backend server I sent using HTTP protocols. However, it will be evident to a person of ordinary skill in the art that a local is computer system may be provided which runs the local network within the restaurant or region of interest, collects data from respective waiter wireless devices and provides local processing of the data to push notifications and provide reports concerning activity within the restaurant or region.

Communication with such a local computer system may use a suitable Wi-Fi communications protocol or HTTP communications protocol. Optionally, the local computer system may act as an intermediary to collate information and send it to a backend server for further processing or data analytics.

The terms "accelerometer", "accelerometer device", "sensor" and "system on chip" may all be used interchangeably or refer to slightly different parts of the invention as will be evident from the context in which they are used. Additionally, such terms may generally be considered a sensor module. Although one or more embodiments have been described with reference to the sensing of G force using an accelerometer, a person of ordinary skill in the art will know that G force is not the only vibration characteristic that may be determined. For example, the frequency of vibration and/or magnitude of vibration may optionally or additionally be measured by a vibration sensing device.

The scope of the present disclosure includes any novel feature or combination of features disclosed therein either explicitly or implicitly or any generalisation thereof irrespective of whether or not it relates to the claimed invention or mitigate against any or all of the problems addressed by the present invention. The applicant hereby gives notice that the new claims may be formulated to such features during the prosecution of this application or of any such further application derived therefrom. In particular, with reference to the appended claims, features from the dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in specific combinations enumerated in the claims.

Claims

1 . A system for monitoring activity in a hospitality establishment comprising a plurality of tables, the system comprising:

a sensor unit for attachment to a table, the sensor unit comprising a vibration sensor for sensing vibration of the table at different points in time to produce vibration data, and means for transmitting the vibration data to a central activity monitor; and

2. A system according to claim 1 , wherein the processor is configured to assign an activity status for the sensor unit for each of the plurality of different types of activity.

3. A system according to claim 1 or 2, wherein the different types of activity are different stages of consumption of a meal or a beverage.

4. A system according to any of the preceding claims, wherein the different types of activity comprise at least one of: table vacant; customers seated; being attended; order placed; customers eating or drinking; customers finished eating or drinking; table vacated; table cleaned.

5. A system according to any of the preceding claims, wherein the processor is arranged to analyse values of the vibration data at different points in time, to determine different types of activity at the table.

6. A system according to any of the preceding claims, wherein the processor is configured to produce an average value of the vibration data over a predetermined period of time, to compare the average value with a reference value, and to determine a type of activity in dependence on the result of the comparison.

7. A system according to any of the preceding claims, wherein the processor is configured to compare the vibration data to a mathematical model to determine the type of activity.

8. A system according to claim 7 wherein the mathematical model is a machine learning model.

9. A system according to claim 8, wherein the machine learning model is pre-trained on reference data.

10. A system according to any of the preceding claims, wherein at least one of the processor and the sensor unit is configured to process the vibration data using a filtering algorithm.

1 1 . A system according to any of the preceding claims, wherein the system further comprises a user interface for displaying the determined type of activity at the table.

12. A system according to claim 12, wherein the user interface is arranged to display information indicating the current statuses of the tables in the hospitality establishment.

13. A system according to any of the preceding claims, wherein the central activity monitor is configured to generate a service alert in dependence on the determined type of activity at the table.

14. A system according to claim 13, wherein the central activity monitor is arranged to transmit the service alert to a mobile communications device associated with a member of staff.

15. A system according to claim 14, wherein the service alert indicates an action to be taken by that member of staff.

16. A system according to any of the preceding claims, wherein the sensor unit further

comprises a processor and associated memory.

17. A system according to any of the preceding claims, wherein the vibration sensor is an

accelerometer.

18. A system according to any of the preceding claims, wherein the means for transmitting the vibration data is part of a communications module such as a wireless personal area network module.

19. A system according to any of the preceding claims, wherein the sensor unit includes a

temperature sensor for sensing the ambient temperature to produce temperature data.

20. A system according to claim 19, wherein the sensor unit is configured to transmit the

temperature data to the central activity monitor. A system according to claim 20, wherein the system comprises a user interface for displaying an indication of temperature based on the temperature data.

A system according to any of the preceding claims, wherein the sensor unit comprises an internal clock.

A system according to any of the preceding claims, wherein the sensor unit is configured to transmit timestamps indicating the time at which the vibration data was collected to the central activity monitor.

A system according to claim 22 or 23, where the internal clock is configured to be synchronised with an external device.

A system according to any of the preceding claims, wherein the sensor unit is configured to detect a user action and, in response, to transmit a service request signal to the central activity monitor indicating that the table needs attending.

A system according to claim 25, wherein the user action is an action which produces a predetermined pattern of vibrations, or the pushing of a button.

A system according to claim 25 or 26, wherein the central activity monitor is configured to generate a service alert on receipt of the service request signal.

A system according to any of the preceding claims, further comprising a portable device arranged to be carried by a member of staff, and configured to communicate with the sensor unit.

A system according to claim 28, wherein the portable device and the sensor unit are arranged to communicate with each other using a wireless personal area network.

A system according to claim 28 or 29, wherein at least one of the portable device and the sensor unit is configured to determine proximity of the portable device to the sensor unit, and to transmit a signal indicative of said proximity to the central activity monitor.

A system according to any of claims 28 to 30, wherein one of the portable device and the sensor unit is configured as a beacon that broadcasts an identifier, and the other of the portable device and the sensor unit is configured to receive the identifier and to determine the proximity of the portable device to the sensor unit based on receipt of the identifier.

32. A system according to claim 30 or 31 , wherein the processor is configured to determine the type of activity at the table based additionally on a signal indicative of proximity of the portable device to the sensor unit.

33. A system according to any of claims 28 to 32, wherein the portable device is a mobile

communications device.

34. A system according to claim 33, wherein the mobile communications device is configured to receive the vibration data from the sensor unit, and to transmit the vibration data to the central activity monitor.

35. A system according to claim 33 or 34, wherein the mobile communications device is

arranged to receive a service alert from the central activity monitor, and to provide an indication to a user of the mobile communications device based on receipt of the service alert.

36. A system according to any of claims 28 to 32, wherein the portable device is a dedicated device which includes communications means, such as a wireless personal area network module, for communicating with the sensor unit.

37. A system according to any of the preceding claims, further comprising a gateway device configured to receive the vibration data from the sensor unit, and to transmit the vibration data to the central activity monitor.

38. A system according to any of the preceding claims, wherein the central activity monitor is configured to communicate with another system, such as a point of sale system, an inventory management system and/or a reservations system.

39. A system according to claim 38, wherein the central activity monitor is arranged to receive an input from another system, and the processor is configured to determine the type of activity at the table based additionally on the input from the other system

40. A system according to any of the preceding claims, wherein the sensor unit is operative in a first and second mode, wherein in said first mode the sensor unit is operative to sense vibration at a first periodicity and in said second mode the sensor unit is operative to sense vibration at a second periodicity comprising shorter intervals than said first periodicity, and wherein the sensor unit is operative to invoke said second mode when a vibration value exceeds a threshold.

41 . A sensor unit configured to sense vibration at a table, said sensor unit operative in a first and second mode wherein: in said first mode said sensor unit is operative to sample vibration at said table at a first periodicity, and in said second mode said sensor unit is operative to sample vibration at said table at a second periodicity comprising shorter intervals than said first periodicity; and said first mode is responsive to sampling a vibration exceeding a background threshold level to invoke said second mode.

42. A sensor module configured to sense vibration at a sense station;

said sensor module operative in a first and second mode wherein in said first mode said sensor module is operative to sample vibration at said sense station at a first periodicity and in said second mode operative to sample vibration at said sense station at a second periodicity comprising shorter intervals than said first periodicity and store a vibration sample with a vibration characteristic value satisfying a criterion, said first mode responsive to sampling a vibration having a said vibration characteristic value exceeding a first threshold value to invoke said second mode.

43. A sensor module, unit or system according to claim 41 or 42, or a system according to claim 40, further operative in said second mode to invoke said first mode responsive to sampling a vibration having a vibration characteristic value less than a second threshold value for a vibration characteristic measurement time interval.

44. A sensor module, unit or system according to claim 43, further operative in said second mode to calculate the variance of a plurality of vibration characteristic values derived from a corresponding plurality of vibration samples.

45. A sensor module, unit or system according to claim 44, further operative in said second mode to collect said plurality of vibration samples within a time window of a length such that at least two said time window may fit within said vibration characteristic measurement time interval.

46. A sensor module, unit or system according to claim 44 or claim 45, wherein said criterion is said vibration sample comprises a vibration characteristic value falling above a lowest range of said variance.

47. A sensor module, unit or system according to claim 46, wherein said lowest range is the bottom

50%, preferably the bottom 33%, more preferably the bottom 25%, yet more preferably the bottom 12.5% and even more preferably the bottom 6.25% of the variance.

48. A sensor module, unit or system according to any of claims 40 to 47, comprising a

communications module and operative to transmit a vibration data signal representative of said vibration characteristic value to a system communications module of a sensor system.

49. A sensor module, unit or system according to claim 48, operative to transmit said vibration data signal responsive to receiving a signal indicative of said system communications module ready to receive said signal.

50. A sensor module, unit or system according to any of claims 40 to 49, operative in a calibration mode to:

take a first plurality of vibration calibration samples over a sample period;

assign a greatest vibration characteristic value of said plurality of vibration calibration samples as a vibration characteristic threshold value;

periodically take vibration samples after said sample period;

take a second plurality of vibration calibration samples over a subsequent sample period responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and

assign a greatest vibration characteristic value of said second plurality of vibration calibration

samples as a vibration characteristic threshold value.

51 . A sensor module configured to sense vibration, operative in a calibration mode to: take a first plurality of vibration calibration samples over a sample period;

periodically take vibration samples after said sample period;

take a second plurality of vibration calibration samples over a subsequent sample period responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and assign a greatest vibration characteristic value of said second plurality of vibration calibration samples as a vibration characteristic threshold value.

52. A sensor system, comprising:

a sensor module or unit according to any of claims 41 to 51 ; and

a central station configured to receive said vibration data signal;

wherein said central station is configured to assign an activity status for the sense module from an analysis of one or more of said vibration data signal communicated from the sensor module.

53. A method of monitoring activity in a hospitality establishment comprising a plurality of tables, the method comprising:

transmitting the vibration data to a central activity monitor;

receiving the vibration data at the central activity monitor; and

54. A method of operating a sensor module configured to sense vibration at a sense station, said method comprising said operating said sensor in a first and second mode wherein in said first mode said sensor module is operative to sample vibration at said sense station at a first periodicity and in said second mode operative to sample vibration at said sense station at a second periodicity comprising shorter intervals than said first periodicity and store a vibration sample with a vibration characteristic value satisfying a criterion, said first mode responsive to sampling a vibration having a said vibration characteristic value exceeding a first threshold value to invoke said second mode.

55. A method of operating sensor module configured to sense vibration, comprising invoking a calibration mode comprising:

taking a first plurality of vibration calibration samples over a sample period;

assigning a greatest vibration characteristic value of said plurality of vibration calibration samples as a vibration characteristic threshold value;

periodically taking vibration samples after said sample period;

taking a second plurality of vibration calibration samples over a subsequent sample period

responsive to no vibration characteristic value of said second plurality of vibration calibration samples reaching said vibration characteristic threshold value; and

assigning a greatest vibration characteristic value of said second plurality of vibration calibration samples as a vibration characteristic threshold value.