Managed Room Backbone

By capturing and encapsulating device data signals in the shared space and transmitting them to the management cloud, monitoring and diagnosis of the health of the shared space is solved, and the problem of device compatibility and maintenance difficulty in the shared space is improved, and device operability and user experience are improved.

CN114641969BActive Publication Date: 2025-05-27MICROSOFT TECHNOLOGY LICENSING LLC
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202080076459.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2020-04-13
Filing Date
2020-10-21
Publication Date
2025-05-27
Estimated Expiration
2040-10-21

AI Technical Summary

Technical Problem

Compatibility and maintenance of audio, video and computing devices in shared spaces are difficult, especially in shared spaces of different sizes and layouts, where the troubleshooting and remediation processes are complex and time-consuming.

Method used

The data signals of the peripheral devices in the conference room are captured through the agent and encapsulated with the system metadata into room health data, which is transmitted to the management cloud through the transmitter, so as to monitor and diagnose the health status of the shared space.

Benefits of technology

Simplifies the management and troubleshooting of shared space equipment, improves the operationality and user experience of the equipment, and reduces maintenance costs and time.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114641969B_ABST
    Figure CN114641969B_ABST
Patent Text Reader

Abstract

This document describes a system. The system includes an agent and a transmitter. The agent is used to capture room-specific data signals, operating system data signals, and application data signals from peripheral devices within a conference room, where the application data signals are obtained from a conferencing service application, and where the agent is used to encapsulate the room-specific data signals, operating system data signals, and application data signals with system metadata into room health data. The transmitter transmits the room health data to a management cloud via a communication intermediary.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] Shared spaces are typically equipped with dedicated audio, video, and computing devices. For example, a shared space can be equipped with components such as audio, video, and computing devices to enable collaboration between people in a conference room and those located away from the conference room. Equipping a shared space with appropriate components can be challenging because audio, video, and computing components are often not immediately compatible with other components used in the shared space. Additionally, an organization may have any number of shared spaces, each with a different size, a different layout, and a different component configuration. Once deployed, the components of a shared space can become disabled or inoperable for a number of reasons. If the components of a shared space are disabled or inoperable, it can be difficult and time-consuming to determine the root cause of these failures. Summary of the Invention

[0002] The following presents a simplified summary of the subject innovation in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview of the claimed subject matter. It is neither intended to identify key or essential elements of the claimed subject matter nor to delineate the scope of the invention. Its sole purpose is to present some concepts of the claimed subject matter in a simplified form as a prelude to the more detailed description that is presented later.

[0003] An embodiment provides a system. The system includes an agent and a transmitter. The agent is configured to capture room-specific data signals, operating system data signals, and application data signals from peripheral devices within a conference room, where the application data signals are obtained from a conferencing service application, and where the agent is configured to encapsulate the room-specific data signals, operating system data signals, and application data signals with system metadata into room health data. The transmitter transmits the room health data to a management cloud via a communication intermediary.

[0004] Another embodiment provides a device. The device includes a room health monitor and a transmitter. The room health monitor is configured to generate a room health assessment based on room health data signals received from a shared space, where the room health data signals include room-specific data signals, operating system data signals, application data signals, and metadata in a non-redundant configuration from peripheral devices within the shared space. The transmitter is configured to transmit the room health assessment to a user.

[0005] Additionally, another embodiment provides a method for enabling a managed room backbone. The method includes capturing room-specific data signals, operating system data signals, and application data signals from peripheral devices within a conference room and combining the room-specific data signals, operating system data signals, and application data signals in a non-redundant configuration into room health data. The method further includes transmitting the room health data to a management cloud via a communication intermediary.

[0006] The following description and the drawings set forth in detail certain illustrative aspects of the claimed subject matter. However, these aspects merely represent several of the various ways in which the principles of the present invention may be employed, and the claimed subject matter is intended to include all such aspects and their equivalents. Other advantages and novel features of the claimed subject matter will become apparent from the following detailed description of the invention when considered in conjunction with the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is a block diagram of a network environment including a managed room backbone;

[0008] Figure 2 is a block diagram illustrating components of room health data;

[0009] Figure 3 is a block diagram illustrating the interpretation of received room health data;

[0010] Figure 4 is a flowchart of a method for a managed room backbone;

[0011] Figure 5 is a flowchart of a method for determining remedies and room health profiles;

[0012] Figure 6 is a block diagram illustrating an exemplary computer-readable medium encoded with instructions for a managed room backbone in accordance with aspects of the disclosed subject matter; and

[0013] Figure 7 is a block diagram of an example of a computing system including a managed room backbone. DETAILED DESCRIPTION

[0014] As discussed above, shared spaces may be equipped with audio, video, and computing devices to enable collaboration between people in a conference room and those located remotely from the conference room. Organizations typically have multiple shared spaces, each with different equipment and functionality. As used herein, a shared space is a collaborative meeting area having one or more components that enable information sharing. A shared space may be, for example, a boardroom, a meeting room, or a small conference room. Each shared space may have a different environment, room size, layout, and use. Additionally, each shared space may have different infrastructure. For example, a shared space may support wired or wireless networks, have a specific number of power outlets, have different acoustic characteristics, etc. As used herein, the infrastructure of a shared space includes the physical characteristics of the shared space that are difficult or impossible to change. For ease of description, a conference room may be used as an exemplary shared space to describe the present technology. However, the present technology may be applicable to any shared space.

[0015] The organization's task is to identify the infrastructure for each shared space and equip each space with audio, video, and computing devices based on the identified infrastructure and the desired capabilities of each space. Once the shared spaces are equipped with these collaboration tools, the organization must monitor the devices within each space. Specifically, the organization must ensure that the devices within each shared space are operable according to their intended functions. Since each meeting room has different devices and functions, it is often difficult (if not impossible) to maintain the meeting room devices for multiple shared spaces. Each meeting room can include different cables, connectors, and other interconnectors. Additionally, different devices may have different maintenance tasks, such as specific firmware updates, different components to be monitored, etc.

[0016] Furthermore, the public nature of the shared space may lead to component failures within the space. When the members of the organization are unaware of the specific configuration of the components within the shared space, their use of the space may cause the configuration to be changed, ultimately resulting in a failure. For example, a member may remove a cable or other connector within the shared space to accommodate another preferred cable or connector that the member wishes to use during a meeting. At the end of the meeting, the member may not restore the components to their original configuration. In such a case, subsequent members using the shared space may encounter a failure when using the shared space due to the missing cable.

[0017] This technology enables a managed room backbone. The managed room backbone as described herein includes: an agent that obtains and encapsulates room health data signals; a transmitter that transmits the encapsulated room health signals; and a cloud service that monitors shared space health and diagnoses device problems or issues within the shared space. In an embodiment, room health is determined by analyzing critical hardware signals, available operating system signals, and other application signals related to the meeting room. In an embodiment, the room health information can be combined and uploaded to a management cloud. The meeting room health information can be collected, stored, and analyzed / interpreted at the management cloud. The management cloud can employ machine learning models for telemetry including the meeting room health information in order to determine the likelihood of a problem. The likelihood of a problem can be embodied as a health signal presented to the user. Thus, the analyzed and interpreted meeting room health information can be presented to the user, and the user can be guided to take actions within the meeting room to remedy a situation that negatively impacts the meeting room health. The user can be a member of the organization that owns the meeting room. In an embodiment, the remedy can be performed remotely by a managed room service provider. The managed room service provider can provide the organization with a conduit to remotely access the organization's devices, including each device within the shared space.

[0018] As a preliminary matter, some of the figures depict concepts in the context of one or more structural components, which are variously referred to as functions, modules, features, elements, etc. The various components shown in the figures can be implemented in any manner, such as via software, hardware (e.g., discrete logic components), firmware, or any combination thereof. In some embodiments, the various components may reflect the use of the corresponding components in an actual implementation. In other embodiments, any single component illustrated in the figures may be implemented by multiple actual components. The description of any two or more separate components in the figures may reflect different functions performed by a single actual component. The Figure 1 provides details regarding a system that can be used to implement the functionality shown in the figures.

[0019] Other figures depict these concepts in the form of flowcharts. In this form, certain operations are depicted as constituting different boxes that are executed in a particular order. This implementation is exemplary and not restrictive. Certain boxes described herein can be combined and executed in a single operation, certain boxes can be broken down into multiple constituent boxes, and certain boxes can be executed in an order different from that illustrated herein, including in a parallel manner of executing these boxes. The boxes shown in the flowcharts can be implemented via software, hardware, firmware, manual processing, etc. As used herein, hardware can include a computer system, discrete logic components such as an application specific integrated circuit (ASIC), etc.

[0020] As for terminology, the phrase “configured to” encompasses any way in which any kind of functionality can be constructed to perform the identified operation. The functionality can be configured to perform the operation using, for example, software, hardware, firmware, etc.

[0021] The term “logic” encompasses any functionality for performing a task. For example, each operation illustrated in the flowchart corresponds to the logic for performing that operation. The operation can be performed using, for example, software, hardware, firmware, etc.

[0022] As used herein, the terms “component,” “system,” “client,” “server,” etc. are intended to refer to computer-related entities, hardware, software (e.g., in execution), or firmware, or any combination thereof. For example, a component can be a process running on a processor, an object, an executable, a program, a function, a library, a subroutine, a computer, or a combination of software and hardware.

[0023] By way of illustration, both an application running on a server and the server can be components. One or more components can reside within a process, and a component can be located on one computer and / or be distributed between two or more computers. The term “processor” is generally understood to refer to a hardware component, such as a processing unit of a computer system.

[0024] In addition, the claimed subject matter can be implemented as a method, apparatus, or article of manufacture that uses standard programming and / or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. As used herein, the term "article of manufacture" is intended to cover a computer program accessible from any computer-readable storage device or medium.

[0025] Computer-readable storage media can include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, and magnetic strips, etc.), optical disks (e.g., compact disks (CDs) and digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., cards, memory sticks, and key drives, etc.). In contrast, computer-readable media (i.e., non-storage media) generally can additionally include communication media, such as transmission media for wireless signals, etc.

[0026] Figure 1 is a block diagram of a network environment 100 including a managed room backbone. In environment 100, a managed room backbone 102, a management cloud 104, and a management service provider 106 are shown. Each of the managed room backbone 102, the management cloud 104, and the management service provider 106 can be communicatively coupled via a network 108. The managed room backbone 102 can be executed via a conference room device 110. In an example, the conference room device 110 can be a hub that supports video conferencing and collaboration. In particular, the conference room device 110 can enable room scheduling, screen sharing, and video conferencing. In an embodiment, the conference room device 110 is communicatively coupled with a plurality of peripheral devices via the managed room backbone 102. The conference room device can be networked according to a managed network, a joined domain network, or a zero-trust network (internet connection only).

[0027] As described herein, the managed room backbone 102 is a framework that interconnects peripheral devices and networks to enable seamless collaboration via peripheral functions across one or more networks. The managed room backbone 102 monitors the communication between peripheral devices and the network. The managed room backbone 102 can also monitor the communication with devices / peripheral devices in other conference rooms. In an embodiment, the managed room backbone 102 can act as an interface between the user and each peripheral component. For ease of description, the managed room backbone is described as being executed on the conference room device 110. However, the managed room backbone can also be executed via the management cloud and the management service provider. In an embodiment, each of the managed room backbone 102, the management cloud 104, and the management service provider 106 provides processing, analysis, and feedback on room health data as described herein.

[0028] For example, the managed room backbone 102 can execute on and monitor communication among various peripheral devices within the conference room 112 of the conference room device 110. The conference room device 110 can be a dedicated device with customized hardware and / or software components, as well as a desktop computer, a laptop computer, a tablet computer, a smart phone, and a wearable computing device with customized components, and other similar devices. The conference room device 110 can manage, for example, the peripheral devices 114, 116, 118, 120, 122, 124, 126, and 128. The peripheral devices 114 to 128 can be juxtaposed within the same conference room or shared space. The managed room backbone 102 together with the peripheral devices 114 to 128 enables users to share content, interact and communicate with each other, create and share schedules, and arrange meetings, etc. through various communication modes (such as, e-mail, text message, telephone, video conferencing, etc.). The conference room device 110 can monitor and manage the conference functions enabled by each of the peripheral devices 114 to 128. For example, the conference room device 110 can provide a user interface to access or initiate a conference and manage conference features, such as audio / video control, presentation, recording, etc. enabled by the peripheral devices 114 to 128. The conference room device 110 can communicate with the peripheral devices 114 to 128 via short-range wireless communication such as including near field communication (NFC), Bluetooth communication, personal area network (PAN) communication, and optical communication. The conference room device 110 can also communicate with the peripheral devices 114 to 128 via wired communication (for example, universal serial bus (USB) or similar connections).

[0029] As Figure 1 Illustrated, the peripheral devices 114 to 128 include computing devices such as the laptop computer 114 and one or more servers 116. In an example, the laptop computer 114 and the server 116 can enable computing functions within the conference room or shared space monitored by the conference room device 110 via the managed room backbone 102. In an embodiment, the laptop computer 114 and the server 116 can be shared computing devices associated with a specific conference room or shared space where the peripheral devices are located. In operation, when in the conference room or shared space, any user within the conference room or meeting space can access the laptop computer 114 or the server 116 to implement any number of computing functions.

[0030] Camera 118 enables video or image capture within a conference room or shared space. In an embodiment, camera 118 may be a fixture within the conference room or shared space. In particular, camera 118 may be strategically placed such that all meeting spaces within the conference room or shared space can be captured. In an embodiment, camera 118 may include pan, tilt, and zoom functions to enhance image and video capture within the conference room or shared space. For example, each camera 118 may have a certain range of movement such that the conference room can be fully captured. Each camera 118 is also capable of zooming in on areas, including zooming in on an individual speaker. The specific lenses and other components of camera 118 may be selected based on their suitability for use in a particular conference room for meeting spaces. For example, to fully capture the conference room, camera 118 may include a wide-angle lens.

[0031] Peripheral devices within the conference room or shared space also include microphone 120 and speaker 122. In an embodiment, microphone 120 and speaker 122 may be physically integrated with each camera 118. Additionally, microphone 120 and speaker 122 may be strategically separate components placed within the conference room or shared space. In an embodiment, each microphone 120 may be located within the conference room or shared space such that sound is captured from all locations within the shared space. Further, each speaker 122 may be located within the conference room or shared space such that sound is adequately provided to all locations within the conference room or shared space.

[0032] Peripheral devices also include headphones 124. Headphones 124 may be used to enable private calls or conferences within the conference room or shared space. Accordingly, each headset may include one or more microphones and speakers. In an embodiment, a telephone or speakerphone 126 may be used to access telephone functions within the conference room or shared space. Accordingly, speakerphone 126 may include one or more microphones and speakers. In an embodiment, the speakerphone 126 functionality may be integrated with the conference room device 110. In this way, other conference rooms and people can be accessed from the conference room or shared space. One or more screens 128 may be used to share content or view other meeting participants. In an embodiment, the screen may be a screen, display device, television monitor, computer monitor, etc.

[0033] Although specific peripheral devices have been illustrated as being collocated in the exemplary conference room 112, any number of peripheral devices may be included in the conference room. In addition to the peripheral devices, the conference room or shared space may also include other devices and connectors, such as mounting devices, cables, hubs, and other devices used to connect the peripheral devices to achieve a seamless audio / video experience. In an embodiment, other devices may be selected to achieve interoperability between the peripheral devices. The devices in the conference room may also be used to measure the acoustics of the room as well as the network connection quality to the conferencing service. The acoustics and network connection of the room affect the meeting experience within the conference room and may be measured and analyzed as part of the room health. In an embodiment, the managed room backbone may initiate a test call and simulate sound via the speaker 122, the headset 124, or the speakerphone 126 to determine the audio characteristics of the room, network connectivity and quality, and the correctness of the configuration. Signals from the test call and the simulated sound may be captured by the microphone 120, the headset 124, or the speakerphone 126 and included in a heuristic method for determining the acoustic health signal. In this way, different acoustic characteristics of each shared space may be determined in real time.

[0034] In an embodiment, the managed room backbone 102 may monitor hardware signals from each of the peripheral devices 114 through 128. In addition to the hardware signals associated with each peripheral device, the managed room backbone 102 may also monitor operating system signals associated with the peripheral devices. Further, the managed room backbone 102 may capture signals from other applications executing on devices within the conference room or shared space. For example, data from other applications may include peripheral supplementary data and telemetry heartbeats. The managed room backbone 102 may also query hardware signals specific to a particular device type. For example, an application programming interface (API) from a particular hardware manufacturer may be queried to obtain more specific error codes or signals associated with a particular device. The managed backbone 102 may combine this information and securely transmit this information across the network 108 to the management cloud 104. The combined data signals are generally referred to as room health data. In an embodiment, the information may be selectively combined or encapsulated to reduce the transmission of redundant signals or signals currently not relevant to room health.

[0035] The management cloud 104 includes a room health data repository 130 and a room health monitor 132. In an embodiment, the room health monitor 132 may analyze the obtained room health data to determine the health status of the meeting room 112. As used herein, health generally refers to whether the meeting room is suitable for a shared, collaborative user experience. The overall health of the meeting room is at least partially based on the health of the meeting room devices, peripherals, and other equipment, including each connection that enables interoperability across the meeting room devices and peripherals. The room health monitor may evaluate multiple health metrics based on the received room health data. This evaluation may be an interpretation of the health status of the meeting room and any devices within the meeting room. For ease of description, the management cloud 104 is illustrated as communicatively coupled to a single meeting room 112. However, the management cloud according to the present technology may manage any number of shared spaces across any number of organizations. Thus, the managed room system according to the present technology may use aggregated telemetry to identify broader outages and report these outages to the user. For example, if all devices in a particular area have connectivity issues, the present technology may notify the user of the managed room system that there is a network outage across the entire area.

[0036] In an embodiment, an assessment of the room health is provided to the on-site user of the meeting room. As used herein, the on-site user may be located within the meeting room 112 and may view the room health assessment via the meeting room device 110. In an embodiment, the user who views the assessment of the room health of the meeting room may be an organizational member located anywhere within the organization. Additionally, in an embodiment, a user with appropriate credentials may access the room health data from any location via an electronic device. Thus, the analyzed room health data may be provided via a dashboard of the managed room backbone 102 executed on the meeting room device 110. The analyzed room health data may also be provided via a dashboard executed on another device within the organization. In the event that the room health assessment indicates a problem or failure of a component within the meeting room, the management cloud 104 may also transmit a remediation task or strategy to the user. In some cases, the management service provider 106 may perform remote remediation of the meeting room 112. The remote remediation may be automatically performed via a remediation server 134. A remediation specialist 136 may also access the room health assessment and provide remote remediation.

[0037] In an embodiment, remediation can include restoring the original configuration of the peripheral devices in the meeting room. For example, this can include ensuring that the cable connections are intact. Remediation can also include tasks specific to the peripheral devices, such as updating drivers or firmware. Other exemplary remediations include operating system remediations, such as setting power plans, lock policies, updating and applying operating system patches and security policies, etc. Applying remediation can include comparing the application configuration with the physical configuration. For example, comparing the expected display configuration of the application with the actual physical configuration visible to the people in the meeting room. In this example, the application may intend to project onto two displays in the front of the room, but in fact only one display exists. The remediation in this example includes detecting the difference in the display projection and correcting the application configuration as needed. Additionally, remediation can include detecting proxy configurations from the operating system and other devices and applying the proxy configurations to devices that lack such proxy configurations and associated states.

[0038] Figure 1 The block diagram is exemplary and should not be considered limiting to the managed room backbone or network environment. Note that the managed room backbone or networking environment can have more or fewer blocks than those illustrated in the Figure 1 example. Additionally, some blocks can be implemented via computing devices such as Figure 7 of the system 700. In particular, environment 100 can include fewer or additional components not illustrated in the Figure 1 such as additional instances of the managed room backbone, additional instances of the management service provider, additional management clouds, additional networks, etc. Depending on the details of the specific implementation, environment 100 can include Figure 1 any number of additional components not shown in the

[0039] Figure 2 is block diagram 200 illustrating components of room health data. In an embodiment, the managed room backbone includes an application programming interface (API) for capturing data signals, encapsulating data signals and metadata, and uploading the encapsulated data to the management cloud. The API can define variables, object classes, routines, and data structures that specify the communication details between the managed room backbone and the management cloud. The API can be used to abstract the implementation of a particular operating system and provide access to objects or actions within the implementation in an expected and predictable manner. For example, exemplary API functionality includes implementing access to system resources such as memory, file system, processes, threads, and devices. The API can also implement access to the data signals described herein.

[0040] In an embodiment, the API can be a Windows API, such as Win32. Win32 is an API implemented on a 32-bit platform of a Windows-based architecture. The API can also be a Mobile Device Management (MDM) API or a Windows Management Instrumentation (WMI) API. Although specific APIs are described herein, the technology is not limited to any particular API. Thus, the use of the Win32 API is for ease of description and should not be construed as a limitation on the technology.

[0041] The agent can be based on the Win32 API and can access the services provided by the API in a continuous and autonomous manner. In particular, the Win32 agent can obtain information related to the health of the peripheral devices in the meeting room for further processing by the managed room backbone. As used herein, an agent is a software application or program that can complete tasks without intervention or request. In an embodiment, the agent can automatically capture multiple signals related to the health of the meeting room and combine or encapsulate these signals for transmission. Thus, at block 202, room-specific data signals are illustrated. The room-specific data can be obtained from the meeting service application. The meeting service application can export an interpretation of the room health for each individually managed room. In an embodiment, the meeting service application may experience multiple events that can be captured by the agent as room-specific data signals. The room-specific data includes data that can indicate the presence of specific peripheral devices in the meeting room. For example, the agent can obtain data indicating the presence of a specific device in the meeting room. If the expected devices in the meeting room do not match the actual devices in the meeting room, the agent can capture this difference as room-specific data. In some cases, the lack of data from the meeting service application can indicate that the meeting service application is not currently executing. The non-execution of the meeting service application can indicate a failure within the managed room. The room-specific data can also include specific settings that are applied to manage the devices in a particular meeting room. For example, settings can be applied to restrict or guide the use of specific peripheral devices in the meeting room. In an embodiment, the settings can be applied by the administrator of a specific meeting room.

[0042] At block 204, an operating system data signal is illustrated. The agent may also capture events from the operating system as operating system data signals. In an example, the operating system may be a Windows operating system. Events observed by the operating system include, but are not limited to, a list of all connected peripheral devices, USB device changes, crashes or faults, specially installed software, running processes, etc. Crash or fault events may include blue screen crashes or driver crashes logged in Windows Error Reporting. Running processes may include all running processes, including specific processes such as antivirus processes. Additionally, these events may include specific operating system configurations surrounding locking, maintaining the current state, and managing configurations copied or obtained from the management interface. In an embodiment, this information may be obtained by querying operating system policies. For example, conference room peripheral devices or equipment may be subject to specific policies that govern the user interface layout displayed at the peripheral device or equipment. In another example, the operating system of a peripheral device may be prohibited from drawing certain menus or features. In an embodiment, this may be referred to as a locking policy. Additionally, in some cases, the agent may be aware of specific operating system events and capture these events as operating system data signals.

[0043] At block 206, an application data signal is illustrated. The agent may also capture events from applications associated with the conference room and executed on conference room devices. For example, applications include a telemetry heartbeat application and a peripheral supplementary data application. The telemetry heartbeat application may enable one or more components within a specific conference room to send periodic pings or other signals to ensure the device is operational. For example, a service, server, computing device, or peripheral device executing within the conference room may send a heartbeat ping to the telemetry heartbeat application to confirm that the device is operating as expected. In some cases, the telemetry heartbeat application may output a heartbeat request to each peripheral device. In the case where a peripheral device does not respond to the heartbeat request, an event may occur that is captured by the agent as an application data signal. In an embodiment, the peripheral supplementary data application enables querying recommendations via input operational protocols and third-party APIs to determine fault codes. Additionally, application data signals include whether the application can log in to its conference service, whether the application can retrieve its schedule, whether the application is running, whether the application has crashed, and other faults reported by the application in its error report.

[0044] At block 208, each of the room-specific data signal, the operating system data signal, and the application data signal may be combined and encapsulated. In an embodiment, the signals are encapsulated together with system metadata. System metadata may include the location and identity of the installed operating system, the agent, and other key versions. In an embodiment, the operating system version, key version, etc. are taken from the conference room device.

[0045] Encapsulated signals and metadata can be referred to as room health data. In an embodiment, the room health data can be selectively combined or encapsulated to reduce the transmission of redundant signals or signals that are currently not relevant to the room, thereby deriving an enhanced aggregated signal representing room health. Thus, the encapsulated signals and metadata can be encapsulated into a non-redundant aggregated signal representing room health. For example, if the operating system reports the presence of a peripheral device, but the conferencing application reports the absence of the peripheral device, it can be determined that the fault lies in how the peripheral device is selected and / or shared with other applications. In the prior art, each of the operating system report and the conferencing application report can be transmitted for further analysis. However, the present technology combines this information into a single signal representing the difference between the operating system and the conferencing application, and transmits the aggregated signal to the management cloud for further analysis or interpretation. In an example where neither the operating system nor the conferencing device reports the presence of the peripheral device, it is likely that the peripheral device is physically disconnected from other conferencing devices in the meeting room. The present technology can combine this information into a single signal representing the protocol between the operating system and the conferencing application, and transmit the aggregated signal to the management cloud for further analysis or interpretation. Thus, the room health signals according to the present technology can be encapsulated such that it represents the differences between room devices.

[0046] At block 210, room health data is uploaded to a management cloud for further interpretation and analysis. In an embodiment, the room health data can be conveyed to the management cloud via a communication broker / bus. In an embodiment, the communication broker / bus can be an Internet of Things (IoT) hub or an Azure IoT hub. In some cases, the communication broker / bus can be a cloud-managed management service that acts as a central messaging hub for two-way communication between the management cloud and the managed room backbone. As used herein, the term "communication broker / bus" is not limited to a specific type of IoT service, but rather refers to a device that communicates with the managed room backbone for secure communication with the management cloud. Thus, in an embodiment, the meeting room device can include the managed room backbone and the communication broker / bus. The communication broker / bus can support communication both from the managed room backbone to the management cloud and from the management cloud to the managed room backbone. The communication broker / bus as described herein supports multiple messaging modes, such as backbone-to-cloud telemetry, file upload from the managed room backbone, and a request-response method for cloud-controlled managed room backbone. This functionality can be based on identifying a specific managed room backbone, where each managed room backbone instance can correspond to a specific shared space. The communication broker / bus can identify the managed room backbone via an identity proofing process using a Trusted Platform Module (TPM). Additionally, the communication broker / bus can identify the managed room backbone via an identity proofing process using meeting room account login credentials. The TPM can issue a nonce challenge to a key using the TPM standard to provide a signed Shared Access Signature (SAS) token during the identity proofing process. The TPM standard is the TPM2.0 Library Specification released on June 29, 2015. In an embodiment, the IoT hub can also provide conveyance and storage for files.

[0047] Figure 3FIG. 300 is a block diagram illustrating the interpretation of received room health data. At block 302, room health data is received. In an example, the room health data can be received by a management cloud. The room health data can be, for example, a combination of room-specific data signals, operating system data signals, application data signals, and metadata captured in a meeting room. The received room health data can be stored in a room health data repository 304. Additionally, at block 306, the room health data can be used to record a data report. The data report can include all captured room-specific, operating system, and application data signals within the record corresponding to a user, device, room, organization, or any combination thereof. The data report can also store associated metadata (such as, reporting time) into a compliance data repository partitioned by a user, device, room, organization, or any combination thereof. In an example, the compliance data repository can be an Azure Cosmos database. Individual signals and / or aggregated reports can be queried in the database. The record can include other metadata, such as room survey data, desired configurations of users, devices, rooms, organizations, etc.

[0048] Generally, room health data (such as, room-specific data signals, operating system data signals, application data signals, and metadata) captured in a shared space can be monitored to ensure the correct operation of each device in the space. In an embodiment, a managed room backbone monitors and maintains the room health data to maintain and enhance the performance of devices within the shared space. For example, the managed room backbone ensures that the correct set of applications is installed on devices in the shared space and that no irrelevant applications are installed. In response to an incorrect set of applications detected in the shared space, the managed room backbone can also perform mitigation measures such as uninstalling software. The managed room backbone can also ensure that the correct applications are running and that no irrelevant applications are running based on the usage scenario of the shared space. For example, when the shared space is used for collaboration with other shared spaces, it may be desirable to execute specific applications. When the shared space is not in use, another set of applications may be executed. The managed room backbone can also perform mitigation measures such as stopping or terminating an application that should not be executing in response to detecting that the application that should not be executing is executing. The managed room backbone can also monitor the application manifest and compare it to a baseline of expected software required to keep the device operational.

[0049] Additionally, the managed room backbone can monitor the size of the registry and determine where it might change by taking snapshots and analyzing the snapshots. The managed room backbone can also monitor the performance of the hard disk drive of the device, including fragmentation status, available space, and performance metrics. The performance metrics can include, but are not limited to, reads / writes per second, cache utilization, etc. Additionally, the managed room backbone can perform mitigation measures such as deleting caches, temporary files, unwanted software, and invoking defragmentation operations on the drive. Other monitoring scenarios include monitoring the overall CPU utilization over a period of time and monitoring the CPU utilization of the applications being executed. Additionally, the managed room backbone can be configured to monitor drivers, proxy settings, and e-CDN settings specific to intensive operations such as video rendering and audio / video streaming.

[0050] At block 308, the room health data can be interpreted. Interpreting the room health data includes analyzing the room health data in view of expected room health data values. In an embodiment, the room health data can be interpreted via machine learning techniques to determine the likelihood of one or more problems. At block 310, insights and analytics are provided based on the interpreted room health data. In particular, the room health data can be plotted and aggregated into a human-readable form. Trends and common failure modes can be identified from the interpreted room health data. Patterns can be identified across any reporting attributes expected in the meeting room. For example, patterns can be identified in any reporting attribute such as location, recommendation, manufacture, or problem category. In some cases, the category of the problem can be identified via a diagnostic code. Room acoustics and network connectivity can be measured and interpreted as components of the meeting room health. In an embodiment, the room health assessment can be determined by interpreting the room health data or providing insights and analytics based on the interpreted room health data. The room health assessment can indicate the overall health or rating of the shared space, as well as the health of the peripherals, devices, and interconnects within the shared space.

[0051] Additional statistical analysis of the interpreted room health data can be enabled. For example, trends and common failure modes can be identified based on a time range. Specifically, any trends or patterns can be analyzed to determine outliers and anomalies within each trend or failure mode. Additionally, each trend and failure mode can be analyzed in view of its recurrence within the time range. In addition to identifying trends in common failure modes, usage patterns within the managed conference rooms can be determined. Further, a return on investment (ROI) calculator can be used to calculate the cost savings of remote meetings compared to meeting with everyone in person. Insights can also be based on a comparison of the managed room data of an organization with the general managed room data from other organizations. For example, the performance of a single organization can be compared to multiple tenant metrics. Badges can be assigned to the performance of individual users / organizations, resulting in gamification of positive behavior. The insights and analysis can be provided to users within the organization. Based on a review of the insights and analysis, users can make decisions regarding specific devices and capabilities established in specific conference rooms of the organization.

[0052] At block 312, alerts are derived from the room health data. In an embodiment, an alert engine can analyze the room health data to determine whether an alert should be generated. In an embodiment, the alert can be activated at block 314 in response to detecting an alert condition. In an embodiment, the present technology can analyze aggregated room health data from multiple rooms across one or more organizations. Telemetry data from multiple rooms across one or more organizations is aggregated and interpreted to determine broader outages and report them to the user. For example, if all devices in a geographical area encompassing multiple organizations exhibit connectivity issues, the present technology can indicate an outage for the entire area. The outage can be indicated by activating an alert.

[0053] At block 316, a remedy or remediation strategy is determined. In an embodiment, the remedy or remediation strategy is a response to the activated alert. In an embodiment, specific alerts and remedies can be transmitted from the management cloud to a specific instance of the organization's managed room backbone. The dashboard of the managed room backbone can display the alerts and any other associated information. Additionally, the dashboard of the managed room backbone can also display the remediation strategy. At block 318, the remediation strategy can be applied to the conference room. In an embodiment, a user can implement one or more remediation strategies to eliminate the activated alert. In an embodiment, the managed room backbone can automatically implement the remediation strategy. Remediation strategies include, but are not limited to, resetting the machine, reimaging, and rebuilding to a known baseline. The known baseline can be those baselines known to the managed room backbone.

[0054] To derive alerts from received room health data, the room health data can be compared against multiple rules or requirements for a specific meeting room. The room health data can also be compared against supplementary user / organizational directives, such as suppression or administrative room markings, business hours, etc. Comparing the room health data against expected data values and supplementary organizational directives in a rule-based manner can be included in the room health assessment of a meeting room. In an example, the received operating system data signal can be compared against the expected data signal from a management application. When analyzing the room health data to determine alerts, a time delay can be added for noisy event types that require multiple instances in order to activate an alert. In an embodiment, the data received from the health data can also be compared against the user-submitted roles. User roles can include suppression (where alerts are ignored for a certain period of time or always), maintenance windows, and / or can include higher alert level definitions. Higher alert definitions can be used for critical rooms such as executive rooms, important person (VIP) rooms, large multi-functional rooms, etc. If the received room health data does not meet the user / organization-submitted roles, an alert can be generated.

[0055] Using user-submitted roles can be referred to as suppression. In an example of suppression, the user can determine that a particular room health signal is irrelevant. Consider a high-end meeting room with a display that consumes a large amount of power. The display might be powered off to save power. However, outside of typical business hours, the user can choose to suppress the room health signal indicating that the display is off as an alert condition. However, in important or highly visible meeting rooms (such as boardrooms or executive rooms), the user might want to be immediately notified of the room health signal. In some cases, the user might want to be immediately informed of any issues before any analysis is done or a remediation strategy is determined. In an embodiment, based on the settings or policies of a specific room, room health notifications can be provided to the user via text or push notifications.

[0056] In an embodiment, the room health data can be compared against a list of expected values, such as expected firmware, expected installed updates, operating system version, application version, and basic input / output system (BIOS) version. Thus, the room health data can include, for example, expected firmware, expected installed updates, operating system version, application version, and basic input / output system (BIOS) version. In the case where the received room health data does not match the list of expected values, an alert can be generated. Additionally, the room health data can be compared against a list of unexpected values that are not baseline, such as a spurious process running or installed software that does not belong to the baseline. If any of these unexpected values are met, an alert might be derived. In addition to comparing values against the room health data, alerts can also be derived by querying peripheral devices via interoperability protocols and third-party APIs to determine fault codes.

[0057] Health patterns of an organization can be tracked via an inferred maintenance window or an inferred broader maintenance or disruption. A managed room backbone can be used as a detector to detect intentional or unintentional broader patterns occurring in the organization. Generally, adding device patterns to the room enables understanding of the overall organization's health, including both planned and unplanned.

[0058] While specific scenarios for deriving alerts have been described, alerts are generally determined when some anomaly or other exceptional condition is detected in the room health data. This technique is not limited to the specific comparisons described above as these are for illustrative purposes. When alert conditions are derived, the alerts are activated. To activate an alert, a support ticket can be created as part of the alert. In an embodiment, the support ticket has an attached parent alert. The parent alert is derived at block 312. It is determined whether the ticket should be directly dispatched to the organization or a managed service provider for further investigation. In response to the activation of the alert, usage patterns and flagged characteristics can be analyzed to detect anomalies and generate a possible problem determination. The possible problem determination can be represented by a unique diagnostic code. In an embodiment, diagnostic information and the unique diagnostic code can be automatically attached to the support ticket. Data signals from agents can be used to detect anomalies and generate a possible problem determination. The data signals can be the room health data as described above. Thus, the data signals are obtained from peripheral devices, operating systems, and other conferencing devices. The data signals include, but are not limited to, recurrence numbers, device identifiers (such as names), USB standards (such as product identification (PID) and vendor identification (VID)), activation or deactivation times - including whether during business hours or non-business hours, parent characteristics (such as whether the device is attached to another device with a different power profile (e.g., a USB hub or a USB extender)), and the power state of the system (including the display and the processor).

[0059] A user can review the room health data in a managed service portal. Generally, the user can access the managed service portal in response to an event, which is a combination of an activated alert and a support ticket. Only users within the organization can communicate with the managed service provider in the context of a specific event. Then, an operator can conduct an investigation and make a response to remedy the problem. In an embodiment, the managed service provider can include operators (such as remediation experts) on standby to assist with remediation. Additionally, the operator can also proactively communicate with the users of the meeting room to mitigate room health issues before they negatively impact the user experience within the meeting room.

[0060] Figure 4It is a process flow diagram of a method 400 for implementing a managed room backbone network. At block 402, room-specific data is captured. At block 404, operating system data is captured. At block 406, application data is captured. The captured data can be captured by an agent in a continuous and autonomous manner. For example, the agent can capture data related to the health of components in a meeting room for further processing by the managed room backbone network. In an embodiment, the room-specific data, operating data, and application data include telemetry measured for each corresponding data type. At block 408, the captured data is combined. In an embodiment, the combined data signal is generally referred to as room health data. In an embodiment, the room health data can be selectively combined or encapsulated to reduce the transmission of redundant signals or signals that are currently not relevant to room health. Thus, the room-specific data signal, the operating system data signal, and the application data signal can be encapsulated in a non-redundant configuration to form room health data. At block 410, the captured data is transmitted to interpret room health.

[0061] Figure 5 It is a flowchart of a method 500 for determining remedies and a room health profile. In some examples, a management cloud can be used to generate a room health assessment. In an embodiment, the room health assessment can include remedies and a room health profile. A remedy or a remediation strategy can include instructions to correct issues that have a negative impact on room health. The room health profile can be an image, a video, or a chart that conveys the current room health. At block 502, room health data is received. In an embodiment, the room health data can be received at the management cloud via a communication intermediary / bus. At block 504, the required remedies are determined based on the room health data. In an embodiment, aggregated telemetry data from devices across multiple rooms or organizations is analyzed and interpreted to identify broader outages. An assessment including remedies can be generated. At block 506, any assessment, remedies, and the room health profile are transmitted to a user. In an embodiment, the remedies can be transmitted via a portal, email, short message service (SMS), or any other communication mode. For ease of description, the assessment, remedies, and the room health profile are described as being transmitted to a user. The user can be a member of an organization that controls or owns the corresponding shared space. The user can also be a remediation expert or other professional obtained by the organization to implement or perform actions to correct any alert conditions found in the assessment, remedies, or the room health profile. In an embodiment, one or more of the remedies in the room health assessment are iteratively executed until the updated room health assessment is satisfactory. The room health assessment can be continuously updated in response to the executed remedies. A satisfactory room health assessment can be one in which all components are fully operable according to their intended functions.

[0062] Turn to Figure 6 , Figure 6is a block diagram illustrating an exemplary computer-readable medium encoded with instructions for a managed in-room backbone network according to aspects of the disclosed subject matter. More specifically, implementation 600 includes a computer-readable medium 608 (e.g., a disc of a CD-R, DVD-R, or hard drive), on which computer-readable data 606 is encoded. This computer-readable data 606 in turn includes a set of computer instructions 604 configured to operate in accordance with one or more principles set forth herein. In such an embodiment 602, the processor-executable instructions 604 can be configured to perform a method, such as Figure 4 at least some of the exemplary method 400 of Figure 5 or at least some of the exemplary method 500 of Figure 7 as described below. In such another embodiment, the processor-executable instructions 604 can be configured to implement a system, such as

[0063] Figure 7 is a block diagram of an example of a computing system including a managed in-room backbone network. Example system 700 includes a computing device 702. The computing device 702 includes a processing unit 704, a system memory 706, and a system bus 708. In some examples, the computing device 702 can be a game console, a personal computer (PC), an auxiliary console, a game controller, and other computing devices. Additionally, the computing device 702 is not limited to a particular architecture. In an example, the computing architecture can be, for example, an x86 architecture, an Advanced RISC Machines (ARM) architecture, or any other computing architecture.

[0064] The system bus 708 couples system components, including but not limited to the system memory 706, to the processing unit 704. The processing unit 704 can be any of a variety of available processors. Dual microprocessors and other multiprocessor architectures can also be used as the processing unit 704.

[0065] The system bus 708 can be any of a multitude of types of bus structures, including a memory bus or memory controller, a peripheral bus or external bus, and a local bus using any kind of available bus architecture known to those of ordinary skill in the art. The system memory 706 includes computer-readable storage media, including volatile memory 710 and non-volatile memory 712.

[0066] The BIOS, which contains basic routines for transferring information between elements within computer 702, such as during startup, is stored in non-volatile memory 712. By way of illustration and not limitation, non-volatile memory 712 can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory.

[0067] Volatile memory 710 includes random access memory (RAM) that acts as an external cache. By way of illustration and not limitation, RAM comes in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), SynchLink TM DRAM (SLDRAM), direct RAM (RDRAM), direct dynamic RAM (DRDRAM), and dynamic RAM (RDRAM).

[0068] Computer 702 also includes other computer-readable media, such as removable / non-removable, volatile / non-volatile computer storage media. Figure 7 Shown, for example, is disk storage 714. Disk storage 714 includes, but is not limited to, devices such as disk drives, floppy disk drives, tape drives, Jaz drives, Zip drives, flash memory cards, or memory sticks.

[0069] In addition, disk storage 714 can include storage media alone or in combination with other storage media, where the other storage media includes, but is not limited to, optical disk drives such as compact disk ROM devices (CD-ROM), CD recordable drives (CD-R drives), CD rewritable drives (CD-RW drives), or digital versatile disk ROM drives (DVD-ROM). To facilitate connection of disk storage device 714 to system bus 708, a removable or non-removable interface such as interface 716 is typically used.

[0070] It should be understood, Figure 7Describes software that acts as a mediator between a user and the basic computer resources described in a suitable operating environment 700. Such software includes an operating system 718. The operating system 718 (which can be stored on disk storage 714) is used to control and allocate the resources of computer 702. The operating system 718 described herein is not limited to a particular operating system. In an example, the operating system can be, for example, a Windows-based operating system, an Android-based operating system, an iOS-based operating system, or any other operating system.

[0071] System applications 720 utilize the operating system 718 for resource management through program modules 722 and program data 724 stored in system memory 706 or disk storage 714. It should be understood that the disclosed subject matter can be implemented with various operating systems or combinations of operating systems.

[0072] The user inputs commands or information into computer 702 through input device 726. Input device 726 includes, but is not limited to, pointing devices such as a mouse, trackball, stylus, etc., keyboard, microphone, joystick, satellite antenna, scanner, TV tuner card, digital camera, digital video camera, web camera, any suitable dial-up attachment (physical or virtual), etc. In some examples, the input device can include a natural user interface (NUI) device. An NUI refers to any interface technology that enables a user to interact with a device in a "natural" way, free from the artificial constraints imposed by input devices such as a mouse, keyboard, remote control, etc. In some examples, NUI devices include devices that rely on speech recognition, touch and stylus recognition, gesture recognition on and near the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gesture, and machine intelligence. For example, an NUI device can include a touch-sensitive display, voice and speech recognition, intent and goal understanding, and motion gesture detection using a depth camera (such as a stereo camera system, an infrared camera system, an RGB camera system, and combinations thereof). NUI devices can also include motion gesture detection using an accelerometer or gyroscope, face recognition, three-dimensional (3D) displays, head, eye, and gaze tracking, immersive augmented reality and virtual reality systems, all of which provide a more natural interface. NUI devices can also include technologies that use electric field sensing electrodes to sense brain activity. For example, an NUI device can use electroencephalography (EEG) and related methods to detect the electrical activity of the brain. Input device 726 is connected to processing unit 704 via interface port 728 through system bus 708. Interface port 728 includes, for example, serial ports, parallel ports, game ports, and universal serial bus (USB).

[0073] Output device 730 uses some of the same type of ports as input device 726. Thus, for example, USB ports can be used to provide input to computer 702 and output information from computer 702 to output device 730.

[0074] Output adapter 732 is provided to illustrate that there are some output devices 730, such as monitors, speakers, and printers, and other output devices 730 that can be accessed via the adapter. By way of illustration and not limitation, output adapter 732 includes video and sound cards that provide a means of connection between output device 730 and system bus 708. It may be noted that other devices and device systems provide input and output capabilities, such as remote computing device 734.

[0075] Computer 702 can be a server that hosts various software applications using logical connections to one or more remote computers (such as remote computing device 734) in a network environment. Remote computing device 734 can be a client system configured with a web browser, PC applications, mobile phone applications, etc. Remote computing device 734 can be a personal computer, server, router, network PC, workstation, microprocessor-based device, mobile phone, peer device, or other common network nodes, etc., and generally includes many or all of the elements described with respect to computer 702.

[0076] Remote computing device 734 can be logically connected to computer 702 via network interface 736 and then via a communication connection 738 that can be wireless. Network interface 736 includes wireless communication networks, such as local area networks (LANs) and wide area networks (WANs). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring, etc. WAN technologies include, but are not limited to, point-to-point links, circuit-switched networks (such as Integrated Services Digital Network (ISDN) and its variants), packet-switched networks, and Digital Subscriber Line (DSL).

[0077] Communication connection 738 refers to the hardware / software used to connect network interface 736 to bus 708. Although communication connection 738 is shown inside computer 702 for purposes of illustration, it can also be outside computer 702. For illustrative purposes, the hardware / software used to connect to network interface 736 can include internal and external technologies, such as mobile phone switches, modems including conventional telephone-grade modems, cable TV modems, and DSL modems, ISDN adapters, and Ethernet cards.

[0078] The computer 702 may also include a radio device 740. For example, the radio device 740 may be a wireless local area network radio device that may operate on one or more wireless frequency bands. For example, the radio component 740 may operate on the industrial, scientific, and medical (ISM) radio frequency band at 2.4 GHz or 5 GHz. In some examples, the radio device 740 may operate at any radio frequency on any suitable radio frequency band.

[0079] The computer 702 includes one or more modules 722, such as a managed room backbone 742. In some embodiments, the managed room backbone 742 interconnects the peripherals in an organization's conference room with the network. The organization may have any number of conference rooms, and each conference room may include a managed room backbone. In an embodiment, the managed room backbone 742 enables seamless collaboration across one or more networks via peripheral functionality. The managed room backbone monitors the communication between the peripherals and the network. The managed room backbone may also monitor the communication between other conference rooms. In an embodiment, the managed room backbone may act as an interface between the user and each peripheral component.

[0080] It should be understood that Figure 7 the block diagrams are not intended to indicate that the computing system 702 is to include Figure 7 all of the components shown in Figure 7 Rather, the computing system 702 may include fewer or additional components not shown in

[0081] (e.g., additional applications, additional modules, additional memory devices, additional network interfaces, etc.).

[0081] It should also be noted that the different embodiments described herein may be combined in different ways. That is, parts of one or more embodiments may be combined with parts of one or more other embodiments. All of these are contemplated herein.

[0082] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A system for implementing a managed room backbone network, comprising: an agent, configured to: execute on a conference room device, wherein the conference room device is configured to be communicatively coupled via short-range wireless communication or wired communication to peripheral devices co-located in the same conference room; capture a conference room specific data signal from the peripheral devices, an operating system data signal associated with the peripheral devices, and an application data signal obtained from a conference service application; encapsulate the conference room specific data signal, the operating system data signal, and the application data signal together with system metadata into room health data; and a transmitter, configured to transmit the room health data to a management cloud via a communication intermediary; and a receiver, configured to receive from the management cloud a room health assessment for the conference room and a corresponding remediation strategy; wherein the agent is configured to locally and automatically implement at least part of the corresponding remediation strategy.

2. The system according to claim 1, wherein the system further comprises the management cloud, and wherein the management cloud comprises a room health monitor, configured to statistically analyze the room health data to determine the room health assessment of the conference room.

3. The system according to claim 1, wherein the management cloud is configured to compare the room health data with expected data values and supplementary organizational instructions in a rule-based manner to determine the room health assessment of the conference room.

4. The system according to claim 1, wherein the system further comprises the management cloud, and wherein the management cloud is configured to store the room health data in a room health data repository.

5. The system according to claim 1, wherein the system further comprises the management cloud, and wherein the management cloud is configured to access the room health data via a room health monitor.

6. The system according to claim 1, wherein the peripheral devices include a camera, a microphone, a hands-free phone, a speaker, headphones, a laptop, a server, or any combination thereof.

7. The system according to claim 1, wherein the conference room device is configured to be networked according to a managed network, a domain-joined network, or on a zero-trust network.

8. An apparatus for implementing a managed room backbone network, comprising: a room health monitor, configured to generate a room health assessment and a corresponding remediation strategy based on a room health data signal received from a conference room device, the conference room device being configured to be communicatively coupled via short-range wireless communication or wired communication to peripheral devices co-located in the same conference room, wherein the room health data signal comprises a conference room specific data signal from the peripheral devices in the conference room captured by an agent executing on the conference room device and encapsulated by the agent in a non-redundant configuration, an operating system data signal associated with the peripheral devices, an application data signal obtained from a conference service application, and metadata, and wherein the generated corresponding remediation strategy is designed to be at least partially executed locally by the agent; and A transmitter, configured to transmit the room health assessment and the generated corresponding remediation strategy to the conference room device on which the agent is executing.

9. The apparatus according to claim 8, wherein the room health assessment includes remediation and a room health profile.

10. The apparatus according to claim 8, wherein the corresponding remediation strategy includes one or more remediations, and the one or more remediations will be iteratively executed until the updated room health assessment is satisfactory.

11. The apparatus according to claim 8, wherein the corresponding remediation strategy is also designed to be partially executed by a managed service provider, and includes transmitting the room health assessment and the corresponding remediation strategy to the managed service provider, wherein the managed service provider is configured to perform remote remediation of the conference room as indicated by the room health assessment and the corresponding remediation strategy.

12. A method for implementing a managed room backbone comprising: capturing, via an agent executing on a conference room device, a conference room specific data signal from a peripheral device placed within the same conference room, an operating system data signal associated with the peripheral device, and an application data signal obtained from a conference service application, the conference room device being communicatively coupled to the peripheral device within the conference room via short-range wireless or wired communication; combining the conference room specific data signal, the operating system data signal, and the application data signal in a non-redundant configuration to form room health data; transmitting the room health data to a management cloud via a communication intermediary; receiving, via the communication intermediary, a room health assessment for the conference room and a corresponding remediation strategy from the management cloud; and automatically locally implementing at least a portion of the corresponding remediation strategy.

13. The method according to claim 12, comprising: comparing, via a room health monitor of the management cloud, the room health data with expected data values and supplementary organizational instructions in a rule-based manner to determine the room health assessment of the conference room.

14. The method according to claim 12, comprising: comparing, via a room health monitor of the management cloud, the room health data with a role submitted by a user, and suppressing a room health signal of the room health data in response to the role submitted by the user.

15. The method according to claim 12, wherein the communication intermediary is a cloud-hosted managed service that acts as a central message hub for two-way communication.

16. The method according to claim 12, including automatically executing a second portion of the corresponding remediation strategy.

Citation Information

Patent Citations

  • Residential building indoor environment monitoring and health grade evaluation Internet of Things system

    CN105116848A

  • Service level view of audiovisual conference systems

    US20130250038A1

  • Recording web conferences

    US9699409B1