HK1245040B - System architecture for office productivity structure communications - Google Patents

Description

System Architecture for Office Productivity Structured Communications

Cross-reference to related applications

This application claims the benefit of priority to U.S. Provisional Application No. 62/097,439, filed December 29, 2014, and U.S. Provisional Application No. 62/174,333, filed June 11, 2015, both of which are hereby incorporated by reference in their entireties.

Background Art

Every year, managers and employees spend millions of hours sitting at work. Manager and employee productivity ultimately impacts output and, therefore, company profitability. Devices and/or other workplace structures designed to help workers identify optimal work habits and improve interactions with other workers have the potential to increase per capita output. Therefore, improvements in how devices and systems foster these habits and interactions could drive consumer demand for these products.

Summary of the Invention

In one embodiment, the present invention provides a furniture system comprising a chair having a seat, a backrest coupled to the seat, and a base supporting the backrest and the seat. The furniture system also includes a plurality of sensors coupled to the chair. Each sensor is operable to detect a physical force imparted to the chair by a user and to generate an output signal indicative of the physical force. The furniture system further includes a processor coupled to the plurality of sensors. The processor is operable to receive the output signals generated by the plurality of sensors and to determine a current posture of a user sitting in the chair based on at least one of the output signals.

In another embodiment, the present invention provides a method for determining a posture of a user seated in a chair. The chair includes a seat, a backrest, and a base. The method includes detecting a physical force imparted to the chair by the user using a plurality of sensors coupled to the chair, and generating an output signal indicative of the physical force using each of the plurality of sensors. The method also includes receiving the output signals generated by the plurality of sensors using a processor coupled to the plurality of sensors, and determining, by the processor, a current posture of the user seated in the chair based on at least one of the output signals received by the processor.

Other aspects of the invention will become apparent by consideration of the detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 illustrates an example office productivity structure (OPS).

FIG2 illustrates an example analysis system.

FIG3 illustrates an example OPS environment.

FIG. 4 illustrates an example system for monitoring and analyzing occupancy signatures.

5A-5C illustrate example interfaces for individualizing time utilization reports.

FIG6 illustrates an example mobile device.

FIG. 7 illustrates a mapping for determining the usage and warranty status of a chair.

FIG8 shows a mapping for determining rotational usage and target sales of a chair.

FIG. 9 shows a mapping used to determine chair adjustments for an operator.

FIG. 10 shows a map used for operator focus/distraction analysis.

FIG11 illustrates example enterprise logic.

FIG12 illustrates example maintenance logic.

FIG13 illustrates example seizure logic.

FIG14 illustrates example career logic.

Figure 15 shows the gesture logic.

FIG16 shows a second example OPS.

FIG17 illustrates example operator feedback logic.

DETAILED DESCRIPTION

Before explaining any embodiments of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The invention is capable of other embodiments and of being practiced or carried out in various ways.

Described below is a context-aware architecture that can be integrated with an office productivity structure (OPS), such as an office chair, executive chair, other office chair, table, workstation, desk, shelving, other furniture, room lighting, office lighting, climate control system, storage device computer docking station, computer internet portal, telephone switchboard, wearable gesture sensors, and/or other OPS. Sensors within the OPS can recognize features such as gestures, biometric data, circadian timing, gesture state, location information, noise level, temperature, orientation information, facial expressions, identification codes, data, gestures, postures, or gesture duration, and/or other characteristics. The sensors can also provide data to a local or remote analysis system that performs the recognition. The OPS can also communicate with an analysis system (such as an enterprise database, a local database, a server, a network system, a cloud analysis system, and/or other processing system) to facilitate the generation of a representative productivity model for one or more operators utilizing the OPS (as just one example). The productivity model may be integrated with operator data and applications, such as email, instant messaging, calendar, and/or location applications or data, to determine context for the productivity model and provide context-informed feedback to the operator.

Based on the productivity model, the analysis system can determine productivity information that may be useful to the modeled operator. For example, the productivity information may include useful tips such as break timing, mapping of performance to time of day, suggested meeting locations and times, target states, posture adjustments, instructions for an OPS design or configuration that is more suitable for the operator's usage profile, and/or other tips. The information may be presented to the operator via push notifications, data visualizations, and/or other data displays to mobile devices, terminals, workstations, and/or other operator devices. The analysis system may also be able to learn through operator feedback. For example, some observations may be acted upon, while others may be ignored. The application may customize its observations based on the characteristics of those observations that were acted upon to increase the chances that the user will respond to the observations.

Additionally or alternatively, productivity information can be used to support enterprise application interactions, such as loading programs upon arrival, limiting electronic distractions (e.g., calls, emails, or other during high productivity periods), loading to-do lists, executing time-logging applications, notifying safety or security systems of occupancy, and/or other enterprise application integrations.

In various implementations, productivity models can include data regarding informal and/or official hierarchical dynamics within an organization. For example, by monitoring meeting locations (e.g., the tendency of one employee to travel to another's office for meetings), the system can determine the status relationships between employees within the company. For example, for longer scheduled meetings, lower-level employees may often travel to the office of a higher-level employee. Using meeting data captured from chair occupancy, calendar data, and/or data sources, the analysis system can determine the hierarchical status within the enterprise and/or other organization. This hierarchical status can be integrated into the productivity model.

The analysis system can also provide OPS maintenance monitoring. The data collected by the OPS can be used to determine the current condition of the OPS. For example, posture and weight distribution data from a chair may indicate that a spring or other biasing component has worn out. In an example, due to worn springs, the chair may recline beyond a certain tolerance range that will be allowed. This condition can be diagnosed from the data, and the analysis system can issue a notification that the chair should be replaced or serviced. Other maintenance diagnostics for the OPS can be made using the collected data.

FIG1 illustrates an example OPS 100. The example OPS 100 is an office chair. However, other OPS types may be used in conjunction with the architecture and techniques described below. Many of the structural elements and functionalities (e.g., actuators) described below for the OPS 100 are optional but may be included to support the sensing and feedback capabilities described further below.

The OPS 100 may include a power source 102 and one or more electrically powered devices 110 coupled to the power source. The power source 102 may include a battery pack, a fuel cell, a capacitor and/or capacitor bank, a photovoltaic cell, and/or other power source. The power source 102 may be attached to the mobile portion 101 of the OPS, wirelessly transmitting power from a station 103, or connected to the mobile portion 101 via a wired tether. Where a wire or cable is used, such a tether may be removed from view and from potential foot traffic, for example, by being hidden beneath carpet, walls, wainscoting, conduit, wire management equipment, or other concealment. The station 103 may include a charging station for the mobile portion 101. The mobile portion may be moved to the charging station using a propulsion system when not in use. In some cases, a charging arm or other extender may be folded away from the mobile portion 101 or the charging station to charge the mobile portion when not in use.

The electrically powered devices may include one or more actuators 112 for adjusting the configuration and positioning of the OPS within a room or location, processing circuitry 114 for supporting the execution of applications on the OPS, a display 116 for presenting information to an operator, a human interface device 118, a networking interface 120, and/or other electrically powered devices. The actuators 112 may include propulsion devices, electric devices, electrical devices, chemical devices, hydraulic devices, pneumatic devices, electrochemical sources, and/or other mechanical energy sources. For example, motors, gears, wheels, engines, or other propulsion systems may be used.

In a seated OPS such as the example OPS 100, the OPS may include seat structural features, such as a backrest 132, which is directly or indirectly coupled to a seat 134 and/or base 136. In some cases, the actuator 112 may be capable of performing automatic adjustments of the seat 134, backrest 132, base 136, or other portions of the example OPS 100. Additionally, automatic adjustment mechanisms may be implemented to adjust other structural features, including seat depth, armrest height, lumbar pressure, lumbar position, sacral support, spinal support, head support, chest support, foot support, leg support, calf support, and/or other seat supports. For example, a seated OPS may include adjustment features to achieve a full range of positions from a seated to a reclined to a standing position.

Actuator 112 can be coupled to processing circuitry 114. Processing circuitry 114 can be further coupled to sensors 140 within OPS 100. Sensors 140 can include accelerometers 142, load sensors 144, temperature sensors 146, and/or other sensors. Sensors 140 can be grouped into different locations within OPS 100. For example, backrest sensor 141 can be used to determine positional parameters of backrest 132, such as, for example, the tilt of the seat back relative to the base, back weight distribution, and recline rate. Sensors can include accelerometers, strain gauges, load cell sensors, pressure sensors, and/or other sensors. Seat sensor 145 can determine occupancy location within the seat using positional parameters of seat 134, such as, for example, seat pan weight distribution, seat pan tilt relative to a horizontal plane (e.g., the floor), seat pan height relative to the floor, and/or other metrics. Seat sensor 145 can include accelerometers, strain gauges, pressure sensors, load cell sensors, laser range sensors, other range sensors, and/or other sensors. Furthermore, the backrest sensor 141 and the seat sensor 145 can collaborate to determine the seat's occupancy status. The base sensor 149 can also determine positional parameters of the base 136, such as rotation, travel distance, impact force, orientation relative to a desk or other object, distance from other objects, weight differences on the feet, and/or other physical conditions. The base sensor 149 can be used to measure the chair's movement and orientation, as well as the foot's orientation. The base sensor 149 may include a magnetometer, a gyroscope, an optical orientation tracker, a dead reckoning calculator, an accelerometer, an ultrasound system, an odometry system, an optical camera, and/or other sensors. The armrest sensor 143 can measure forces on the armrests and/or the orientation of force vectors on the armrests to determine arm posture. Furthermore, differences between armrests can be used to determine lateral inertia and/or other posture conditions. In the illustrated embodiment, the seated OPS 100 includes a first armrest and a second armrest. A first armrest sensor coupled to the first armrest detects a first force acting on the first armrest. A second armrest sensor coupled to the second armrest detects a second force acting on the second armrest. Detecting the first force and the second force may include detecting the magnitude and direction associated with each force. Furthermore, the difference between the first force and the second force may be used to determine the aforementioned difference. A specific posture or posture condition may then be detected based on the difference (i.e., the difference) between the first armrest and the second armrest. The armrest sensor 143 may include a strain gauge, a pressure sensor, and/or other sensors. Additionally or alternatively, an off-OPS sensor 147 may be used to monitor the OPS 100 from a distance. The off-OPS sensor 147 may include a rangefinder system, a camera, a motion sensor, a gesture recognition system (e.g., Xbox™, Kinect™, and/or other gesture recognition systems), and/or other sensors.

The OPS 100 may include any number of a variety of sensors 118 , and several examples are given in Table 1 .

Sensor orientation Sensor Type backrest Accelerometers, strain gauges, pressure sensors, load cell sensors, laser ranging sensors, other ranging sensors Sitting Accelerometers, strain gauges, pressure sensors, load cell sensors, laser ranging sensors, other ranging sensors base Magnetometers, gyroscopes, optical orientation trackers, dead reckoning calculators, accelerometers, ultrasonic systems, ranging systems, optical cameras armrest Strain gauges, pressure sensors Stay away from OPS Cameras, motion sensors, gesture recognition systems

Table 1: Sensor types and locations.

As explained above, at least some of the sensors 140 detect physical forces (e.g., seat pan weight distribution, backrest weight distribution, armrest force vectors, etc.) imparted by the user to the seated OPS 100. Each sensor 140 then generates an output signal indicative of the physical forces. The sensors 140 can detect rotational movement, reclining, lateral positioning of the seated individual, the direction the seat is pointing (north, south, east, west, and/or other intermediate directions), noise levels, temperature levels, and/or other conditions. In particular, the output signals from the sensors 140, along with the orientation parameters determined for the chair, are used to determine the current posture of the user seated in the chair, as discussed above.

In various implementations, the OPS may not necessarily include one or more of the above features. For example, the OPS may include sensors and communication capabilities, but may not include actuators and/or local analytical processing. The sensors 140 may additionally or alternatively be communicatively coupled to an analysis system, such that the OPS can collect sensor data and transmit the collected data to the analysis system, e.g., a cloud-based analysis system. The data and/or generated observations may be sent from the analysis system back to an operator device, e.g., a smartphone, computer, OPS display, and/or other operator device.

Processing circuitry 114 can execute instructions that adjust OPS 100 until certain sensor criteria are met. For example, a threshold tolerance load on seat 134 can be permitted for a particular operator, as detected by load sensor 144 in seat 134. Processing circuitry can cause actuator 112 to adjust the OPS structural configuration to shift weight between seat 134 and the floor. Alternatively or additionally, accelerometers can be used to detect orientation criteria, and positioning criteria can be determined using ranging technology, satellite navigation (e.g., GPS, GLONASS, Galileo, and/or other satellite navigation), or other positioning technologies. However, the adjustment instructions, adjustment criteria, and sensor usage can vary widely. Furthermore, processing circuitry can receive adjustment instructions or instructions for adjustment routines from the analysis system via a network interface. The instructions and/or instructions can be associated with applications running on the analysis system, such as maintenance applications, enterprise applications, and/or productivity assistance applications.

Processing circuitry 114 may include one or more processors 152 (e.g., a general-purpose processor, a central processing unit (CPU), a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), an audio processor, a field-programmable gate array (FPGA), a microcontroller, a multi-core processor, and/or other integrated processing circuitry). Processing circuitry 114 may further include memory 154. Memory 154 stores, for example, control instructions 156, which processor 152 executes to implement desired functionality for OPS 100. For example, functionality may include OPS configuration adjustments, maintenance functions, enterprise application interaction, and/or other functions. Control parameters 158 provide and specify configuration and operating options for control instructions 156. Control parameters 158 may include adjustment configuration data, enterprise application data, sensor data, actuator position data, and/or other control parameters.

OPS 100 may also include a network interface 120, which may support wireless (e.g., Bluetooth, Bluetooth Low Energy (BLE), ZigBee, Wi-Fi, WLAN, cellular (4G, LTE/Advanced)) and/or wired, Ethernet, Gigabit Ethernet, optical networking protocols. Network interface 120 may enable communication with analysis system 200, other OPSs, and/or other devices.

The OPS 100 can include different positioning and adjustment configurations for different operators. For example, two operators using the same OPS can have different associated settings. In some cases, the OPS can identify different operators based on features or other identifiers, as described below. In some cases, a single operator can have multiple OPS configurations applied in different situations, which can also be identified by features. For example, during periods of habitual high productivity (e.g., during a portion of an employee's primary workday on a given day), a relaxed position can be used to promote operator comfort, but during periods of habitual sleepiness, an upright or more standing position can be used. Thus, increasingly active postures can be used to maintain high output for the operator. The control parameters 158 can store one or more configuration settings for an operator.

Turning now to FIG. 16 , a second example OPS 1600 is shown. Example OPS 1600 is a table. For example, OPS 1600 may be implemented as a table in a conference room or a desk in an office. OPS 1600 may include a power supply 1602, processing circuitry 1614, a display 1616, a human interface device 1618, a network interface 1620, an actuator 1612, a sensor 1640, or other components.

The second example OPS 1600 may utilize a power supply 1602, processing circuitry 1614, network interface 1620, human interface device 1618, and display 1616 similar to those presented in the example OPS 100. However, the capabilities of the components in the second example OPS 1600 may differ from those of the OPS 100.

Processing circuitry 1614 may include one or more processors 1652, such as general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), application-specific integrated circuits (ASICs), audio processors, field-programmable gate arrays (FPGAs), microcontrollers, multi-core processors, and/or other integrated processing circuits. Processing circuitry 1614 may further include memory 1654. Memory 1654 stores, for example, control instructions 1656 that processor 1652 executes to implement desired functionality for OPS 1600. For example, functionality may include OPS configuration adjustments, maintenance functions, enterprise application interaction, and/or other functions. Control parameters 1658 provide and specify configuration and operational options for control instructions 1656. Control parameters 1658 may include adjustment configuration data, enterprise application data, sensor data, actuator position data, and/or other control parameters.

Actuators 1612 and sensors 1640 can be customized based on the application. For example, a table can include actuators to support height adjustment in response to detected people or features. Sensors 1640 can include any of the sensors discussed above with respect to OPS 100. Furthermore, sensors 1640 can coordinate with actuators 1612 to perform height adjustments based on a person's size, posture, or orientation. OPS 1600 can respond to multiple detected people. For example, OPS 1600 can perform height adjustments to accommodate the average height of a group. Alternatively or additionally, OPS 1600 can perform height adjustments to accommodate extremes within a group. For example, height adjustments can account for the shortest detected member of a group. Enterprise interaction can also be enabled on OPS 1600. For example, OPS 1600 can be reconfigured to accommodate an upcoming meeting, actuators 1612 can detach or connect table subunits, height adjustments can be made based on expected attendees, and messages requesting additional seats can be sent by OPS 1600.

FIG2 illustrates an example analysis system 200. Analysis system 200 may include system circuitry 214 to support the execution of the functionality described above. System circuitry 214 may include a processor 216 (e.g., a graphics processing unit, a general-purpose processor, an audio processor, and/or other processing device), memory 220, and/or other circuitry. The processor may include an evaluation processor 422 and a contextualization processor 424, described below.

Memory 220 can store sensor data from the OPS, parameters used for assessment, human resource data identifying OPS operators and their occupations or roles, application parameters for enterprise application integration, and/or other data. For example, memory 220 can store operator characteristics 261, behavioral characteristics 262, occupancy characteristics 263, sensor data 264, application parameters 265, maintenance data 266, assessment parameters 267, OPS adjustment data 268, orientation data 269 (e.g., for a user's previously detected posture), and/or other data used to support OPS interaction and data processing. This data can be periodically stored in memory 220 to keep it current.

Analysis system 200 may be implemented in a cloud environment and may be distributed across one or more computing platforms and/or virtual machines. In some cases, the analysis system may be dynamically instantiated such that specific hardware units may be interchangeable between instances.

Analysis system 200 may also include a communication interface 212, which may support wireless (e.g., Bluetooth, Wi-Fi, WLAN, cellular (4G, LTE/A)) and/or wired, Ethernet, Gigabit Ethernet, and optical networking protocols. Communication interface 212 may enable communication with the OPS and between computing platforms hosting the various computing components of analysis system 200. Analysis system 200 may include a power supply 234 and various input interfaces 228. Analysis system 200 may also include a user interface 218, which may include a human interface device and/or a graphical user interface (GUI). The user interface may include a display 240 for presenting video, images, and/or other visual information to an operator. In various implementations, the GUI may support portable access, such as via a web-based GUI. Functional aspects of analysis system 200 are described below in conjunction with other figures.

FIG3 illustrates an example data communication environment 300 . The analysis system 200 resides within the data communication environment 300 . The contextualization processor 424 and the evaluation processor 422 described below may be part of the algorithm engine circuitry 302 and the application framework circuitry 304 . The communication interface 212 may communicate with OPS sensors to collect various sensor data 320 . For example, seating data (e.g., gesture data, posture data, spatial data, OPS model data, and/or other seating data), surface data (e.g., vibration data, pressure data, spatial data, and/or other surface data), building data (e.g., auditory data, light usage data, power consumption data, security system data, heating/cooling data, temperature data, motion sensor data, and/or other lighting/power data), device data (e.g., personal computer (PC) application data, smartphone data, location data, calendar data, enterprise application client data, fitness monitoring data (Nike™, Jawbone™, Fitbit™, and/or health devices), wearable posture detection device data (e.g., LumoBack and/or other wearable devices), and/or other data). The analytics system 200 may provide feedback 330 to the OPS via the new configuration (eg, seating settings, other OPS settings, lighting status, heating/cooling status, other spontaneous building feedback, enterprise application server data, and/or other feedback).

Interface 212 can also provide data output to various enterprise application management systems. For example, the analytics system 200 can send individual performance feedback 352 to individual users via various channels, such as social media, enterprise application server data, and human channels (e.g., encouraging colleagues to provide encouragement or other human interaction to operators in the same workgroup). In another example, the analytics system can send human resources information 354 (e.g., health and wellness information, social interaction data, and/or other human resources data). Human resources data can be used to coordinate with external vendors (such as healthcare providers, insurance providers, and/or other external service providers). In some cases, the data can be anonymized to protect individual privacy, while allowing for enterprise-level integration with external providers. The analytics system 200 can be integrated with building controls for site/asset management 356. Additionally or alternatively, product providers can access product data 358 to facilitate research and development, product management, and warranty management. In some cases, third parties may be interested in OPS data (e.g., manufacturing date/location, serial number, usage data), potentially presenting opportunities for data resale 370. This opportunity can be attractive to organizations requiring customized solutions and potentially offering discounts on overall monitoring system deployment costs. Different levels of OPS data can be made available to third parties, depending on their application, their subscription level, the operator's data privacy concerns, the data collection organization's data sharing priorities, or other business considerations. In some cases, sensor data can be filtered and sent to third parties. Additionally or alternatively, the data can be processed, and actionable insights can be delivered to the third party.

FIG17 illustrates example operator feedback logic 1700. The feedback logic may collect feedback 1702 from the operator via OPS sensors 1740, enterprise data 1714, application integration 1716, or other channels. For example, a chair-based OPS may receive a stress profile from the chair's sensors. The operator may shift their weight in response to a notification sent to a display or other action taken by the system. For example, the operator feedback logic 1700 may generate a command message that causes the chair actuator to change the chair's orientation, which may result in a change in the stress profile. Additionally or alternatively, the operator feedback logic 1700 may generate a push notification for the operator's mobile device (e.g., and send the push notification as a display on the operator's mobile device). The push notification may indicate a target posture to the user and request the operator to shift/change posture. After the shift, the system may interpret the generated stress profile as feedback from the operator (i.e., the system may determine whether the user moved toward the target posture, away from the target posture, or did not perform the movement). In another embodiment, the operator may provide quick feedback via enterprise software or other applications. For example, the operator can log in to the enterprise portal and provide feedback through the tools available on the portal. Additionally or alternatively, the operator can provide feedback through an enterprise application running on the operator's device with or without a quick login.

In some cases, the enterprise login portal can be integrated with other online portals and resources. For example, enterprise resources can be accessed through social media, employee management websites, or other online resources.

Operator feedback logic 1700 can respond to the feedback with an action 1704. The action can be directed to an actuator or display associated with any of the feedback input channels. The action does not necessarily need to be sent back through the specific channel(s) from which the feedback originates that initiated the response.

In some implementations, the OPS may include one or more features of an ergonomic office chair. One example is sold by Herman Miller of Zeeland, Michigan under the trademark AERON®. Features of the AERON® chair, which may be incorporated into a chair, include a seat and back having a form-fitting, breathable woven mesh; an integral carrier member for securing the periphery of the woven mesh to the chair frame; a mechanism for controlling the range of tilt and resisting tilt; and a linkage assembly by which the seat and back can pivot about a hip pivot point while simultaneously tilting back. However, other chair and OPS designs may be used, which may increase or decrease adjustment options. Another example may be sold by Herman Miller, also of Zeeland, Michigan, under the trademark PostureFit®.

The OPS may be equipped with an integrated or additional sensor/communication unit to provide processing circuitry, sensors, and/or communication interfaces. These units may cooperate in the monitoring and feature recognition features described herein.

In some implementations, sensor devices can be added to existing OPS to facilitate monitoring features. In an example system, a seating sensor can be 2 in x 1 in x 3/4 in and have sensors capable of measuring movement, recline, time, temperature vibration, pressure, and/or other conditions. The sensor device can be battery-powered. The sensor device can communicate with a terminal or other OPS via Bluetooth, BLE, and/or other communication protocols. The terminal or other OPS can forward the collected data to the analysis system 200 for analysis. In some cases, the sensor device can establish a direct communication link to the data processing device via Bluetooth or other communication protocols.

In some cases, the monitoring system can be used to determine informal and/or formal group dynamics (e.g., hierarchical organization, social groupings, and influence within an organization). As part of determining group dynamics, an occupancy or space usage study can be performed. In some implementations, an operator can provide a list of spaces to be monitored for the study, such as a floor plan. However, ranging and navigation sensors on the OPS can be used to determine the spatial layout. These spaces are then stored in a database table in a database that can be assigned identifiers and associated with operators and/or other individuals. For example, an office can be associated with one or more occupants and given an identifier. The OPS can include a serial number or other identifier. The location of the OPS within the study space can also be determined.

In various implementations, OPS connectivity can be managed across the organization. For example, an OPS can act as a local hub for connectivity with other satellite OPSs. For example, a workstation unit can access wide area network (WAN) connectivity. A workstation can communicate with other OPSs via a second communication technology. For example, a workstation can use Wi-Fi, Bluetooth, other wireless connectivity, and/or a wired connection to communicate with other OPSs. In some cases, OPSs may have different sensing and processing capabilities. Satellite OPSs can collect data via onboard sensors and send the captured data to a central OPS for processing and/or application integration. The central OPS can further interact with analysis systems via WAN or other network connectivity. In some cases, an OPS does not necessarily need to exchange data directly with other OPSs. For example, an OPS can utilize onboard data processing, onboard sensing, and onboard network connectivity to maintain a communication link to an analysis system.

OPS data can be logically associated with the OPS sensors that collected the data, for example, using database keys and fields. However, for some OPS configurations, data association may occur based on application preferences. For example, ranging measurements from an office can be associated with the OPS located within that office, even if the scan was performed by another OPS or a measurement device not connected to the OPS. This logical association can be maintained at the analysis system. Additionally or alternatively, an indicator for data association can be generated by the OPS and sent to the processing system along with the data (e.g., as metadata or other data). Data can be sent to the analysis system via transmission processes and systems, such as Hypertext Transfer Protocol (HTTP) operations (e.g., post, get, put, delete, and/or other operations), sending XML data to web services, sending messages using socket communication, cloud storage operations on Cassandra or Hadoop systems, and/or other processes. Some systems implement security layers for transmission on various links between data collected at OPS sensors. For example, Secure Sockets Layer (SSL), Secure File Transfer Protocol (SFTP), virtual private network tunnels, and/or other encrypted transmission protocols.

FIG4 illustrates an example system 400 for monitoring and analyzing occupancy characteristics. The example system determines occupancy within one or more physical spaces. A physical space may include physical elements, such as seats or work surfaces, or other OPS. Example system 400 may be implemented on one or more analysis systems 200, as described above. The system includes a receiver 420, an evaluation processor 422, and a contextualization processor 424. Receiver 420 is operable to receive usage information, such as an estimated or probable utilization state. A probable utilization state may be determined for a physical element (e.g., a seat or work surface) within a first time period (e.g., a minute, hour, day, or other time period). This determination may be based on the amount of movement of the physical element during discrete portions of the first time period (e.g., 15-second intervals or other intervals). The probable utilization state indicates the likelihood that at least one occupant is utilizing the physical element (e.g., sitting on a seat or working at/on a work surface), and therefore occupying at least a portion of the first physical space during the first time period.

The system 400 further includes an evaluation processor 422 and a contextualization processor 424. The evaluation processor 422 is coupled to the receiver and is operable to evaluate at least a portion of the received portion of the determined possible utilization states to determine a number of occupants occupying at least a portion of the physical space. For example, the evaluation processor 422 can determine whether an occupant is likely to have caused movement based on the determined associated possible utilization states. Additionally or alternatively, the evaluation processor 422 can combine received data from multiple OPSs 100 and/or receive additional inputs, such as the status of lights in the room, historical security badge reports, motion detector reports, or other data that can be used to confirm that the possible utilization state is in fact indicative of an occupant and is not a false positive.

The contextualization processor 424 can be coupled to the evaluation processor 422 and compare the determined number of occupants with data from an expected occupancy model, human resource data, previous measurements, or other data to facilitate managing the occupancy of the first physical space. For example, the contextualization processor 424 can determine the occupancy of at least a portion of the first physical space at a particular time based at least on the received determined possible utilization states and verify the utilization of the portion of the first physical space at the particular time. In another example, the contextualization processor 424 can determine the occupancy of at least a portion of the first physical space at multiple specific times based at least on the received determined possible utilization states and verify a change in the occupancy of the portion of the first physical space over a period of time including the multiple specific times. In another example, the contextualization processor 424 can associate the occupancy of at least a portion of the first physical space with at least one event based at least on the received determined possible utilization states. In another example, the contextualization processor 424 can calculate an index value representing at least the received portion of the multiple possible utilization states.

In another example, the contextualization processor 424 may associate occupancy of at least a portion of the first physical space with at least one attribute thereof based at least on the received determined possible utilization state, wherein the attribute may include location, environmental conditions (e.g., temperature, vibration, relative humidity, concentration of allergens or volatile organic compounds, atmospheric pressure, radiation, electromagnetic fields, etc.), available amenities, decor, electricity consumption, or a combination thereof. In another example, the contextualization processor 424 may aggregate the received determined possible utilization state with previously received determined possible utilization state and contextualize at least the received determined possible utilization state based on the aggregation. The previously collected determined possible utilization state may have been received for a second physical space different from the first physical space, or alternatively, the previously received determined possible utilization state may have been received for a second physical space operated by an entity different from the entity associated with the first physical space.

Once occupancy data is collected, the contextualization processor 424 can monitor the flow of operators from location to location. The flow of operators can be used to determine when and where meetings occur and who attends the meetings. The pattern of meetings can be used to determine informal and/or formal hierarchical relationships within the organization. For example, regular meetings between operators in neutral locations (e.g., break rooms, water coolers, foyers, and/or other neutral locations) may indicate an informal "water cooler" relationship. In another example, regular meetings at non-neutral locations where an operator moves from his/her normal physical space to the physical space of another may indicate a formal organizational relationship.

In some implementations, seat sensors can collect proximity, spatial, temporal, motion, acceleration, and posture data to facilitate the identification of features that may represent certain mental or postural states of the operator (i.e., current sitting posture). The seat sensors can send this data to the evaluation processor 422 of the analysis system 200 for feature identification. The contextualization processor 424 of the analysis system 200 can identify, determine, track, correlate, and/or prioritize these and desired states. In other words, the analysis system 200 can store previous information, such as signals from the seat sensors, the operator's mental state, and/or different postures specific to the operator. In response to the analysis, the contextualization processor 424 can send actionable observations to the operator. These observations can be used to fill experience blind spots (e.g., alerting the operator to habits that the operator may be unaware of or only slightly aware of). Actionable observations can be provided via one or more of the other interface channels described above with respect to the OPS environment 300.

Features can include nearly any collection of recurring observable phenomena that can be used to identify a specific individual, group of individuals, behavior, mental state, and/or other attributes. For example, recognizable movement patterns, radio frequency identification (RFID) tags, doors when walking, facial images, fingerprints, gestures, daily routines or other habits, biometric data, location data, smartphone or device data, occupational descriptions, and/or other identifiable data. For example, for gesture-type or posture-type features, Seat OPS can detect a 20° chair rotation with a 5° increase in backward tilt relative to the previous state. When these two detections occur within 3 seconds, this may indicate an interruption or task shift. This can be correlated with calendar data, location data, and/or other data to determine high-resolution work efficiency analysis. However, other features can be correlated and analyzed.

A task transition can occur when an operator switches from performing a first task to performing a second task, or from a first state to a second state. For example, a task transition can occur when an operator switches from typing to talking on the phone, and then back again from talking on the phone to a contemplative state. In some cases, a target number of task transitions can be selected for an operator for a given period. However, the target number of transitions can be determined based on time of day, operator preferences, operator performance history, task transition history, occupational function, season, and/or other factors.

For individuals, the system can guide actionable observations to focus on an operator-centric model. Thus, in the "My World" environment, observations can be targeted to individual operators. This can help avoid adding additional distractions to an operator's day through generalized feedback that may not necessarily apply to the individual operator. Furthermore, operators may be able to access OPS-specific information to access observations, data, and/or other information related to OPS for their own operations. Operators can receive input on improving rest timing based on health and/or productivity data. Observations can also help users reduce their own sedentary behavior and increase their use of healthy postures. For example, sitting upright for too long may be an unhealthy posture. In this example, the analysis system 200 can determine the time period a user maintains a current posture (e.g., an upright posture) and, if that time period exceeds a time threshold (i.e., an observation to help the user increase their use of healthy postures), generate a notification to the user to change their posture. The analysis system can track movements and identify periods of distraction from a group of many movements within a short time period (e.g., seconds and/or minutes, or other time period). Observation can help the operator become aware of periods of distraction and the time needed to regain focus.

The system can experiment with various outputs to explore improvements to various conditions. For example, a chair-type OPS can change the orientation of a chair to determine which orientations produce the desired postural outcome for the occupant. The OPS can implement random changes. Additionally or alternatively, the OPS can implement a parameter search algorithm to construct a strategy for parameter changes. In some cases, a structured search can identify a preferred state after fewer changes when compared to a random variation strategy. Iterations of experimentation and subsequent feedback create a feedback loop. The feedback loop can be managed by operator feedback logic 1700.

The system can also measure time away from the desk versus time at the desk to determine the ratio of "heads-down" type work to "team" type work performed in a given day. Thus, the system can help operators reduce negative distractions (e.g., productivity loss from internet/email use or other negative distractions) and increase positive distractions (e.g., team interactions, healthy breaks, posture-improving exercise breaks, and/or other positive distractions). In addition, operators can choose to share non-anonymous data with health providers to achieve discounted services and/or insurance premiums. Wearable OPS and wearable notification devices can assist system operations during operator mobility situations.

The system can determine actionable observations based on sensor and application data. For example, an observation can include identifying a time period in an operator's schedule where there is a downtime. The system can send a notification to the operator to encourage them to take a break during the downtime rather than waiting for a later time. Additionally or alternatively, the system may issue warnings about upcoming meetings and, for example, use characteristics and occupancy data to help locate individuals attending the meeting. The system can also remind operators not to take a break when a meeting is approaching. For example, the system can identify characteristics that indicate the operator may be planning an upcoming break (e.g., chair movement, habitual messages, clearing a to-do list in an app, and/or other activity). In response, the system can encourage the operator to postpone the break to a more appropriate time. The content of the meeting can also influence the timing and content of breaks. For example, the system might recommend a walking break before a meeting based on a phone call, as the operator may not necessarily be walking to the meeting. The system can also coordinate information received from multiple OPSs. For example, the system can receive input from a conference table OPS if the meeting is a sit-down meeting. Thus, even though the operator may be away from their desk and chair (OPS), the system may be able to determine that the time during the meeting is still sedentary time for the operator. In some cases, enterprise application data may provide indicators of the meeting mode. For example, a conference call or phone meeting may be indicated within the meeting details. Similarly, the inclusion of a specific room or location may indicate that the operator will be traveling to the meeting (e.g., in the office or at another location).

Actionable items can be determined by exchanging data with the application. For example, the analysis system can read a calendar or task list from Outlook, or read the type of template presentation from a PowerPoint document to determine the operator's current task.

In another example scenario, the system might send a notification encouraging activity after lunch, rather than after a sedentary period. In another scenario, the system might also vary the duration of recommended breaks based on previous activity levels. For example, the system might encourage longer breaks after long periods of sedentary activity. Alternatively, the system might encourage sedentary breaks after long periods of physical activity or stress. Furthermore, the system might encourage formal breaks during periods of low productivity or distraction, for example by monitoring app usage or operator movement. During periods of high productivity (e.g., based on app usage and/or other data), break reminders might be suppressed to avoid pushing the operator "out of their groove."

The system can also use behavioral data to promote more effective operator interaction with other operators. For example, feedback on the vibration function of the operator's mobile device can be used to alert the operator that other operators have lost interest in the demonstration. This warning can prompt the operator to change the topic or otherwise wake up the other operators.

To encourage overall health, the system may send notifications to stand up and/or sit down after a certain period of time in either orientation.

Additionally or alternatively, behavioral data can be correlated with calendar data or other enterprise data. For example, the system can determine an operator's anxiety level based on a mix of behavioral observations and upcoming calendar events that may be anxiety-provoking (e.g., a public speaking appointment, a work performance review, a client meeting, a meeting with a supervisor, or other anxiety-inducing events). In some cases, the system can monitor operator behavior around common anxiety-inducing events (e.g., events identified by research or reported by operators). Behavioral patterns around these known or common anxiety-inducing events can be compared with behavioral patterns around other events to identify additional anxiety-inducing events.

In some implementations, activity trackers (e.g., Nike(TM), Fitbit(TM), Apple(TM), or other activity trackers) can be integrated with the system. For example, OPS can establish a link with the activity tracker and access information collected by the tracker. Additionally or alternatively, the operator of the tracker can set the tracker to forward information to the system via another tracker uplink. Tracker data can be used to develop a more comprehensive view of user activity. For example, an activity tracker can track mobility-type fitness, but may have an incomplete picture of the operator's work posture and work activity routine. Integrating activity tracker data with OPS sensor data can provide insights into both health at work and health in other areas.

The system can also analyze the floor plan to determine whether it meets one or more criteria for space usage by an operator or group. For example, space usage goals can include 'per unit' productivity, aesthetics, ergonomics, proximity between designated individuals, accessibility, or other measures. The system can generate command messages for OPS with movement capabilities (e.g., desks, chairs, tables, lighting, or other OPS) to reconfigure the floor plan to meet the floor plan goals.

The system can report the results of changes to floor plans or other space usage plans to management systems or personnel. Management systems or personnel can respond to the reports to remind space usage priorities.

The initial configuration and goals may be based on prior research, industry practices, historical usage patterns, or other known data prior to setup. The initial conditions and data may be changed as current feedback from the system is processed and assimilated.

Figures 5A-C illustrate an example interface 500 for personalized time utilization reporting. Example interface 500 can be generated and displayed by a smartphone application, a console application on a laptop or desktop computer, an application executed on a wearable device, and/or other client computing environments. As shown in Figure 5, at the first level 510, general information regarding performance (seat time 512, away time 513) and/or goal progress 514 can be displayed. The display can use a layout with data visualization occupying a large portion of the screen to facilitate data ingestion.

As shown in FIG5B , at the second level 520, which can be accessed from the general menu and/or detailed options at the first level, operators can access long-term reports by daily 522, weekly 524, or monthly trends (i.e., by predetermined time periods). The reports can put daily performance into context and allow the identification of cyclical trends, for example, on a daily, weekly, or monthly basis. The second level can also provide interactive questionnaires 526 for determining the operator's own productivity assessment. These questionnaires can be sent to the analysis system 200 to adjust the productivity model. For example, a generalized productivity model may assume that the desired productivity can be achieved by first balancing time spent on heads-down work with time spent with the team. However, an operator's individual productivity balance may differ from the generalized model. The questionnaires can help the analysis system 200 assess deviations from the generalized model for an individual operator.

As shown in FIG5C , the third layer 530, accessible from the general menu and/or detailed options on the first or second layers, can display a report containing detailed statistical analysis of the time usage categories shown on the first layer 510. For example, sitting time 512 can be broken down into reclining time 532, upright time 534, and stationary time 536. In other words, the analysis system breaks down time spent sitting into time spent sitting in different posture categories (reclining time 532, upright time 534, and stationary time 536). Each posture category can include a set of more than one stored posture. For example, similar to upright time 534 and stationary time 536, time spent in the reclining category does not necessarily indicate time spent in any particular reclining posture. Instead, multiple stored postures are grouped together to form a posture category. The graph can display performance metrics such as activity level 538, total sitting time 540, and focus level 542. These metrics can help operators identify areas for improvement and areas of strength.

The example interface 500 can show a report of activity postures and environmental sensor data for a predetermined time period (e.g., a day, a week, a month) as described above. Data displays in the form of sensor/report data versus time can also be used. In the illustrated embodiment, the data is displayed in a pie chart, but other types of graphs such as, for example, bar charts, scatter plots, etc. can also be used in addition or alternatively. In the illustrated embodiment, the interface 500 displays the length of time the user spent in each stored posture (e.g., leaning back 532, standing upright 534, and stationary 536). The relationship between peaks and valleys and time can be analyzed by the system to determine actionable observations. The interface 500 can be used to push the observations to the operator.

The analysis system 200 can generate sitting time details (e.g., different postures of a user) by analyzing posture, movement, and/or rotation data collected from chair sensors. The collected data can be correlated and/or cross-referenced with activity, operator profile (e.g., age, gender, height, weight, and/or other profiled data), location, application usage, calendar, and/or other data collected from sources other than chair sensors. For healthy, productive output, reminders and/or activity goals can be set to help balance activity and focus. For example, a goal can be set to stand up at certain times. To this end, the analysis system 200 can also include time spent standing in the report shown in Figures 5A-C. Goals can also be related to posture, rest time, rest content, total sitting time, number of transfer movements, and/or standing time.

The analysis system can generate away time details by analyzing calendar data, seat occupancy data, people tracking data, location data, and seat time data away from the primary location. The away data can be compared with the seat time data at the primary location. Goals can be set for specific amounts of away time or desk time. In some cases, the health nature of the balance between desk and away time may influence goal setting. For example, the analysis system 200 can recommend a balance that meets company health guidelines and meets productivity goals for specific operators.

In some implementations, reports can be sent to the operator's email, for example, periodically. For example, they can be sent daily, weekly, monthly, and/or when the operator requests.

The analysis system can send notifications based on decisions made on a lookup table. For example, the lookup table can include entries organized based on enterprise software, operator, OPS status, or any combination thereof (e.g., frequency of operational transfers, operator alertness, OPS sensor readings, calendar entries, email box fullness, keyboard input rate, or other measures). The lookup table can match the input status to an entry and perform the action associated with the entry. In some cases, an entry can instruct the system to send a notification. In some cases, an entry can instruct the system to wait a certain period before performing another lookup check to avoid overwhelming the operator with notifications. In some cases, an entry can instruct the system to adjust OPS location settings.

Additionally or alternatively, the system can have one or more default actions when no entry matches the current situation. For example, the default action can be no action or a specified action. In some cases, a random selection of actions or a rotating member of a set of defined actions can be taken. In some cases, the random action can be selected from a set of defined actions. For example, the random action can be selected so that when no entry matches, a large percentage of the time (e.g., up to 80-95% or more) no action is taken. However, at other times, the operator can receive notifications to inject variety into the operator's daily/weekly/monthly patterns.

Lookup tables can be static or dynamic. Dynamic lookup tables can be updated in response to operator feedback. Feedback can be active or passive. For example, active feedback can include an operator responding to a notification query or sending unsolicited comments or other input to the system. Passive feedback can include an operator responding to a system action, but is not explicitly related to the operator's system action. For example, an operator may stand up in response to a notification to take a break from sitting. In another scenario, an operator may remain seated in response to a notification to take a break from sitting. An operator passively responding by taking a suggested action can be considered positive feedback. An operator passively responding by not taking a suggestion can be considered negative feedback or no feedback. In some cases, passive user feedback can take the form of movement toward or away from a target. For example, the system can determine a target posture for the operator and, in response, adjust one or more OPS actuators. If the operator shifts their posture toward the target, the system can determine that the shift is positive feedback. If the operator shifts their posture toward the target posture, the system can determine that the shift is negative feedback.

The system can also dynamically change the pace of response actions based on feedback. In some cases, operators may find rapid changes or notifications disruptive. Alternatively, sparsely spaced notifications can allow regression without generating any progress toward the expressed or implicit goal. Thus, feedback-modulated intervals can allow for a balance between progress and operator disruption. For example, the system can take response actions while varying the intervals between response actions. In an example scenario, the system can increase the intervals between response actions until feedback (e.g., expressed or sensor-derived) indicates regression from the goal. The system can also respond to changes in effectiveness. For example, the system can increase the length of the intervals until the decline in effectiveness accelerates with respect to the increase. In another scenario, the system can decrease the intervals until feedback is received from the operator or until the gain in effectiveness slows with respect to the decrease in intervals.

The system can be integrated with operator applications. For example, a productivity application can be automatically launched based on profile data, building security data, calendar data, occupancy data, or other data. In one example, an email application can be launched when an operator arrives at the office. Additionally or alternatively, an application or login can be terminated when the operator leaves their desk or workstation. Such termination can reduce surreptitious access to secure data by unauthorized individuals.

The system can also be applied in workplace environments outside of offices. In some cases, the system can be applied in environments such as automobiles and heavy machinery. The OPS can utilize cellular or other wireless data connectivity to transmit sensor data to a central analysis system. In an example scenario, an OPS system implemented in a tractor can be used to monitor operator behaviors and patterns similar to those described in an office environment, such as sitting time or other sedentary patterns. In addition, the OPS can also perform environmental monitoring. For example, the OPS can measure and report the operator's exposure levels. For example, exposure levels to vibration, toxins, radiation, or other environmental factors that may have health effects.

The system can also be used to provide users with notifications related to healthcare. Additionally or alternatively to providing monitoring and warnings for exposure risks, the system can be used to provide notifications of health-related behavioral issues. For example, the system can warn airline passengers to get up and move around during long flights to avoid the risk of blood clots. Similarly, the system can provide warnings about other long-term sitting. In some implementations, the system can access health records and selectively provide warnings based on the risk of individual operators. Additionally or alternatively, the warnings can be provided to a health warning filtering system, for example maintained by a third party, which will filter the warnings based on the health history of the individual operator. Thus, in some cases, filtering can be applied without sharing health records.

The interfaces discussed above can be implemented on an operator device, such as a mobile device. FIG6 illustrates an example mobile device 1200 for interface presentation. In this example, the mobile device 1200 is a smartphone, but the mobile device can be any mobile device, such as, but not limited to, a smartphone, a smartwatch, smart glasses, a tablet, a laptop, or other device. Therefore, the smartphone described below is merely an example context for explaining the architecture and techniques.

As an example, mobile device 1200 may be a 2G, 3G, 4G/LTE, or faster cellular telephone capable of making and receiving wireless phone calls, and sending and receiving data using 802.11 a/b/g/n/ac/ad ("WiFi"), Bluetooth (BT), near field communication (NFC), or any other type of wireless technology. Mobile device 1200 may also be a smartphone that runs any number or type of applications in addition to making and receiving phone calls.

The example mobile device 1200 can communicate with a network controller 1250, such as an enhanced Node B (eNB) or other base station. The network controller 1250 and the mobile device 1200 establish communication channels, such as a control channel 1252 and a data channel 1254, and exchange data. In this example, the mobile device 1200 supports one or more subscriber identity modules (SIMs), such as SIM1 1202. An electrical and physical interface 1206 connects SIM1 1202 to the rest of the user device hardware, for example, via a system bus 1210.

Mobile device 1200 includes a communication interface 1212, system logic 1214, and a user interface 1218. System logic 1214 may include any combination of hardware, software, firmware, or other logic. System logic 1214 may be implemented, for example, using one or more system-on-chips (SoCs), application-specific integrated circuits (ASICs), discrete analog and digital circuits, and other circuitry. System logic 1214 is part of the implementation of any desired functionality within mobile device 1200. In this regard, system logic 1214 may include logic that facilitates, for example, decoding and playing music and video (e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback); running applications, accepting user input; storing and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections (e.g., Internet connectivity); establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on user interface 1218. The user interface 1218 and input 1228 may include a graphical user interface, a touch-sensitive display, tactile feedback or other tactile output, voice or facial recognition input, buttons, switches, speakers, and other user interface elements. Additional examples of input 1228 include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headphone and microphone input/output jacks, universal serial bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors), and other types of input.

System logic 1214 may include one or more processors 1216 and memory 1220. Memory 1220 stores, for example, control instructions 1222 that processor 1216 executes to perform desired functionality for mobile device 1200. Control parameters 1224 provide and specify configuration and operating options for control instructions 1222. Memory 1220 may also store any BT, WiFi, 3G, or other data 1226 that mobile device 1200 will transmit or has received via communication interface 1212.

In various implementations, system power may be provided by a power storage device such as battery 1282 .

In the communication interface 1212, radio frequency (RF) transmit (Tx) and receive (Rx) circuitry 1230 handles the transmission and reception of signals via one or more antennas 1232. The communication interface 1212 may include one or more transceivers. The transceiver may be a wireless transceiver that includes modulation/demodulation circuitry, a digital-to-analog converter (DAC), a shaping table, an analog-to-digital converter (ADC), filters, a waveform shaper, filters, preamplifiers, power amplifiers, and/or other logic for transmitting and receiving via one or more antennas or (for some devices) via a physical (e.g., wired) medium.

Transmitted and received signals may conform to any of a variety of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM), frequency channels, bit rates, and encodings. As a specific example, communication interface 1212 may include a transceiver that supports transmission and reception under 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA)+, and 4G/Long Term Evolution (LTE) standards. However, the techniques described below are applicable to other wireless communication technologies, whether derived from the Third Generation Partnership Project (3GPP), the GSM Association, 3GPP2, the IEEE, or other partners or standards bodies.

At other scales of use, such as facilities management, human resources management, and/or other enterprise management, generalized features from aggregated analytics can be used. Furthermore, the set of features used can be tailored to the operator's application, whether at the enterprise or individual level. At the enterprise level, the analytics system 200 can provide occupancy tracking, space utilization and performance ratios, aggregate and individual OPS usage information, maintenance feedback, predictive maintenance schedules, aggregate and individual behavioral analytics, temperature levels, noise levels, and/or other enterprise data.

HR and health/wellness providers can also access reports generated by the analysis system 200. These reports can include physical ergonomic reports indicating physical health, cognitive ergonomic reports related to mental health and employee satisfaction for retention purposes, and trend analysis that can be used for intervention and/or other loss prevention activities. These reports can also be used to generate links to wellness programs or other HR activities.

In some implementations, occupational profiles can be determined based on OPS data and other characteristic data. A human resources department can provide occupational and task descriptions for various employees. Using these descriptions, the system can match the descriptions with collected employee characteristics. The set of characteristics can be analyzed to determine an occupational profile based on the provided occupational descriptions. This analysis can yield a set of characteristics common among employees with a particular description. In some cases, before determining specific characteristics for an operator based on the possible characteristics of the occupational description the operator might give them, actionable observations can be provided based on the operator's pre-formed occupational profile. For example, OPS types (e.g., seat type, desk type, and/or other OPS) can be suggested for certain occupational descriptions. Additionally or alternatively, actionable behavioral observations can be generated based on the occupational description data. For example, actionable observations regarding break timing or length can be based on expected periodic tasks or other tasks for the operator's given occupational description. Furthermore, posture suggestions can be included as actionable observations. For example, for an occupation characterized by long periods of seated time, standing breaks can be suggested to an operator who exhibits characteristics of primarily taking seated breaks.

The system can query a human resources database to access job descriptions. Furthermore, the system can send job description updates to the database based on behaviors learned from operator observations. For example, human resources may provide a given job description that may not match the behaviors of the operator assigned to that description. The analysis system can identify this mismatch and update the job description.

Additionally or alternatively, facility management level data can be used to perform OPS maintenance and inventory management. In an example scenario, an OPS may have an actual age of 7 years, but usage levels are similar to a 12-year-old OPS. In response to such a determination, actions can be taken. For example, a high-use OPS can be rotated out for another OPS that is experiencing unexpectedly light loads. Thus, the overall life of the fleet can be extended. Furthermore, OPS can be transferred regularly to take into account operator schedules. For example, once a year, OPS can be transferred between known light users and heavy users, resulting in even wear. In the example, scenario chairs can be swapped from a 3-shift/week group to a 2-shift/week group, resulting in even wear. OPS involved in a recall or experiencing a failure can be accurately located and replaced or overhauled. Further defects can be identified and quickly resolved. In the example scenario, the failure may have occurred in a specific brand of chair at a specific age. The identified brand and age of chair can be accurately located and overhauled.

The system can be integrated with building functions for heating/cooling control, security functions, lighting control, and/or other functions. For example, occupants with foreign features can be contained in a specific non-safe zone. When a foreign feature is detected, other security functions such as cameras can enter a secondary mode. For example, when a foreign feature is detected, a security camera can record high-resolution video. In another example, when no occupants are detected, the system can reduce the resolution or frame rate of the stored video. During drills or emergency situations, the system can be used to determine that occupants have moved to a safe area or that there are currently no occupants in the danger zone. In another scenario, in an area without occupants, the lighting or heating/cooling can be turned off.

Suppliers can also use management-level data to determine product matches for specific customers. For example, if most users at a particular company sit at the front of their chairs, it might be beneficial to recommend a chair model that provides support for people sitting on the edge of their chairs. As discussed above, defect identification can also help suppliers with loss prevention and liability.

7-10 illustrate example data mappings 610 , 620 , 630 , 640 for various features.

7 shows a mapping 610 for determining the usage and warranty status of a chair. Data such as individual weight, chair movement, and/or other data may be processed to determine the usage of the chair and then determine the status of the chair in terms of warranty coverage.

8 shows a mapping 620 for determining chair rotational usage and target sales. Data such as seat pan weight distribution, individual weight, chair movement, and/or other data can be processed to determine chair rotational usage and then, based on usage, determine which products may be best for the individual operator.

9 shows a map 630 for determining chair adjustments for an operator. Data such as seat pan weight distribution, back weight distribution, rate of reclining individual weight, and/or other data may be processed to determine adjustments that may result in improved physical fitness.

Figure 10 shows a mapping for operator focus/distraction analysis. Data such as seat pan weight distribution, back weight distribution, chair orientation and position, chair rotation data and/or other data can be processed to determine a focus profile for the operator. For example, the system can determine the number or length of distraction periods versus focus periods. Additionally or alternatively, the system can determine times to recommend breaks based on the operator's focus level. For example, when the operator is distracted, a break can be recommended. Focus determination can be integrated with other data. For example, accessed calendar data can indicate that the operator has an upcoming meeting. If the operator is distracted from preparing for this meeting, the system can send a reminder to focus on preparing for the upcoming meeting.

FIG11 illustrates example enterprise logic 700 that may be executed on assessment processor 422 and contextualization processor 424. Enterprise logic 700 may receive data (702). For example, enterprise logic 700 may receive data from OPS sensors, applications, building sensors, operator feedback, and/or other data sources. Enterprise logic 700 may determine the current state of one or more enterprise applications (704). Enterprise logic may select a state based on the received data (706). For example, data may determine that an application should be in a "top visible window" state or an active state based on the received data. In another example, enterprise logic 700 may determine the state to include sending a push notification based on the received data. Based on the application data and/or sensor data, the notification may include a notification such as an instant message, text message, push notification, image, email, sound, video, or other media. For example, the notification may include actionable observations based on calendar information related to an upcoming meeting and seat positioning information related to operator focus. Enterprise logic may determine whether the current state matches a selected state associated with the received data (708). For example, the system can determine whether the selected application is launched or whether an appropriate notification is displayed or was recently displayed. If the current state matches the selected state, then the enterprise logic 700 can maintain the current state (710) and return to monitoring input data (702). If the current state does not match the selected state, then the enterprise logic 700 can change the state of the enterprise application (712) and then return to monitoring input data (702).

For example, if an operator remains in their chair as a meeting approaches or begins, the notification may include sending a meeting reminder. Additionally or alternatively, if the operator remains focused on the same PowerPoint or Word document for a period exceeding a certain threshold, the enterprise software may ask the operator if they need assistance, such as from a colleague working on the same project. Alternatively, the enterprise logic 700 may be configured to lock certain applications to prevent operator distraction. For example, if the operator is unusually still or restless, the enterprise logic 700 may determine that the operator is distracted. The enterprise logic 700 may lock certain internet content sources (e.g., sports or video websites) to keep the operator focused on a defined task. Additionally or alternatively, the system may determine distraction based on posture or sitting position. In other words, the system 200 may determine that the user is distracted when they are in certain postures. The enterprise logic may respond to this identification with a notification encouraging the operator to continue completing the task. In some cases, operator feedback may be used to distinguish between actual distraction and a productive break. For example, an operator may be engaging in a productive (e.g., social or professional) discussion with a colleague, which the enterprise logic may identify as a distraction. Enterprise logic 700 may responsively send a notification. Upon receiving the notification, the operator may reply with feedback indicating that enterprise logic 700 has incorrectly categorized the conversation.

Alternatively or additionally, the enterprise logic 700 can provide notifications about environmental impacts. For example, if an operator has been operating machinery with known negative vibration effects and is approaching exposure limits, the enterprise logic 700 can generate a notification for the equipment's dashboard or the operator's mobile device.

FIG12 illustrates example maintenance logic 800 that may be executed on the assessment processor 422 and the contextualization processor 424. The maintenance logic 800 may receive input data from the OPS (802). For example, the input data may include usage data, movement data, positioning data, model data, and/or other data. The maintenance logic 800 may access expected performance data for the OPS (804). For example, the maintenance logic 800 may access a vendor database containing the lifespan and normal operating parameters of the OPS model. Based on the input data and the expected performance data, the maintenance logic 800 may determine an operating condition of the OPS (806). For example, the maintenance logic 800 may determine whether the OPS is operating within a tolerance range defined by the expected performance data. In some cases, the maintenance logic may compare the age of the OPS with the expected lifespan of the OPS. The operating condition may be affected by one or both of the age-to-life ratio and the expected performance data. If the operating condition is determined to be within a satisfactory range, the maintenance logic may determine an estimated time before maintenance may be required based on the usage data and the operating condition (808). If the operating condition is not within a satisfactory range, the maintenance logic may send a service alert (810). For example, a service warning alert may automatically request a service visit from a technician. In another example, the service alert may be sent to an operator of the OPS to allow the operator to determine an appropriate action. When calculating the expected performance, the maintenance logic may send the operating condition and selected received data to a database of expected performance data for use as additional data points (812). For example, to determine the expected performance, the maintenance logic 800 may check third-party and manufacturer databases for warranty dates, check for product recall notices, failure notices, warning notices, recommended use notices or updates, compare to a recommended regular preventive maintenance schedule, or perform other maintenance queries.

In some cases, to implement a service alert, maintenance logic 800 may send a message to a service person, schedule a service visit via an automated scheduling system, check for product upgrades, check to determine if a previously ordered part is ready, maintain and update statistics for the OPS manufacturer, or perform other maintenance actions.

13 illustrates example occupancy logic 900, which may be executed on the evaluation processor 422 and the contextualization processor 424. The occupancy logic 900 may receive input data from one or more sources discussed above (902). The occupancy logic 900 may parse the data for recurring patterns (904). For example, the occupancy logic 900 may parse the data to determine when occupancy or occupancy groupings (e.g., rooms or other spaces for an OPS) may be expected or unexpected. Thus, the occupancy logic may be able to make predictions about future occupancy or space usage. For example, the occupancy logic 900 may determine that unplanned meetings occur simultaneously between certain operators on recurring weeks. The occupancy logic 900 may recognize the pattern and reserve space for the unplanned meeting without operator intervention. In some cases, the occupancy logic may add the unplanned meeting to the operator's calendar, for example, as a temporarily or permanently scheduled event.

For example, the enterprise logic can perform wavelet analysis to determine periodic patterns. The data can be compared to known states to determine overlap. For example, the occupation logic 900 can be given a mapping of two or more known application states. The occupation logic 900 can determine the current state based on the two or more known states. The occupation logic 900 can determine the current state based on the superposition of the two or more known states.

The occupancy logic 900 may associate patterns across data types (906). For example, calendar data may be compared to seat load sensor data. The occupancy logic may determine whether a possible pattern from the first data set is compatible with patterns from the other data sets (908). For example, a pattern from the calendar data may be incompatible with the sensor data readings. This may indicate that a meeting was canceled or moved, or that the discovered pattern was a false positive in either data set. If a pattern is found to be consistent between the data sets, the occupancy logic 900 may send the pattern to other logic for observation processing (910). If a pattern is found to be inconsistent between the data sets, the occupancy logic 900 may determine a confidence level for the pattern (912). For example, a common pattern may have a high confidence level compared to an uncommon pattern. For example, it may be uncommon for an office chair to be occupied when a particular operator is not present. The calendar data may indicate that the operator is not present, but the chair load sensor indicates that the chair is occupied. The occupancy logic may determine that the calendar data is incorrect, for example, because schedules may change frequently and operators may not always update their calendars. Alternatively, the occupancy logic 900 may determine that a chair load sensor is faulty if the sensor has indicated continuous occupancy for an extremely long period of time (e.g., 24 hours or another long period of time). Alternatively, or in addition, an abnormal occupancy reading may indicate that the operator has lost consciousness or otherwise requires medical assistance. Once the relative trust level is established, the occupancy logic 900 may send a trusted mode (914) over a less trusted incompatible mode. The predicted occupancy pattern may be used to change the floor plan to better match the expected usage. For example, an unused meeting space may be converted to a seated workspace, or vice versa. In some cases, the conversion may be performed by an OPS having mobility capabilities.

Additionally or alternatively, the predictive patterns may be used to control building automation, such as HVAC, lighting, security sensors, locks, or other building systems.

FIG14 illustrates example career logic 1000, which may be executed on the evaluation processor 422 and the contextualization processor 424. The career logic 1000 may access a career description from a database (1002). For example, the career logic 1000 may access the career description from a human resources database. The career logic 1000 may receive input data from the OPS (1004). The career logic 1000 may also receive an occupancy pattern from the occupancy logic 900 (1006). Based on the OPS data and the occupancy pattern, the career logic may determine an empirical career pattern for the operator (1008). The empirical career pattern may include, for example, application usage history, focus profile, rest time, meeting patterns (e.g., people typically met, times typically used for meetings, and/or other meeting data), posture profile, and/or other data for the operator. The career logic may compare the empirical career pattern with the career description accessed from the database (1010). The career logic 1000 may identify differences between the accessed career description and the empirical career pattern (1012). For example, the system may detect a number of task transfers that are outside of an expected range based on the accessed career description. The career logic may generate actionable observations based on the differences (1014). For example, the career logic may indicate that the operator should adjust the average number of daily task shifts for the operator to fit within the expected range of the career profile. Additionally or alternatively, the career logic 1000 may adjust the OPS actuator to set the chair height, adjust the distance between the operator and the monitor, adjust the stiffness of the chair back, limit the angle and speed of rotation, or other ergonomic adjustments appropriate to the career profile. The career logic 1000 may send the actionable observations for execution (1016). For example, the actionable observations may be sent as push notifications, automatic OPS adjustments, application actions, or other actions. For example, using a calendar enterprise application, the career logic 1000 may set aside internship time for a career that requires skills. In another example, the career logic 1000 may adjust the room temperature to aid productivity, e.g., to encourage alertness. In another example, the career logic 1000 may lock an application to limit distraction or prevent excessive work for the operator. In some cases, the operator may be able to override actions through the career logic 1000. Career logic 1000 may make time usage recommendations based on the efficiency of other operators with the same career profile.

FIG15 illustrates posture logic 1400, which may be executed on evaluation processor 422. Posture logic 1400 may receive sensor data such as video data, motion data, pressure data, and/or other data. Posture logic may use the data to classify an operator's posture into one or more posture states 1401-1414. Once the operator's posture is classified, posture logic 1400 may send the posture states to other logic executed, for example, on evaluation processor 422 and contextualization processor 424 for pattern determination. In some cases, posture logic may implement an initialization process in which an operator assumes one or more posture states to allow subsequent recognition by matching with the initialization states.

The classified posture states may include an upright sitting orientation 1401, a chair exit orientation 1402, a chair entry orientation 1403, a chair recline orientation 1404, a recline orientation with feet on the chair base 1405, a perch orientation with elbows on knees 1406, an upright and off-back orientation 1407, a left-leaning orientation 1408, a right-leaning orientation 1409, a left-leg crossed orientation 1412, a right-leg crossed orientation 1411, a slouching orientation 1412, a chair rotation state 1413, a relaxation state 1414 and/or other posture states.

The states can be distinguished via different weight distributions and/or different video or odometry features on the strain sensors in the seat. For example, a person leaning to the left may have extra weight on the left side of the seat pan and/or left armrest. A person sitting upright may have a balanced left/right weight distribution. Similarly, a person reclining may have extra weight on the backrest and have spinal or neck curvature that may be visible via video capture.

The methods, devices, processes, and logic described above can be implemented in many different ways and in many different combinations of hardware and software. For example, all or part of an implementation can include an instruction processor such as a central processing unit (CPU), microcontroller, or microprocessor; an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a field-programmable gate array (FPGA); or a circuit including discrete logic or other circuit components (including analog circuit components, digital circuit components, or both); or any combination thereof. As an example, the circuit can include discrete interconnected hardware components and/or can be combined on a single integrated circuit die, distributed among multiple integrated circuit dies, or implemented in a multi-chip module (MCM) where multiple integrated circuit dies are packaged together.

The circuitry may further include or access instructions for execution by the circuitry. The instructions may be stored in a tangible storage medium other than a transient signal, such as flash memory, random access memory (RAM), read-only memory (ROM), or erasable programmable read-only memory (EPROM); on a magnetic or optical disk, such as a compact disk read-only memory (CDROM), a hard disk drive (HDD), or other magnetic or optical disk; or in or on another machine-readable medium. A product, such as a computer program product, may include a storage medium and instructions stored in or on the medium, and when the instructions are executed by circuitry in a device, may cause the device to implement any of the processes described above or illustrated in the accompanying figures.

The implementation may be distributed as circuitry between multiple system components (such as between multiple processors and memories), optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be stored and managed separately, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many different ways, including as data structures (such as linked lists, hash tables, arrays, records, objects, or implicit storage mechanisms). Programs may be part of a single program (e.g., a subroutine), separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library (such as a shared library (e.g., a dynamic link library (DLL))). A DLL may, for example, store instructions that, when executed by the circuitry, perform any of the processes described above or illustrated in the accompanying drawings.

Various implementations have been described in detail. However, many other implementations are possible. Various features and advantages of the present invention are set forth in the following claims.

Claims (15)

1. A furniture system comprising: Chairs (100), including Sitting part (134). The backrest (132) coupled to the seat (134), and A base (136) that supports the backrest (132) and the seat (134). Multiple sensors (140) coupled to the chair (100), each sensor (140) operable to detect physical forces transmitted by a user onto the chair (100) and generate an output signal indicating the physical forces; and The processor coupled to the plurality of sensors (140), and the processor, are operable to: Receive the output signals generated by the plurality of sensors (140), The current posture of the user sitting in the chair (100) is determined based on at least one of the output signals; and To implement enterprise logic (700): Determine when the user is distracted based on the user's posture; In response to determining that the user is distracted, a push notification is sent to the user to encourage them to continue performing the task; and Receive feedback from the user indicating that the enterprise logic (700) inappropriately determined that the user was distracted. 2. The furniture system of claim 1, wherein the processor is operable to determine orientation parameters of the chair (100) based on at least one of the output signals, the orientation parameters corresponding to the tilt of the seat (134) relative to the base (136), the weight distribution on the backrest (132), or the tilt of the seat (134) relative to a horizontal plane, and wherein the user’s current posture is determined based on the orientation parameters. 3. The furniture system of claim 1, wherein the chair (100) further comprises a first armrest and a second armrest. The first of the plurality of sensors (140) is coupled to the first handrail and operable to determine a first force vector acting on the first handrail, and The processor is operable to determine the user's current posture based on the first force vector. 4. The furniture system of claim 3, wherein the second sensor of the plurality of sensors (140) is coupled to the second armrest and operable to determine a second force vector acting on the second armrest, and wherein the processor is operable to Determine the difference between the first force vector and the second force vector, and The user's current posture is determined based on the difference. 5. The furniture system of claim 1, wherein the processor is operable to The user's current posture is stored periodically. Generate reports that include information about the stored user gestures, and The report is sent to the display (116). 6. The furniture system of claim 5, wherein the report includes the length of time spent in each of the stored postures. 7. The furniture system of claim 5, wherein the processor is further operable to Determine the time period during which the user stays at the current location; and generate a notification to the user to change their posture when the time period exceeds a time threshold. 8. The furniture system of claim 5, wherein the report includes information on the time spent standing and the time spent sitting, and wherein the time spent sitting is subdivided into the time spent sitting in different postures. 9. The furniture system of claim 1, wherein the processor is operable to Instruct the user on the target pose, and In response to instructing the user on a target posture, it is determined whether the user is moving toward the target posture based on the output signals from the plurality of sensors (140). 10. The furniture system of claim 1, wherein the user’s current posture is selected from the group consisting of: an upright position, a chair-back position, a chair-back position with feet on the base, a resting position with elbows on the knees, an upright position away from the backrest, a left-leaning position, a right-leaning position, a position with the left leg crossed, a position with the right leg crossed, and a relaxed position. 11. A method for determining the posture of a user sitting on a chair (100) of the furniture system of claim 1, the method comprising: The physical forces transmitted by the user to the chair (100) are detected by the plurality of sensors (140); Each of the plurality of sensors (140) generates an output signal indicating the physical force; The processor coupled to the plurality of sensors (140) receives the output signals generated by the plurality of sensors (140); and The processor determines the current posture of the user sitting in the chair (100) based on at least one of the output signals received by the processor; Enterprise logic (700) is implemented by the processor: Determine when the user is distracted based on the user's posture; In response to determining that the user is distracted, a push notification is sent to the user to encourage the user to continue performing the task; and Receive feedback from the user to indicate that the enterprise logic (700) has inappropriately determined that the user is distracted. 12. The method of claim 11, further comprising: Based on at least one of the output signals received by the processor, the processor determines the orientation parameters of the chair (100), the orientation parameters corresponding to the tilt of the seat (134) relative to the base (136), the weight distribution on the backrest (132), or the tilt of the seat (134) relative to the horizontal plane; and Determining the user's current posture includes determining the user's current posture based on the orientation parameters. 13. The method of claim 11, wherein the chair (100) further comprises a first armrest and a second armrest, and the method further comprises: A first force acting on the first handrail is detected by the first sensor among the plurality of sensors (140) coupled to the first handrail; A second force acting on the second handrail is detected by the second sensor among the plurality of sensors (140) coupled to the second handrail; Determine the difference between the first force and the second force; and Determining the user's current posture includes determining the user's current posture based on the differences. 14. The method of claim 11, further comprising: The processor periodically stores the user's current posture; The processor generates a report including information about the stored user gestures, and The report is sent to the display (116). 15. The method of claim 11, further comprising: The processor instructs the user on the target pose; and In response to instructing the user on a target posture, the processor determines whether the user is moving toward the target posture based on output signals from the plurality of sensors (140).