CONNECTED FACILITY SYSTEMS

Abstract

This disclosure relates to a management system that coordinates an interoperable mesh of technologies and devices to manage a hospitality facility. This disclosure further relates to the identification of key issues associated with hospitality and facility management to address with management systems of this disclosure so as to provide a management system that is cost-effective and maximizes facility profitability.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to, and the benefit of, U.S. Provisional Application No. 62/979,617, filed on Feb. 21, 2020, the content of which is incorporated by reference herein in its entirety.

FIELD OF INVENTION

This disclosure relates to systems and methods for managing a hospitality facility.

BACKGROUND

Managing operations of a hospitality facility (e.g., a resort, a hotel, a cruise ship, a condominium, a conference center, a health club and/or spa, a dining facility, and the like) is particularly challenging because of the many issues that frequently arise. For example, property and facility managers must monitor and manage the many different components associated with both hospitality and the facility itself, including room bookings, guest accommodations, workforce management, and maintenance of facility infrastructure. Accordingly, property and facility managers must be able to efficiently address various hospitality- and facility-related issues that may arise, while simultaneously meeting guest expectations and ensuring profitability.

SUMMARY

The present invention relates to systems and methods for managing a hospitality facility through an interoperable mesh of technologies and devices. For example, management systems and methods of the present disclosure combine a wide range of different technologies (e.g., computers, networks, software, sensors, etc.) to manage and address distinct issues associated with hospitality and facility infrastructure with one centralized and integrated system. The management systems and methods of the present invention can be configured to accommodate any number of different facility systems and devices, thereby resulting in a highly scalable and customizable management system. Furthermore, management systems and methods of the present disclosure leverage individual capabilities of different systems and devices associated with a given facility (e.g., smartphones, sensors, in-room devices, etc.) to accomplish a variety of different tasks. The activities of the different systems and devices are coordinated by integrating the respective operation of each into a unified management system having a single control point. The single control point allows a property or facility manager to efficiently monitor and direct operations of the different systems and devices across the facility.

More specifically, management systems of the present invention coordinate activities of different systems and devices (e.g., a guest device, a staff device, or a device integrated into the facility) by managing the exchange of data between those devices over a network. In some instances, management systems use software applications to provide and manage communication among different devices. The exchange of information preferably occurs over a wireless network. Because management systems use wireless communications to coordinate activities of different devices, integration of management systems described herein can be integrated into a facility having a single room as easily as a facility having any number of rooms or spaces and are also well suited to accommodate facility growth (e.g., increase in overall room number).

A particular advantage of the management systems of the present invention is that such systems are able to monitor various aspects of hospitality and facilities management, further identify specific issues associated therewith, and subsequently provide actionable management over such issues. As will be described in greater detail herein, the various issues may generally involve access, environment, illumination, occupancy, and utilities associated with a given facility. By focusing management system resources on those key areas of hospitality and facility management, costs associated with integration and maintenance of a management system into a facility are tailored to those areas of hospitality and infrastructure, wherein such areas are most likely to drive facility revenue. In addition to driving facility revenue, the management systems and methods described herein are able to more efficiently manage hospitality and facility-related tasks by deriving actionable insights from any given individual, thereby cutting down on excessive waste and costs. Accordingly, the management systems and methods are able to contribute to the sustainability of both the environment and humans using such facilities.

In one aspect, this disclosure relates to a management system for managing a hospitality facility. This system is operable to communicate and exchange data over a network with a plurality of different devices, including, a guest device, a staff device, and a device that is operably associated with the facility (e.g., locking device). More specifically, the system involves a processor coupled to memory containing instructions executable by the processor to cause the central information system to receive data from at least one of the plurality of devices, wherein at least a portion of the data comprises unique identification information (e.g., a unique device identifier). The system is further operable to query a database that includes authentication information and generate an output based, at least in part, on data received from the plurality of devices and results of the query. The output is provided by the system to at least one of the plurality of devices or a property management system. The output may include, for example, instructions to adjust operation of a device connected to the facility.

By communicating with multiple different devices over a network (e.g., a cloud-based network) the management system is operable to coordinate aspects of facility management across the different devices. At least one of the devices may be a guest device (e.g., a guest's personal smartphone). At least one of the devices may be a staff device (e.g., an employee's smartphone). And at least one of the devices may be a device connected with the facility (e.g., a locking device, or a sensor). By communicating with different devices, the management system leverages capabilities of various devices to accomplish specific tasks and facilitate management of the facility.

For example, the management system may communicate with a device connected to the facility, e.g., an in-room device, which may include at least one of one of a locking device, a thermostat, an entertainment device, or a light. Preferably the system is operable to communicate with more than one device connected to the facility, and more preferably, the system is operable to communicate with more than one of multiple types of devices connected to the facility, for example, at least two of a door lock, a thermostat, an entertainment device, or a light. The system, by exchanging communications over a network, is operable to regulate operations of each of those devices automatically or based on input from, for example, a guest operating a guest device, a staff member operating a staff device, or at a facility manager. Communications among the various devices are preferably coordinated using data hubs or nodes. The hubs may be operably associated with specific devices within a room. Communications from a management system can be effectively directed to specific devices by routing said communications to the hubs. The hubs may also collect, store, and/or transmit data from one or more devices to the management system. By relaying signals through a hub, the number of individual data streams are reduced, thereby improving communication efficiency.

In preferred embodiments the guest device includes a smartphone running an application configured to communicate and exchange data with the management system. Preferably, the application includes an interface configured to receive input from a guest associated with the device. The interface may be configured to receive input in connection with at least one of, for example, accessing a room, adjusting room temperature, adjusting an entertainment device, changing room ambiance, or making a room service request.

For security, systems of the invention include mechanisms to authenticate data received from a device. Authentication of a device helps ensure that a device from which data is received is associated with a guest and/or a room of the facility. This may be used to verify, for example, that a guest requesting room access with a guest device are occupants of the room for which access is requested. Accordingly, a portion of data provided by a device includes unique identification information. The system is operable to query a database that includes authentication information having identification data associating a guest and a registered room of the facility. The system may be configured to authenticate data received from the plurality of devices by correlating unique identification information of one of the plurality of devices and authentication information from the database.

In addition, for security purposes, communications between devices may be encrypted. For example, data received by the system from a guest device, a staff device, or a device connected to the facility may be encrypted data, including, for example, hash-based message authentication code.

The management systems of the invention provide output based on data received from devices. The output may include computer-readable instructions for adjusting operation of a device connected to the facility. The computer-readable instructions are processed by the device connected to the facility and may thereby result in a change to, for example, a status of a locking device, an adjustment in air temperature, an adjustment in room lighting, or an adjustment to an entertainment device.

In other instances, the output may include data that relates to a custodial or maintenance task. The data is preferably viewable on an interface of the staff device. The interface may be configured to receive input from a staff member associated with the staff device in connection with the custodial or maintenance task. For example, identifying that a task or assignment is complete.

The management system may be configured to update information stored in a database based on authenticated data received from one of the plurality of devices or the property management system. For example, the update may be in connection with information that associates a room of the facility with a guest and results in a change to authentication information. The update may be in connection with a room service request. The update may be in connection with a custodial or maintenance task. The update may be in connection with an operational status of the device connected to the facility.

The management system can provide an output to a property management system, e.g., a system operated by a property manager. The property management system may comprise an interface that is configured to receive input from a property manager. This interface may allow the property manager to control one or more parameters of the system. For example, the one or more parameters may include operational parameters of the device connected to the facility. Input from the property manager may also be used to change information stored in the database, e.g., guest room assignments.

In preferred embodiments, management systems of the invention include one or more sensors operably associated with the facility. The one or more sensors may sense signals and collect data relating to facility utilities (e.g., energy consumption). The data may by associated with individual devices of the facility to identify whether the device is operating within certain parameters. The data may be analyzed by a software analysis program or service associated with the management system and provided to a facility manager, an owner, or staff. The data can identify costs relating to facility management. The data may be used to make informed decisions relating to facility upgrades.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary management system for managing a hospitality facility.

FIG. 2 shows interoperable features of a management system.

FIG. 3 shows a block diagram of a guest device application.

FIGS. 4A-4D show screenshots of a guest device application.

FIG. 5 shows a block diagram of an exemplary staff device application.

FIGS. 6A-6D shows screenshots of an exemplary staff device application.

FIG. 7A is a screenshot of an exemplary dashboard interface provided by management system software consistent with the present disclosure. FIGS. 7A-1, 7A-2, 7A-3, and 7A-4 are enlarged screenshots of the dashboard interface, showing various metrics.

FIG. 7B is a screenshot of an exemplary booking management interface provided by management system software consistent with the present disclosure. FIGS. 7B-1 and 7B-2 are enlarged views of portions of the booking management interface.

FIG. 8 shows a block diagram illustrating aspects of an exemplary locking device.

FIG. 9 shows a front view of an exemplary locking device.

FIG. 10 shows an exploded view of an exemplary locking device.

FIG. 11 shows an exemplary data hub.

FIG. 12 shows a deployment scenario of an exemplary data hub.

FIG. 13 shows a block diagram of an exemplary management system.

FIG. 14 shows a block diagram of an environment control system.

FIG. 15 shows an exemplary energy sensor for use with a management system.

FIG. 16 shows an air quality sensor for use with a management system.

FIG. 17 shows correlations between outputs of air quality sensor and air quality.

FIG. 18 shows a diagram of an analytical software system.

FIGS. 19A and 19B are an exemplary screenshots of an interface provided on a user's device displaying various data to a user. FIGS. 19A-1, 19A-2, and 19A-3 are enlarged views of interfaces showing data relating to room availability, occupancy status, and sensor status, respectively. FIGS. 19B-1 and 19B-2 are enlarged views of interfaces showing data relating to booking references and guest reviews.

FIG. 20 shows an exemplary management system following a Message Queuing Telemetry Transport architecture.

FIG. 21 shows a block diagram illustrating mutual authentication.

FIG. 22 identifies pathways for operating exemplary components associated with a server.

FIG. 23 identifies exemplary server components of a management system.

FIG. 24 illustrates connectivity among components of an exemplary management system.

FIG. 25 diagrams inter-system communications of a management system.

FIG. 26 shows a block diagram illustrating server connections.

FIG. 27 shows a block diagram of a device manager.

FIG. 28 provides a block diagram of a facility manager component.

FIG. 29 shows a block diagram of an alarm manager.

FIG. 30 shows a block diagram of a notification engine.

FIG. 31 shows a block diagram of a schedule manager.

FIG. 32 shows a sequence diagram for installation and commissioning of sensors and a data hub with configuration data.

FIG. 33 shows a sequence diagram of a firmware upgrade process.

FIG. 34 shows a sequence diagram for a hotel site setup.

FIG. 35 shows a sequence diagram for maintenance.

FIG. 36 shows a sequence diagram for guest check in.

FIG. 37 shows a sequence diagram for a guest check out.

FIG. 38 shows a sequence diagram for room server management.

FIG. 39 identifies issues addressed by an exemplary management system.

DETAILED DESCRIPTION

Rising energy costs, maintenance, and security are some of the important challenges that must be addressed by hospitality facility managers. Unfortunately, addressing these challenges is complicated by the many competing issues associated with hospitality, e.g., meeting guest expectations while maintaining profitability. While some individual solutions to those challenges exist, implementing individual solutions into a facility can be inefficient, difficult, and expensive. Accordingly, management systems that coordinate computer devices across a facility to address multiple issues are lacking. As such, it is an object of the invention to provide a fully integrated management system that addresses distinct issues of hospitality and facility management from a common control point.

A major advantage of a management system according to this disclosure lies in the ability to address issues associated with hospitality and facility infrastructure with cost-effective solutions to maximize profitability and improve overall experiences of guests at a hospitality facility. For example, specific issues relating to hospitality may include controlling access to rooms and maximizing guest control over their own experience within the facility. Issues relating to facility infrastructure may involve managing expenses associated with certain high-cost utilities (e.g., energy consumption). Embodiments of the invention therefore implement cost-effective mechanisms for monitoring, reporting, and regulating facility use of such utilities while providing guest control over certain devices connected to the facility. More particularly, as described herein, preferred embodiments of the invention provide management systems that address a plurality of issues associated with access, environment, illumination, occupancy, and utilities.

In a broad sense, the invention is directed to a unified facility management system comprising an interoperable mesh of various technologies and devices, which may include, occupant databases, access control systems (e.g., door locks), temperature monitors, energy monitors, workforce management systems, staff or guest devices, and analytical software. The devices are integrated into a management system that addresses challenges associated with facility infrastructure and hospitality from a single point interface for cost-effective and efficient facility management.

FIG. 1 illustrates an exemplary management system 101. The management system 101 is uniquely designed for managing a hospitality facility by addressing issues relating to both hospitality, and facility infrastructure. In particular, issues addressed by the management system 101 preferably include issues involving access, environment, illumination, occupancy, and utilities.

The hospitality facility may be any facility related to guest entertainment or lodging, for example, a hotel, a resort, an inn, a club, a dining facility, a conference center, a cruise ship, etc.

The management system 101, which may be embodied on an internet-based computing system, manages (e.g., controls, oversees, handles) certain aspects of a hospitality facility by communicating and/or exchanging digital information with a plurality of devices 109 over a network.

In general, the management system 101 involves a mesh network of technologies integrated with one another and used to monitor or control various aspects of facility management with the devices described herein. In particular, the management system 101 includes a computer 103 having a processor coupled to memory containing instructions executable by the processor to cause the system 101 to communicate and exchange data over a network 105 (e.g., a Wi-Fi network) operably associated with the computer 103 to regulate operations of different devices within the system and thus perform various tasks.

The management system 101 is operable to communicate (e.g., send and receive digital information) with a plurality of devices 109. The plurality of devices may include a guest device 111, a property manager device 113, a staff device 115, and at least one device connected to the facility 133. As used herein, devices connected to the facility include devices associated with a particular facility. The devices connected to the facility need not be physically (e.g., wired or otherwise installed) connected to a facility. Devices connected to the facility 113 include devices associated with particular rooms, such as guest rooms, and may include a locking device 117, a data hub 141, or a sensor 135. Preferably, the management system 101 is operable to communicate with multiple different devices connected to the facility 135, for example, at least two or more of a locking device 117, a sensor 135, and a data hub 141. More preferably, the management system is operable to communicate with a plurality of each one of a locking device 117, a sensor 135, and a data hub 141. For example, the facility may comprise at least two guest rooms and each of those two rooms may have a locking device, a sensor, and a data hub.

The management system 101 is configured to receive data from at least one of the plurality of devices 109. A portion of the data received preferably includes unique identification information for authenticating the respective device. The unique identification information may comprise, for example, a unique identifier (UID). A UID is a numeric or alphanumeric string that is uniquely associated with a device within a given system. UIDs make it possible to address that device, so that it can be accessed and interacted with.

The system 101 may be operable to query a database 121 that comprises authentication information. The authentication information may comprise data identifying a UID associated with a device of a guest or staff, for example. The system 101 may be operable to compare or correlate unique identification information received from one of the plurality of devices with the authentication information to assess whether the device is authorized to send a communication over the network. The management system 101 generates an output based on data received and results of the authentication assessment. The output may be provided to a different one of the plurality of devices 109 and/or a property management system 125.

The output may include computer-readable instructions that control operations of a device connected to the facility 133, e.g., a device found in a guest room, such as, a locking device 117. The output may be responsive to data received from a guest device or a staff device. Accordingly, the management system 101 provides a mechanism for a guest to operate a device in the guest's room. In other instances, the output may include, or be based on, data received by one or more sensors 135. The output may be provided to a property management system 125 (e.g., a computer system operated by a property manager or owner) or a data analysis system 131.

One important aspect of the management system 101 involves the collection and analysis of data relating to facility operations, e.g., utilities. As discussed in detail below, devices connected to the facility 133 preferably include sensors 135. The sensors 135 include devices that sense and provide data relating to, for example, utilities. For example, the sensors 135 may comprise sensors for sensing and providing data relating to energy consumption and/or air quality. The data may be collected and provided directly to a property management system 125 or a data analysis system 131. Analysis of the data provides facility managers, owners, staff, etc., with valuable information for assessing aspects of the facility including facility infrastructure (e.g., operational status of devices), profitability, and occupant health. The data may be used by facility managers to identify, for example, areas of the facility with higher utility expenses, e.g., rooms consuming more energy. Identification of higher utility expenses is valuable for prioritizing facility upgrades and maximizing profits.

By communicating with multiple different devices over a network 105 the management system 101 is operable to coordinate aspects of facility management across a plurality of different devices 109. Integration of different devices 109 into one integrated network 105 provides a secure and reliable mechanism for one of the plurality of devices 109 (e.g., a guest device 111) to control operations of a different device, such as, a device inside the guest's room (e.g., a television). By enabling communications across different devices, the system 101 leverages capabilities of any number of different devices to accomplish specific tasks, thereby maximizing guest control of their experience, and facilitating management of the facility with one integrated management system. For security, the communications may use digitally encrypted code, such as, for example, hash-based message authentication code.

Communications across the devices 109 are enabled by the network 105. The network 105 may be any network that carries data. However, the management system 101 is not limited by any particular network type. Non-limiting examples of suitable networks that may be used as network 109 include Wi-Fi wireless data communication technology, a personal area network (PAN), a local area network (LAN), a wireless local area network (WLAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), a storage-area network (SAN), a system-area network (also known as SAN), a passive optical local area network (POLAN), an enterprise private network (EPN), a virtual private network (VPN). digital subscriber link networks (DSL), various second generation (2G), third generation (3G), fourth generation (4G), fifth-generation (5G) cellular-based data communication technologies, Bluetooth radio, Near Field Communication (NFC), the most recently published versions of IEEE 802.11 transmission protocol standards, other networks capable of carrying data, and combinations thereof. Preferably the network comprises a cloud-based network, e.g., the internet comprising certain accessible databases. In some embodiments, a communication path between any one of the devices within the system 101 may be, in whole or in part, provided by a wired connection.

In preferred embodiments, communications between devices over the network 105 are facilitated by a data hub 141. The data hub 141 improves efficiency of the management system 101 by, for example, reducing the number of different devices that a computer of the management system 101 communicates with directly. For example, preferably, the data hub 141 is operably associated with devices connected to the facility such as one or more devices of a particular guest room. Communications from the system 101 may by transmitted to the hub 141 and from the hub 141 transmitted to a respective guest room device. The data hub 141 can improve communication efficiency within the computers of the management system 101 by directing those communications. In one aspect, the data hub 141 improves efficiency of communications over a network by reducing the total number of devices that talk to each directly. In addition to improving efficiency, data security is improved, as the data hub 141 may be operable to authenticate devices communicating over the network before communications from one device or system are transmitted to a different device or system.

FIG. 2 shows interoperable features of a management system 201. In particular, illustrated are exemplary associations between certain features of a management system 201 and the interoperable mesh of various technologies and devices associated with that system 201.

Features of the management system 201, for example, may include information that is controlled or influenced by input of a facility manager operating a property management system 221. The property management system includes a computer having a processor coupled to memory containing instructions executable by the processor to cause the system 201 to communicate and exchange data over a network. The property management system 221 may comprise an interface 223 configured to receive input from a facility manager, a property manager, an owner, or the like. The property management system 221 may include administrative features for adjusting parameters of the management system 201, for example, providing authorization of staff or guest devices for exchanging data over a network. The parameters may be adjusted by any input through the interface 223 that causes changes in data information stored in one or more databases.

Some features of the management system 201 include, but are not limited to, providing guest offers and event bookings 203, managing facility maintenance and workforce 205, and/or collecting and viewing data related to facility infrastructure 209. It may be desirable that each of those features 203, 205, and 209, involve data input from the facility manager. As such, the management system 201 is preferably configured to provide a bidirectional flow of information between a property management system 221 and other devices associated with the management system 201.

Features of the management system 201 may further include features associated with at least one of guest and property access management 227, energy management 229, or comprise a communication engine 231. Information relating to those features 227, 229, and 231, may not, in some instances, require input from a facility manager. Information relating to those features 227, 229, and 231 may be handled on the backend by computers and associated devices of the system 201. The facility manager may, however, make adjustments to one or more databases, for example, providing an update to a guest database identifying registered guests, which is used by the system 201 to then manage guest access automatically without further input from a manager.

The management system involves communicating and sharing data with a plurality of different devices. To communicate with the different devices, elements of the management system may involve certain software applications hosted by the devices. The software may be stored on a server and downloaded onto the devices. The software may comprise control logic that, when executed by a processor of the device, causes the processor to perform the functions of the invention as described herein

FIG. 3 shows a block diagram of a guest device application 301. In particular, the block diagram is related to an application 301 for a guest device running an Android-based operating system.

The guest device, as it pertains to this disclosure, may relate to any computing device that is under a guest's control and is operable to exchange data with the management system. The guest device may include, for example, any one of a personal computer, a mobile communication device, e.g., a smartphone, a tablet, a wearable device, or any other device comprising a computer and operable to communicate digital data over a network. In preferred embodiments, the guest device comprises a smartphone, (i.e., a phone that is enabled to communicate over the internet). Communications with management systems of the invention are facilitated by the application 301, which enables communications to be exchanged with the management system over the network from a user-friendly interface.

In particular, the guest device preferably runs the application 301 using computer-executable instructions contained in memory of the device. In preferred embodiments, the application 301 is installed onto a guest device by the guest. The application 301 may be downloaded and installed from a sever associated with the facility.

For example, the guest device application 301 may be a hospitality facility associated application, such as, the guest device application sold under the trade name Porta by Caleido. Although, the embodiment illustrated comprises an Android-based application, a person of skill in the art will recognize that a similar application may be provided for compatibility with an iOS operating system. The application 301 may comprise Java code. The application 301 code is configured to provide a guest with access to a core set of functions relating to the facility. The application 301 preferably includes an interface 305 with a flexible design layout that allows for the customization of a guest experience. The interface 305 may be fine-tuned for compatibility with parameters of the facility. Some fine-tuning may be performed by a facility manager through, for example, an application associated with the facility, for example, a facility application provided under the trade name Ikanos by Caleido.

Preferably, the guest device application 301 is installed on a guest device of each guest to provide control of the guest's experience at the facility. For example, the guest device application 301 may enable the guest device to communicate with the facility management system through an interface 305 so as to manage, for example, time of check-in, control aspects of room climate (e.g., an air conditioning setting), send requests for room cleaning, and/or provide room access for management and security.

For example, preferably within premises of a facility, a guest can interact with an interface 305 of the application 301 to provide input for unlocking or locking a door of the facility. The interface 305 may be designed to receive different types of input from a guest, including, making a request for room service. The interface 305 may be configured to receive input from a guest for controlling one or more devices connected to the facility, such as, electronic devices associated with a particular room. Preferably, the application interface 305 is configured to receive input from the guest to manage one or more of accessing a room of the facility (e.g., opening a door lock), adjusting room temperature, adjusting an entertainment device (e.g., turning on or off a television), changing room ambiance (e.g., turning on or off a light), or making a room service request. For example, through the guest device application, the guest can make a maintenance or cleanup request, and authorize and/or schedule any such request.

The application interface 305 may provide data relating to alerts or notifications for specific information or events. Some of the notifications may relate to room bookings, access key control, identify when a guest room is unlocked or locked, or relate to emergency information, such as, instructions related an evacuation. The application 301 may also be used to view or adjust room related activity, including, room temperature, air quality, and air conditioner settings. In other instances, the application 301 may function as a marketing tool. For example, a facility manager may send an offer, advertise a special event, send an invite, etc., to a guest through the application. The guest may receive a notification on the guest device and may respond to the offer through an input receivable by the interface 305 of the application 301.

Preferably, the application 301 includes computer-readable instructions for interacting with drivers 309, e.g., kernel drivers, of the guest device. The drivers may include a Bluetooth driver, a wireless driver, an audio driver, etc. A Bluetooth driver, for example, may be used to send communications for locking or unlocking a locking device of the facility. The Bluetooth driver may be used to send or receive data relating to a status of a locking device. An audio driver may be used to provide audio associated with alerts or notifications. In some embodiments, functionality of a driver, e.g., a wireless driver, a may be controlled through a software of the management system.

FIGS. 4A-4D show screenshots of a guest device application.

FIG. 4A shows an exemplary check-in screen of a guest application. The screen may include information relating to guest checking, such as, time and day of check in/check out, number of guests, room number, etc.

FIG. 4B shows a screen of a guest application homepage. The homepage identifies a guest's room and includes a menu of options selectable by the guest by, for example, touching the screen of the guest device to select the menu option. Options may include hyperlinks to webpages with various room amenities, bath amenities, concierge amenities, dining services, offers, events, etc.

FIG. 4C shows a screen of a guest application room unlock page. The unlock page may include an option for sharing a key with another guest.

FIG. 4D shows a screen of a guest application for making an amenities request. In particular, the screen shows various bath amenities that may be selected by a guest for delivery to a guest room.

Management systems of the invention are also operable to communicate, over a network, with one or more staff devices. A staff device is an electronic device under control of a staff member associated with the facility. The staff device may be operable to request and receive information over a network (e.g., a cloud-based network). The staff device may include any one of a personal computer, a mobile communication device, e.g., a smartphone, a tablet, a wearable device, or any other device comprising a computer and operable to communicate digital data over a network. In preferred embodiments, the staff device comprises a smartphone, (i.e., a phone that is enabled to communicate over the internet). To communicate with systems of the invention, the staff device preferably hosts an application to send and receive data with the management system (or devices associated with said system) over the network.

In preferred embodiments, a staff device runs an application operably associated with a management system of a facility. The application may be installed onto the staff device. The application may be downloaded and installed from a media content database associated with the facility.

FIG. 5 shows a block diagram of an exemplary staff device application 501. In particular, the staff device application 501 relates to an application for a staff device running an Android operating system. Similar staff device applications may be designed for execution by devices running an iOS operating system.

For example, the staff device application 501 may be a hospitality facility associated application, such as, the application sold under the trade name Cheirismo by Caleido. The application may comprise one of an Android-based application or an iOS-based application. The application may comprise Java code or Swift code. The application code may be configured to enable a staff to access a core set of functions relating to management of a facility. The application preferably includes an interface with a flexible design that allows for the customization of staff device features and/or to be fine-tuned for compatibility with parameters of the management system of a facility. Some fine-tuning may be performed by a facility manager through, for example, an application associated with the facility itself, for example, a facility application provided under the trade name Ikanos by Caleido.

The staff device application may be an Android-based application designed to accommodate multiple different employee roles, e.g., a floor manager and/or a maintenance staff. Alternatively, the staff device application may be tailored around a specific employee role. For example, a floor manager may run an application with features specific to performing duties of a floor manager while a maintenance or custodial staff device runs an application hosting features specific to their duties.

For example, a device of a staff member serving a maintenance role may comprise an application with a maintenance role interface 503. Accordingly, the interface may be tailored to the needs of maintenance staff. Tailoring the interface around a staff member's role at the facility can make the application more user friendly and improve security by restricting certain software features. The maintenance role interface 503, for example, may be restricted to exchanging data relating to alerts and notifications, task assignments and status, or issue reports.

A corresponding device of a floor manager may comprise an application 501 with an interface tailored to the duties of the floor manager. The interface 505 may include features that relate more particularly to a floor manager's assignments, e.g., day-to-day management tasks. For example, the interface 505 be configured to receive input that identifies an area of a facility (e.g., a guest room) in need of maintenance or custodial attention. When scheduling an assignment, the floor manager may assign a specific task within one or more room as part of a schedule that is assigned to staff (e.g., electricians, plumbers, custodians). The interface may also be configured to receive input from the floor manager to operate devices connected to the facility, for example, to lock or unlock a room, e.g., for a scheduled maintenance or repair, or to initiate an emergency alarm in case of fire or emergency, and/or to view alerts or notifications, including, notifications identifying activities within a facility.

In addition, a manager may use a staff device application to add or assign roles to staff for a given time period. The assignments may include authorization to access one or more rooms of the facility. This authority, however, may time-out at the end of a day or shift or within a time period as mandated by property owners.

The floor manager may also use the application to facilitate customer loyalty by advertising events or functions associated with a facility. In addition, hotel management may use the application to post special promotions, rewards, discounts, or coupons.

Staff members of a facility may be required to have a staff device application installed on their personal devices (i.e., staff devices), so as to communicate with a management system of a facility. The application can be installed on the devices of staff of each of the workers, or a facility manager may distribute devices to staff, which may be returned after completion of the staff members shift. Each staff member may have a separate login for each effective function. Each staff member may view scheduled room cleaning chart and allocated timeslots, and access/unlock each room as per the scheduled chart, not necessarily in order of allocation. Once a room is opened, a staff member may be prevented from simultaneously opening another room. Assigned tasks per room may be presented with checkboxes against each task, and the staff member may select and identify an assignment as complete upon completion of allocated assignments. Moreover, from a staff device application interface, a staff member may report/submit issues or problems with rooms or supply items.

The staff device application may be pivotal to a facility management system as it may be used to coordinate elements of the system. For example, a facility manager may control any number of features associated with the facility management system through a staff device application. Limits to the staff device application may be imposed by certain parameters established using a management system application, such as, the management system application sold under the trade name Ikanos, by Caleido. A facility manager may input any and all staff device or guest device control parameters into an interface of a management system application and may view a status against each parameter in real-time through the staff device application.

FIGS. 6A-6D shows screenshots of an exemplary staff device application.

FIG. 6A shows an exemplary welcome screen.

FIG. 6B shows an exemplary welcome screen identifying certain functionalities of the application.

FIG. 6C shows a screen of a home page of a floor manager application.

FIG. 6D shows a room service page.

In preferred implementations, a management system of the invention comprises a software. The software is preferably a facility management software, for example, the management software sold under the trade name Ikanos by Caleido. The software may be stored in a computer program product and loaded into the management system using removable storage drive, hard drive or communications interface. The control logic (software), when executed by processor, causes processor to perform functions of the invention as described herein.

The software may reside in a locally hosted environment and provide an interface for connecting or controlling existing property management solutions. The facility management software interface may be a standard interface or may be customized to fit parameters and needs of a particular facility. Advantageously, the software interface may be further designed to accommodate aspects of property management solutions, such as those property management solutions provided under the trade name WinHMS, or Opera, or Hotelier, or Protel, or Fidelio.

In some regards, facility management software is provided for the purposes of coordinating the various computers and devices connected to a management system of a facility. For example, the facility management software may perform roles associated with guest information collection, connecting or identifying a guest to a room, associating a guest device with a particular guest, identifying and controlling devices connected to facility, e.g., a computer operated door lock, a motion sensor, an energy sensor, etc.

Bidirectional information flow of guest data may be used to facilitate operations with management systems. These data may include personal guest details, allocated rooms, associations of guests with respective guest devices, or booking information details. Collection of data may be coordinated with door locks of an associated guest room without any user intervention.

The software may provide features directed to monitoring a hospitality facility. In particular, because the facility management software connects to a network collecting a plurality of devices operable associated with the facility, the facility management software is useful to collect, analyze, store, and/or report information from the plurality of devices. This data may be processed and sent to custom analysis software system, for example, the analysis software system sold under the trade name Cielo by Caleido. The analysis software may be hosted on Amazon Web Services (AWS) in a Software as a Service (SaaS) environment. The data may include, for example, data related to energy consumption of the facility. The data may be collected, analyzed, and reported to one or more property owners or facility managers. Some operationally critical data may be gleaned from the collected data and may be provided to staff members through a staff device application. The information and data that is collected and maintained by may be locally backed-up locally on one or more memory devices associated with the software. The memory devices may be on or off facility premises.

FIG. 7A is a screenshot of an exemplary dashboard interface displaying facility data 701 provided by management system software consistent with the present disclosure. FIGS. 7A-1, 7A-2, 7A-3, and 7A-4 are enlarged screenshots of the dashboard interface, showing various metrics. The data 701 may be data collected from devices within the facility, e.g., energy consumption sensors. The computer management software may be used analyze and/or display data.

FIG. 7B is a screenshot of an exemplary booking management interface provided by management system software, including features for managing room bookings. FIGS. 7B-1 and 7B-2 are enlarged views of portions of the booking management interface.

Management systems of the invention are operable to communicate and exchange data over a network with multiple types of devices connected with the facility. The devices connected to the facility may be important to various aspects of facility management. For example, the devices may relate to facility access, security, or energy costs. In preferred embodiments, devices connected with the facility includes one or more locking devices. The locking devices preferably comprise computer-controlled locking mechanisms operable to communicate with the management system over a network.

A locking device of the invention preferably includes a computer-controllable locking device, such as, the locking device sold under the trade name Kleio by Caleido.

FIG. 8 is a block diagram illustrating aspects of an exemplary locking device 801. The locking device 801 is configured to communicate with a management system by exchanging data over a network 807. The communications may include data relating to registered guests or staff members of a facility. The data may further include unique identification information associated with a device of a guest or staff. For example, the data may identify a particular guest device 805 of a guest that is authorized to enter the room, such that, when the guest requests entry with the device 805, the locking device 801 can accommodate the request.

Communications between the locking device 801 and the management system may be facilitated by a data hub 803. The locking device 801 may communicate with the datahub by Bluetooth or over the network 807. The data hub 803 may include memory for storing identification data of registered guests or staff, which may be received from the management system. In this way, data relating to identification data of persons authorized to enter a room are made accessible faster, and in situations in which, for example, a Wi-Fi network of a facility is down.

FIG. 9 is a front view of an exemplary locking device 901. The locking device 901 provides a computer controlled, smart-lock solution for security and convenience of guests at the facility. The locking device 901 is configured to receive data in connection with a request for entry, preferably by Bluetooth, from a guest or staff member and, upon authenticating that the request is of an authorized entrant, provide access to a room of a facility.

The locking device 901 may be configured to mount to any conventional door 907 of a facility. The locking device 901 includes a computer (not shown) connected to a processor for executing instructions relating to a status of a lock 905. The locking device 901 is further configured to communicate and exchange data over a network. The data may include information for identifying persons authorized to enter a room. The data may include information pertaining to a room entry request, which may include a time stamp, for creating an archive of guest or staff that request room entry and when said request was made.

The locking device 901 may include a display 903. The display 903 may be an LCD display. The display 903 may be configured to receiving manual input from a guest or staff member. For example, the display 903 may be configured to provide a keypad for entering a key code.

FIG. 10 is an exploded view of an exemplary locking device 1001. The locking device 1001 comprises a front panel 1003 and a rear panel 1005. The front panel 1003 may house a communication engine, and a display unit (e.g., an LCD display). The display unit may include an LCD display with touch screen and LED indications of status. The rear panel 1005 may house a motor, a battery, and a charging electronic.

The locking device may be implemented by facility to eliminate the traditional “master key” concept that has caused maintenance and security headaches for facility managers. In some embodiments, the locking device operates in tandem with a hub of management systems. The hub is preferably a data control hub, for example, the data control hub provided under the trade name IntelliHub by Caleido. The locking device may function similarly to standard hotel door locks, except that the locking mechanism may be controllable through, for example, a guest device application, or a staff device application. The locking device may include a display 903, such as, an LCD display, with a touch screen interface on the outside and a knob (not shown) to lock oneself in from the inside. This knob can also serve as a do-not disturb function. Once locked, the locking device may not be opened from the outside, like standard hotel room locks. If an allocated unlock/lock code is lost, the codes may be regenerated on an application of a staff device or a guest device by the guest or staff of the facility.

In certain instances, a guest may book a room with the facility using a guest device or check-in with a staff member of the facility, for example, at the front desk. Once a room is booked, information contained inside memory or a database associated with the facility may be updated to identify a guest with a particular room of the facility. For example, when the guest attempts to check-in using a guest device application, unique identification data identifying the guest and the device associated with the guest may be provided by the application to the management system and stored in memory or a facility database. The management system may store the identification information and associate said information with one or more rooms of a facility. The management system information may notify the guest through the application which room the guest has been assigned. Advantageously, the entire process may occur without any human interaction.

When the guest arrives at the room of the facility, the guest device application may be used to unlock the door. For example, a locking mechanism of the locking device may be controlled through a Bluetooth interface, or other similar methods. If the guest does not have a device, the guest may be assigned a code, e.g., a 4-6-digit numeric lock code, to unlock or lock the device. The code may be entered on a touchpad of the device to unlock the door. Once unlocked, the door lock can remain open for a period of 30 seconds, or similarly brief period, before the unit auto-locks. Alternatively, the locking device may be locked by the guest.

In some embodiments, the locking device includes memory for storying a list of authenticated users or guests or identification information of their associated devices. For example, memory of the locking devices may store up to 1024 users, or more. Such locking devices may be integrated into a guest room, a conference hall, or a luxury lounge. The number users or guests stored in memory of the locking device will likely depend on the type of room associated with the locking device.

A list of authenticated users stored in memory may be modified with software of the management system, an application of a guest device, or an application of a staff device. For example, when a guest is logged into the system, the front-desk, or a floor manager may assign permissions that are transmitted to one or more locking devices at the facility. The locking device may be operably associated with one or more databases. The databases may store data used to identify users or guests associated with a room. The locking device may store guest information as well as virtual lock/unlock codes allocated by guests. All permitted users who have a virtual lock/unlock codes, may open a door with their mobile application or by entering the respective codes on the keypad. User information can be timed-out at each check-out cycle.

Locking devices may display custom messages on associated LCD interface. The messages may include, for example, a room number, a welcome message, or identify an event. The same display doubles may be used as a keypad to enter codes for locking or unlocking the locking device.

In some embodiments, the locking device communicates data with a data hub of the management system. Data may include successful or unsuccessful unlock/lock events. The data may be stored in memory of a database of the hub. The data may be viewable with a staff device application, a guest device application, or a software connected to the facility. Communication between the locking device and the hub may occur over a network (e.g., a cloud-based network), or by Bluetooth, and the software can be designed to manage the connectivity between the locking device and the hub.

FIG. 11 shows an exemplary data hub 1101. The data hub 1101 is preferably a data control unit such as the data control unit provided under the trade name IntelliHub by Caleido. The data hub 1101 may function as a data or a node aggregator for a room or a designated area of a facility. The hub 1101 is configured to receive instructions from the management system by, for example, the computer management software, and transmits those instructions to the one or more devices and or sensors associated with the hub 1101. Moreover, the hub 1101 may transmit data that is collected or aggregated from the associated devices and/or sensors the management system. In addition to these functions, the hub 1101 may also turn on power to the room upon successful authentication feedback from a locking device. The hub 1101 may also have functionality built-in to interact with devices of the room, for example, an air conditioner, and/or controls to set temperature settings. This feature is advantageous because it enables the guest to pre-condition the room once check-in is complete. The functionality may be achieved through a coordinated effort of the hub and a support device.

FIG. 12 shows a deployment scenario of data hubs 1201 at a facility management system. The deployment scenario illustrates how the hub 1201 may assume various roles of a node data collection unit to aggregate and move data through a hospitality facility via the management system. The deployments are flexible and can cover any desired area of the facility property, including, for example, a lounge 1205, a kitchen, 1207, a guest room 1209, a restaurant or dining area, a reception desk, a front desk, an auditorium, or a conference room. In all these cases, the hub can form a master node in the area and may be operable to exchange data with sensors and devices associated with the management system. The node, by relaying directing instructions from the management system, provides for efficient movement of data through the system by minimizing the number of devices and sensors that the management system must coordinate directly.

In some instances, a hub of a management system may be incorporated into a locking device. The locking device, which is advantageously positioned in close proximity with sensors and devices of each room of the facility, may have a built-in data hub.

FIG. 13 shows an exemplary control management system 1301 for integration into a facility. The control management system 1301 is operable to exchange communications from one or more guest devices 1303 and/or one or more staff devices 1305. Communications from the guest devices 1303 or staff devices 1305 may involve instructions for controlling one or more devices connected to the facility 1333, such as, for example, a locking device 1307, or an environmental control device 1309 (e.g., an air conditioner). The control management system 1301 is operable to exchange communication with devices connected to the facility 1333 in response to data received from guest devices 1303 or staff devices 1305.

In preferred embodiments, exchanges of communications between guest devices and staff devices are coordinated through a data hub 1313. The data hub 1313 is preferably associated with specific devices connected to the facility 1333, such as, devices of a specific room. Integration of a data hub 1313 is beneficial for coordinating data exchange between guest or staff devices 1303, 1305, and the control management system 1301 because the data hub 1313 can identify, by virtue of its connection to the respective devices 1333, to the management system 1301 the room from which devices are subject to control.

Identification data may be used by the management system 1301, or the data hub 1313, to authorize certain communication exchanges, for example, to authorize whether a communication from a guest device can control a device connected to the facility 1333. Data authorization may involve correlating or comparing unique identification data of the guest device 1303 with authentication information stored in a database 1321. The authentication information may comprise data associated a registered guest with a room of the facility. The authentication information may further include data associating the registered guest with the unique identification information of the guest device. The authentication information may comprise data associating the unique identification information with a room for which the device is authorized to operate. When there is a match between information stored in the database and unique identification data, a communication exchange may be authorized.

Management systems preferably include one or more sensors 1311 for collecting and reporting data relating to aspects of facility resources. For example, some sensors of the management system can record data relating to energy consumption. The recorded data can be reported to a property manager, a facility manager, a staff, or a guest. The recorded data may be useful from a facility management perspective for controlling costs and improving profitability. Data from the sensors 1311 may be collected by the data hub 1313 and provided on a periodic basis to the management system 1301.

FIG. 14 shows block diagram illustrating an environment control system 1401. The environment control system 1401 may be connected to sensors 1409, e.g., motion sensors. The environment control system 1401 may be a control system such as the one provided under the trade name Amenos by Caleido. The environment control system 1401 may control a room environment by regulating room temperature, for example, by controlling an air condition (AC) system. The environment control system 1401 may be configured as a plug-in replacement for existing thermostat-based HVAC blower control units and features modern split AC controls and motion sensing electronics. The environment control system 1401 may interface with a data hub 1403 in the guest room. The guest associated with the room may control any of split AC controls from a guest device 1407 hosting a guest device application. When not in the room, the guest may signal the unit, through the guest device application, in conjunction with the data hub 1403, to shut down the AC and avoid unnecessary power consumption.

In the event that a guest forgets to signal the availability, one or more motion sensors 1409 may be used to detect the presence or absence of a guest through computer algorithms stored in memory of the sensor control system and executed by the sensor control system to signal the AC unit to, for example, turn off. All commands from the guest device 1407 may be transmitted through the management system via the hub. In some instances, it may be desirable to program AC operation schedules, which can be programmed through a computer software 1411 of the management system and relayed via a data hub to the sensor control system 1401. AC temperature may be scheduled for automatic control based on times of day or whether a room is vacant. In some instances, data, such as data associating a guest with a room for a certain day, or data identifying whether a room will be vacant, is stored in a database of the management system. The management system may communicate with the database storing the data to create schedules of operations and provide said schedules to environment control systems of guest rooms.

The environment control system may interface with a blower and control the blower based on room temperature. Standard high/low speed modes may be controlled for the blower. Optionally heating systems are also be supported and controlled through the environment control system.

Thus, management systems of the invention may regulate issues associated with occupancy by employing one or more motion sensors to identify rooms that are either occupied or unoccupied and manage devices associated with the room accordingly.

FIG. 15 shows an exemplary energy sensor 1501. The energy sensor 1501 may be, for example, an energy monitoring sensor such as the energy monitoring sensor provided under the trade name Mikos by Caleido. The sensor 1501 preferably includes a computer having a processor coupled to memory containing instructions executable by the processor to cause the sensor 1501 to sense or measure energy consumption data and communicate the data over a network. Execution of instructions may be further operable to cause the sensor 1501 to receive instructions over the network from the management system.

In particular embodiments, the sensor 1501 comprises a sensing device that plugs into a standard power socket of a facility to measure power and energy consumed by an electrical device connected to the power socket through the sensor 1501. Accordingly, the sensor 1501 may include an interface (similar to a conventional socket) for receiving an electrical plug of a device.

The sensor 1501 may communicate with the management system over a network, such as, a Wi-Fi network, and may be part of a network operably associated with a data hub. In preferred embodiments, the sensor 1501 will be used with devices associated with high energy consumption, for example, a water heater, an air conditioner, a refrigerator, or any kitchen appliance within a given power ranges.

The sensor 1501 may be a single-phase device that operable in a range of, for example, 90V-270V (45-60 Hz), and may measure voltage, current, and/or energy consumed. The measurements are useful for tracking purposes, and not just for electrical metering. The sensor 1501 may allow for a programmable alarm, an alarm trigger, and/or an event alter or notification that can be sent out to devices connected with the management system. The notifications may signal a deviation in energy consumption. The deviation may be a change beyond a programmed threshold. The device may signal that the device associated with the sensor is functioning sub-optimally. Accordingly, with the integration of energy sensors into a management system, a facility manager can identify if a device, e.g., an AC, needs maintenance (e.g., an air filter change) to ensure that facility devices, particularly those associated with high energy consumption, are operating within pre-determined parameters.

The sensor 1501 is preferably configured to collect data related to energy consumption. The data may be provided through the management system to a software or data analysis system for processing and reporting analytics associated with the facility. The reporting of such data is useful for property managers to identify and control facility expenses through, for example, equipment upgrades.

In some instances, the sensor 1501 may be operable to receive data from the communication system, for example, through an associated data hub. The sensor 1501 may further be operable to respond to the data by, for example, cutting power to a device plugged into the sensor 1501. The sensor may cut power to the device by, for example, regulating a flow of electricity to the device via a circuit. That is, the sensor may be configured to break a circuit of electricity flowing from an outlet to the device via the sensor.

FIG. 16 shows an air quality sensor for use with a management system. The air quality sensor may be an air sensor such as the air sensor sold under the trade name AirQ by Caleido. The air quality sensor is useful for sensing air quality within an area of a facility. Since air quality is important for the health and comfort of facility occupants, e.g., guest and staff members alike, measuring air quality is important for facility management. Measurements of air quality can be used to identify areas of a facility in need of air quality maintenance.

Some features of the air quality sensor include ability to take measurements of pressure, humidity, temperature, and gas. The air quality sensor may measure relative humidity, with a fast response time. The air quality sensor may measure gas, including, volatile organic compounds. The air quality sensor may measure barometric pressure and altitude. The air quality sensor may measure ambient temperature. The air quality sensor may take periodic measurements, for example, every 1 hour, 2 hours, 4 hours, 6 hours, 12 hours, or 24 hours. The management system may compare measurements from the air quality sensor and compare those measurements with optimal measurements. Any deviation between the air quality sensor measurement and optimal measurement, beyond a predetermined threshold, may result in an alarm or notification being transmitted to one of a plurality of different devices or a property management system.

FIG. 17 identifies correlations between output of an exemplary air quality sensor and air quality. In particular, based on intelligent algorithms, an air quality sensor of a management system may provide output in the form of an IAQ output. The IAQ output may be in a range of 0-500, with increments of 1 to indicate differences of air quality. The IAQ ranges are illustrated in the figure. Based on detected IAQ levels, a facility manager takes actions to manage air quality in various rooms of a facility. For example, a facility manager may choose to manually deploy room an air-purifier. There may be an option to automatically turn-on or turn-off a room air-purifier. For example, purifiers may be incorporated in rooms of the facility and may be, for example, turned on automatically by the management system in response to a sensor detecting an air quality above a pre-determined threshold (e.g., above 50, or above 100). Alternatively, a staff member or facility manager may be notified when the air quality if sensed above the pre-determined threshold at which point the staff or facility manager can activate the purifier through the system. Advantageously, incorporation of the sensor identifies when a purifier is needed such that the purifier is not running and consuming energy unnecessarily. If the air quality is particularly poor, or reaches a dangerous level, e.g., above 150, an alarm may be triggered.

FIG. 18 is a block diagram of an analytical software system 1801 for managing a facility. Rooms of a facility preferably includes a plurality of sensors, such as, one or more of a temperature sensor, an air quality sensor, a later usage sensor, a lock, or power sensor. The sensors take measurements and provide data to a data hub 1803. The data hub 1803 transmits data from a room to a computer of a management system 1805. The management system 1805 is operable to receive sensor data from a plurality of data hubs 1803 at the facility and also receives anonymized data from a property (facility) server 1809. The data from each property of the a customer may be gathered in software system 1801 using a data sync process. A user (e.g., facility manager, property manager, staff member) may access the centralized data from using a web application associated with the software system. Users associated with the property may also access the data from a management system server using a mobile application.

Preferably, the analytical software system comprises a software service such as the service offered under the trade name Cielo by Caleido. The software may be hosted as a Software-as-a-Service (SAAS) solution for facility managers. Aided by adapters for interconnection with existing property management solutions, the analytical software may accelerate data capture and process event streams in near-real time. For example, when a property is installed with a property management solution, such as the solution sold under the trade name the Caleido Solution, by Caleido, the software interface for the property may be enabled by a technical team interfacing with the property owners. The software may allow facility managers or owners to view property statistics, for example, through a metrics dashboard. The software may be configured to receive data from various computers, sensors, and devices through the facility via the management system and process that data into actionable information, for example, information relating to facility expenses that can be improved by certain facility upgrades.

The software may comprise an interface with a custom dashboard allowing managers or owners to monitor, in real-time, energy consumption patterns over a facility. The interface may comprise one or more dashboards for viewing interactive reports or data charts. The interface may provide an in-depth analysis of collected data. The in-depth analysis may analyze data collected from one or more facilities via sensors. The in-depth analysis may include analytical processes such as pivoting, filtering, drill down, charting, and custom calculations.

Other features of the software system include data virtualization. Data virtualization allows multiple data sources to be combined into a single metadata view to enable analyses and reporting across sources without requiring extract, transmit load (ETL) processes or a data warehouse of each data source individually. Data integration (ETL) can be used to extract data from various sources, transform the data based on defined business rules, and load the data into a centralized data warehouse or data mark.

The facility owners or managers may use the analysis software system to analyze best practices and processes from top-performing avenues. The data software may include (but is not limited to): a user administration and subscription management; a user login, organization and property interface; logging—user level and admin level; generation of metrics and analytics; user reports; password protection; and service request management.

FIGS. 19A and 19B are an exemplary screenshots of an interface provided on a user's device displaying various data to a user. FIGS. 19A-1, 19A-2, and 19A-3 are enlarged views of interfaces showing data relating to room availability 1903, occupancy status 1905, and sensor status 1907, respectively. FIGS. 19B-1 and 19B-2 are enlarged views of interfaces showing data relating to booking references 1911 and guest reviews 1915. The data are presented in a format that is simple and easy to digest. As such, the learning curve for using and operating the system is minimal and decisions regarding the facility (e.g., identifying aspects of facility infrastructure of upgrades) can be made quickly.

A management system according to this disclosure provides for efficient, cost-effective facility management through an interoperable mesh of technologies and devices. The management system is operable to combine different technologies (e.g., computers, networks, software, devices, sensors, etc.) to manage and address distinct issues. In preferred embodiments, the issues addressed are associated with both hospitality and facility infrastructure so as to maximize profitability and guest experience. The management system addresses issues relating to hospitality and facility infrastructure with one centralized and integrated system.

As a person of skill in the art will appreciate, the management system coordinates activities of different systems and devices (e.g., a guest device, a staff device, or a device integrated into the facility) by managing the exchange of digital data between those devices over a network. Digital data, as it pertains to this disclosure, may be described as the discrete, discontinuous representation of information or works. Numbers and letters are commonly used representations. Digital data may be contrasted with analog signals which behave in a continuous manner, and with continuous functions such as sounds, images, and other measurements. The exchange of digital data over a network generally relates to any information exchange or information sharing done electronically or through certain systems. Information exchange may involve a bidirectional information transfer in digital data. As, “information,” as described herein generally refers to (digital) data that encodes and represents the information at hand, including, requests for services or computer executable instructions for adjusting an operation or setting of an in-room device (e.g., an A/C setting or light).

In certain embodiments, the management system coordinates information exchanges between a hub and/or a server using a Message Queuing Telemetry Transport (MQTT) protocol. MQTT relates to an open Organization for the Advancement of Structured Information Standards (OASIS) and International Organization for Standardization (ISO) standard (ISO/IEC 20922) lightweight, publish-subscribe network protocol that transports messages between devices. The protocol usually runs over TCP/IP; however, any network protocol that provides ordered, lossless, bi-directional connections may support MQTT. MQTT is an advantageous protocol for use with management systems of this disclosure since MQTT is optimized for connections with remote locations where a “small code footprint” is required or the network bandwidth is limited.

Specifically, an MQTT protocol may define two types of network entities: a message broker and a number of clients (i.e., any device that runs an MQTT library and connects to an MQTT broker over a network). An MQTT broker is a server that receives all messages from the clients and then routes the messages to the appropriate destination clients. An MQTT client is any device (from a micro controller up to a fully-fledged server) that runs an MQTT library and connects to an MQTT broker over a network.

Information can be organized in a hierarchy of topics. When a publisher has a new item of data to distribute, it can send a control message with the data to the connected broker. The broker then distributes the information to any clients that have subscribed to that topic. The publisher does not need to have any data on the number or locations of subscribers, and subscribers, in turn, do not have to be configured with any data about the publishers. According to a preferred MQTT of the invention, information is organized by six topics, e.g., One topic to publish messages to the server, one topic for device data, one topic for device alerts, one topic for device health packet, one topic for last will, and one topic for server to hub. There may be at least 50 hubs. There may be one global topic for messages, e.g., a Firmware update. Devices of the management system may be configured to listen to ‘Global topic/device UID’ topic.

If a broker receives a message on a topic for which there are no current subscribers, the broker may discard the message unless the publisher of the message designated the message as a retained message. A retained message is a normal MQTT message with the retained flag set to true. The broker may store the last retained message and the corresponding QoS for the selected topic. Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe. The broker may store only one retained message per topic. This allows new subscribers to a topic to receive the most current value rather than waiting for the next update from a publisher.

When a publishing client first connects to the broker, it can set up a default message to be sent to subscribers if the broker detects that the publishing client has unexpectedly disconnected from the broker. Clients may only interact with a broker, but a system may contain several broker servers that exchange data based on their current subscribers' topics.

A minimal MQTT control message may be as little as two bytes of data. A control message may carry nearly 256 megabytes of data, or more, if needed. There may be different message types used to connect and disconnect a client from a broker, to publish data, to acknowledge receipt of data, and to supervise the connection between client and server.

MQTT generally uses TCP protocol for data transmission. A variant, MQTT-SN, may be used over other transports such as UDP or Bluetooth.

MQTT, according to the disclosure, sends connection credentials (authorization data) in plain text format. Data security measures may be implemented by, for example, using TLS to encrypt and protect the transferred information against interception, modification, or forgery.

In preferred embodiment, communications will be carried via a MQTT protocol using a Mosquitto broker. Mosquitto is an open source (EPL/EDL licensed) message broker that implements the MQTT protocol. Mosquitto is lightweight and is suitable for use on a plurality of different devices including those from low power single board computers to full servers.

In some embodiments Heartbeats will be implemented using the Last will and testament (LWT) specification of the MQTT protocol. The last will message is a normal MQTT message with a topic, retained message flag, quality of service (QoS), and payload. The broker stores the message until it detects that the client has disconnected ungracefully. In response to the ungraceful disconnect, the broker sends the last-will message to all subscribed clients of the last-will message topic. If the client disconnects gracefully with a correct disconnect message, the broker discards the stored LWT message. Appropriate QoS levels will be used to transmit messages across the topics. QoS level considerations include Hub should not have to handle duplicate messages; and server has to ensure that it handles duplicate messages in a predictable manner.

The hub data processor may use Remote Dictionary Server (i.e., Redis) to manage duplicate messages and ensure that the same message is not processed by multiple processes. Redis is an in-memory data structure store, used as a distributed, in-memory key-value database, cache and message broker, with optional durability. Redis supports different kinds of abstract data structures, such as strings, lists, maps, sets, sorted sets, HyperLogLogs, bitmaps, streams, and spatial indexes. SSL may be used to ensure communication between the hub and server is secure.

All Personally, Identifiable Information (PII) data, e.g., names, addresses, emails etc. will be encrypted and stored in a database of a management system. This approach of encryption of data at rest ensures that meaningful data is shown only to an authorized user. An Oracle DBMS_CRYPTO package may be used. The Encryption Algorithm may be, for example, AES256. The Chaining Mode used may be CBC. The Padding Mode used may be PKCS5.

FIG. 20 shows an exemplary management system 2001 following a Message Queuing Telemetry Transport architecture. A hub data processor of a hub 2003 of the management system 2001 may use a Remote Dictionary Server. Communications between a server 2005 and the hub 2003 is preferably two way, such that each of the server 2005 or hub 2003 is configured to initiate or receive a communication from the other.

Authentication and identification are preferably handled by both the hub 2003 and the server 2005. Preferably, no two hubs 2003 will communicate with each other directly. In most instances, symmetric key authentication will be used to authenticate the hub 2003 and the same key will be used to authenticate messages received from the server 2005.

FIG. 21 shows a block diagram illustrating authentication. In particular, the figure illustrates an HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) mutual authentication process for authenticating data exchanged over a network. The authentication process of a management system generally involves authenticating a request received from a device (e.g., a guest device or staff device) before processing the request.

Preferably, the authentication comprises HMAC. HMAC is a type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. The code may be used to simultaneously verify both data integrity and the authenticity of a message. In some instances, HMAC can provide message authentication using a shared secret instead of using digital signatures with asymmetric cryptography. It trades off the need for a complex public key infrastructure by delegating the key exchange to the communicating parties, who are responsible for establishing and using a trusted channel to agree on the key prior to communication.

FIG. 22 identifies pathways for operating exemplary components associated with a server. As illustrated, a user, e.g., a staff, guest, facility manager, etc., may communicate with a server (labeled here as an application server) of a management system to operate various components of the server. Communications may be carried out via a Hypertext Transfer Protocol (HTTP) request. HTTP is an application layer protocol for distributed, collaborative, hypermedia information systems and is the foundation of data communication for the Internet. HTTP request may be made using a guest device or staff device. The device may include an interface with hyperlinks to server components that the user can easily access, for example by tapping the screen in a web browser or software application. The components or modules, described in detail below, include report management, sensor data processor, schedule handler, alarm manager, notification engine, device and facility manager, and cloud synchronizer.

The hub is operable to communicate with the application server via a MQTT device. The hub may initiate a communicate in response to an instruction received by a guest device, a staff device, or a property management system.

FIG. 23 identifies exemplary server components of a management system. As a person of skill in the art will recognize, a server refers to a piece of computer hardware or software (computer program) that provides functionality for other programs or devices, referred to as clients. Servers of a management system provide any number of different functionalities, often called services, such as sharing data or resources among multiple clients, or performing computation for a client. A management system generally comprises a single server for serving multiple clients. Although, in some instances, it may be desirable to include multiple servers. A client process may run on the same device or may connect over a network to a server on a different device. Typical servers are database servers, file servers, mail servers, print servers, web servers, game servers, and application servers.

Preferably, the server implemented as a request-response model: a client sends a request to the server, which performs some action and sends a response back to the client, typically with a result or acknowledgment. The server may comprise a computer, designed as server-class hardware, which is specialized for running servers on it.

FIG. 24 illustrates connectivity among components of an exemplary management system. More particularly, FIG. 24 illustrates connectivity among various server components with devices and servers coordinated by the management system.

FIG. 25 diagrams inter-system communications of a management system 2501. The management system 2501 comprises a computer with memory containing instructions for communicating with a plurality of devices over a network. The plurality of devices includes devices operated by staff 2503 and guests 2505 of the facility as well as devices installed in the facility (e.g., in room devices, such as, door locks 2507 and sensors 2509). Preferably, the management system is operable to communicate with devices installed in the facility through one or more hubs 2511.

FIG. 26 shows a block diagram illustrating connections with a server 2603 of a management system. The server 2603 provides functionality for other components or modules associated with the server. Some exemplary modules are identified in the figure. The server 2603 is operable to communicate with a property management system (PMS) 2605 bidirectionally. Preferably, the communications may comprise a HTTPS protocol. The server may send communications to a cloud server according to that same protocol. In preferred embodiments, the server is operable to communicate bidirectionally with one or more hubs of a facility 2607. Each one of the one or more hubs may be associated with a particular room of the facility. In some instances, one hub may be associated with more than one room. The hub 2607 may communicate with a lock 2609 and one or more sensors 2611 of each room of the facility. In some aspects, the hub 2611 may function as an intermediary for communications between a server and devices connected to the facility e.g., sensors 2611, and locks 2609. The sever 2603 may provide information to a cloud server 2613. Providing information to a cloud server 2613 can be useful for backing up server data and sharing data from the server with other devices not connected directly with said server 2603.

FIG. 27 shows a block diagram of a device manager. The device manager is a component, also referred herein as a module, of a server operable to communicate data relating to various devices of a facility (e.g., a lock, a hub, or a sensor). The device manager may be operable to collect and relay data from devices connected to a facility, e.g., one or more sensors, a light, a lock, etc., and provide said data to a database, a facility manager, a notification engine, or a device communicator. The data may be transmitted to the server via a data hub.

The device manager may communicate with devices connected to a facility via a device communicator. A device communicator refers to a server module operable to send keys, commands, instructions, to devices associated with the management system (e.g., a door lock).

FIG. 28 is a block diagram of a facility manager component. The facility manager component or module is a discrete application of a server that is operable to handle tasks related to rooms, bookings, keys, user activities, food ordering, feedback, maintenance requests, service requests, devices and job orders, offers, events and holidays, and firmware reports. Often, these tasks are addressed by communicating with different components of the same server.

In some instances, the facility manager component is configured to receive communications from a staff application, a guest application, or a maintenance application. In response a communication, the facility manager may send one or more communications (bidirectional) to different server components or modules, such as, a device manager, a reporter hander, a schedule handler, a notification engine, or an alert manager. The facility manger component may also send a communication to a database, for example, to update authentication information.

FIG. 29 is a block diagram of an alarm manager. The alarm manager is a server component operable to raise alarms, issue notifications, and monitor devices. The alarm manager is operable to issue notifications via a notification engine.

For example, in some instances the alarm manger may issue an alarm based on data received by one or more sensors. The one or more sensors may be, for example, an air quality sensor. If poor or dangerous air quality is sensed, the sensor may, by relaying data through a data hub, to a device manager module of the server, and to the alarm manager, trigger an alarm that is directed to one or more devices in association with the management system, such as, staff or guest devices. The alarm may be directed to the various devices via a notification engine module of the server.

FIG. 30 is a block diagram of a notification engine. The notification engine is a component or module of a server operable to send notifications via a short message service (SMS) or push technology. SMS uses standardized communication protocols that let devices exchange short text messages. The notifications may be handled by a bulk SMS service, such as, the bulk SMS service provided under the trade name KAPSYSTEM by KAP Computer Solutions Pvt. Ltd.

Push technology, or server push, is a style of communication where the request for a given transaction is initiated by the publisher or central. Push technology may be contrasted with get, where the request for the transmission of information is initiated by the receiver. Push services are often based on information preferences expressed in advance. This is called a publish model. A client “subscribes” to various information “channels” provided by a server; whenever new content is available on one of those channels, the server pushes that information out to the client. The push notifications may be use a Firebase Cloud Messaging service.

In some embodiments, the notification engine is operable to send notifications in response to communications received by a schedule manager.

FIG. 31 shows a block diagram of a schedule manager. The schedule manager is a module of a server operable to handle tasks relating to, among other things, scheduling cleaning services and or maintenance requests. The scheduling manager may schedule such services in response to input from a guest device, a staff device, or a facility manager. For example, a guest may, via input into a guest application interface, request room service, such as, a room cleaning. In response, the schedule manager may schedule a cleaning and report said schedule via the notification engine or a staff device. The scheduling manager may also schedule services or maintenance requests automatically upon quest check out, or, periodically, for example, daily or weekly.

FIG. 32 is a sequence diagram for an installation and commissioning of sensors and a hub with configuration data. A technician may work with a floor manager to install and configure the hub and sensor of each room with configuration data. Confirmation data may include room number, Wi-Fi settings, password, handshake message, hotel AP SSID, AP password, AC controls, mood lighting settings, etc. After configuration, technician may check whether communication is happening with a computer of the management system to complete the configuration setup.

FIG. 33 shows a sequence diagram of a firmware upgrade process. In particular, FIG. 33 shows a sequence of steps for upgrading firmware of sensors/locks with new image/data. The computer management system may detect firmware changes to identify and store identifying data of all rooms that needs to be updated. A technician may go to a specific room and check current firmware for any sensors/locks of the room and initiate maintenance for the room by giving the details of file transfer protocol (FTP) and commands needed for upgrade. The hub fetches the image from the FTP server and beings the upgrade for the specific sensor/lock. After upgrading, the sensor/lock registration with new firmware parameters is updated to the management system and hub. If the sensor/lock fails to upgrade to new firmware image, then the sensor/lock reboots with previous image and the maintenance is identified as complete for the specific room.

FIG. 34 shows a sequence diagram for a hotel site setup. The diagram is a site and staff setup for a facility. To complete site setup, hotel details (e.g., hotel name, city, image, theme), room details (e.g., floor number, room number, amities for each room), room services (e.g., extra bedding, toiletries, towels) and food and beverage service details (e.g., prices, coupons, orders) are fetched from the hotel and saved in a corresponding database. To complete staff setup, staff details (e.g., role, phone number, username/password) and their access rights are fetched from the hotel and saved in a staff database.

FIG. 35 shows a sequence diagram for maintenance. When the maintenance is started, lock and sensors may be configured to send an acknowledgement to start the maintenance. The technician may request critical event logs for a hub, a lock and/or a sensor. When the maintenance is finished, the hub, lock, and/or sensor may send a second acknowledgement to stop the maintenance.

FIG. 36 shows a sequence diagram for guest check in. A guest may arrive at a facility, e.g., a hotel, for check in and a front desk may validate check in request. For example, the guest may need to provide proof of identification. After validation, a room may be allocated to the guest. The guest may customize their room by providing a service request. Requests may include extra bedding, luggage details, toiletries, food or beverages, etc. A staff member may check the service request and customize the room according to the guest request. The information may then be updated into a database. Information provided to the database may include guest name, telephone number, requests, room allocations, etc.

FIG. 37 shows a sequence diagram for a guest check out. The guest may request a check out using a guest application on the guest's device. Upon request, the management system may fetch guest details and initiate check out procedures. The front desk may process the check-out procedures for the guest by validating the dues or expenses remaining to be paid. If the guest does not have any outstanding dues, then check out is done successfully. If dues are present, then guest will get a notification to contact the front desk. After successful check out, details of the guest are removed from the hub of the room and the database is updated with the details of guests and check out time.

FIG. 38 shows a sequence diagram for room server management. A staff may be assigned to each room for a particular service request using the database information of the staff. When a room service request/food service request is generated by a guest, the staff assigned to a particular request for that room may receive a notification to process the service request. The information is updated in the database after the service is complete.

FIG. 39 is a diagram of issues addressed by an exemplary management system.

As used in any embodiment herein, the term “module” may refer to software, firmware and/or circuitry configured to perform any of the aforementioned operations. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices. Circuitry may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry. The modules may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smartphones, etc.

Any of the operations described herein may be implemented in a system that includes one or more storage mediums having stored thereon, individually or in combination, instructions that when executed by one or more processors perform the methods. Here, the processor may include, for example, a server CPU, a mobile device CPU, and/or other programmable circuitry.

Also, it is intended that operations described herein may be distributed across a plurality of physical devices, such as processing structures at more than one different physical location. The storage medium may include any type of tangible medium, for example, any type of disk including hard disks, floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic and static RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, Solid State Disks (SSDs), magnetic or optical cards, or any type of media suitable for storing electronic instructions. Other embodiments may be implemented as software modules executed by a programmable control device. The storage medium may be non-transitory.

As described herein, various embodiments may be implemented using hardware elements, software elements, or any combination thereof. Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth.

Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

The term “non-transitory” is to be understood to remove only propagating transitory signals per se from the claim scope and does not relinquish rights to all standard computer-readable media that are not only propagating transitory signals per se. Stated another way, the meaning of the term “non-transitory computer-readable medium” and “non-transitory computer-readable storage medium” should be construed to exclude only those types of transitory computer-readable media which were found in In Re Nuijten to fall outside the scope of patentable subject matter under 35 U.S.C. § 101.

The terms and expressions which have been employed herein are used as terms of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described (or portions thereof), and it is recognized that various modifications are possible within the scope of the claims. Accordingly, the claims are intended to cover all such equivalents.

INCORPORATION BY REFERENCE

References and citations to other documents, such as patents, patent applications, patent publications, journals, books, papers, web contents, have been made throughout this disclosure. All such documents are hereby incorporated herein by reference in their entirety for all purposes.

EQUIVALENTS

Various modifications of the invention and many further embodiments thereof, in addition to those shown and described herein, will become apparent to those skilled in the art from the full contents of this document, including references to the scientific and patent literature cited herein. The subject matter herein contains important information, exemplification and guidance that can be adapted to the practice of this invention in its various embodiments and equivalents thereof.

Claims

1. A management system for managing a hospitality facility, the management system operable to communicate and exchange data over a network with a plurality of devices comprising at least a guest device, a staff device, and a device connected to the facility, the management system comprising a hardware processor coupled to non-transitory, computer-readable memory containing instructions executable by the processor to cause the management system to:

receive data from at least one of the plurality of devices, wherein at least a portion of the data comprises unique identification information;

query a database that comprises authentication information;

generate an output based, at least in part, on data received from the at least one of the plurality of devices and results of the query; and

provide the output to at least one of the plurality of devices and a property management system.

2. The management system of claim 1, wherein the device connected to the facility comprises at least one of one of a locking device, a sensor, an air conditioner, an entertainment device, or an illumination device.

3. The management system of claim 1, wherein the guest device comprises a smartphone running an application configured to communicate and exchange data with the management system.

4. The management system of claim 3, wherein the application comprises an interface configured to receive input from a guest associated with the device.

5. The management system of claim 4, wherein the interface is configured to receive input in connection with at least one of accessing a room of the facility, adjusting room temperature, adjusting an entertainment device, changing room ambiance, and making a room service request.

6. The management system of claim 1, wherein the authentication information of the database comprises unique identification data associating a guest and a registered room of the facility.

7. The management system of claim 1, wherein the system is configured to authenticate data received from the plurality of devices by correlating unique identification information of one of the plurality of devices and authentication information from the database.

8. The management system of claim 1, wherein the output comprises computer-readable instructions for adjusting operation of the device connected to the facility.

9. The management system of claim 8, wherein the computer-readable instructions are processed by the device connected to the facility to thereby result in at least one of a change to a lock status, an adjustment in air temperature, an adjustment in room lighting, or an adjustment to an entertainment device.

10. The management system of claim 1, wherein the output comprises data that relates to a custodial or maintenance task and is viewable on an interface of the staff device.

11. The management system of claim 10, wherein the interface is configured to receive input from a staff member associated with the staff device in connection with the custodial or maintenance task.

12. The management system of claim 1, wherein the management system is configured to update information stored in the database based on authenticated data received from one of the plurality of devices or the property management system.

13. The management system of claim 12, wherein the update is in connection with information that associates a room of the facility with a guest and results in a change to authentication information.

14. The management system of claim 12, wherein the update is in connection with a room service request.

15. The management system of claim 12, wherein the update is in connection with a custodial or maintenance task.

16. The management system of claim 12, wherein the update is in connection with an operational status of the device connected to the facility.

17. The management system of claim 1, wherein the property management system comprises an interface that is configured to receive input from a property manager.

18. The management system of claim 17, wherein the interface allows the property manager to control one or more parameters of the system.

19. The management system of claim 18, wherein the one or more parameters comprise operational parameters of the device connected to the facility.

20. The management system of claim 17, wherein input from the property manager is used to change information stored in the database.

21. The management system of claim 20, wherein the information includes guest room assignments.

22. The management system of claim 1, where the network is a cloud-based network.

23. The management system of claim 1, wherein the data received from the at least one device is encrypted.

24. The management system of claim 23, wherein the encrypted data comprises hash-based message authentication code.

25. The management system of claim 2, wherein the sensor provides data relating to at least one of air quality, occupancy, energy consumption or water consumption.

26. The management system of claim 25, wherein the management system further comprises an analytical software system for analyzing data provided by the sensor.