Bed with user context awareness functionality

Abstract

In some implementations, a system includes a bed having a mattress. The system also includes a sensor configured to generate pressure data of the mattress. The system also includes a processor device configured to receive the pressure data; and determine a user state from at least the pressure data. The system also includes a user interface device including user interface hardware capable of providing a user interface, the user interface device configured to select a selected user interface from a plurality of available user interfaces; and provide the selected user interface to the user. Other systems, methods, devices, products, and software can be used.

Description

[0001] This document relates to the automation of consumer devices such as beds.

[0002] Cross-references to related applications

[0003] This application claims the benefit of U.S. Provisional Application Serial No. 62 / 984,207, filed March 2, 2020. The disclosure of the earlier application is considered part of the disclosure of this application (and is incorporated herein by reference).

[0004] background

[0005] Generally speaking, a bed is a piece of furniture used as a place to sleep or relax. Many modern beds have a soft mattress on the bed frame. The mattress may include springs, foam material, and / or air chambers to support the weight of one or more occupants.

[0006] Overview

[0007] In some implementations, a system includes a bed with a mattress. The system also includes sensors configured to generate pressure data from the mattress. The system further includes a processor device configured to receive the pressure data and determine a user state based on at least the pressure data. The system also includes a user interface device comprising user interface hardware capable of providing a user interface, configured to select a chosen user interface from a plurality of available user interfaces and to provide the selected user interface to the user. Other systems, methods, devices, products, and software may be used.

[0008] The implementation may include any, all, or none of the following features. To determine user status, the processor is configured to determine bed presence; and the user interface device is configured to select one of a group consisting of a bed control user interface and a sleep data user interface as the selected user interface based on the bed presence. To determine user status, the processor is configured to determine the bed presence and time; and the user interface device is configured to select one of a group consisting of a bed control user interface, a wake-up user interface, and a sleep data user interface as the selected user interface based on the bed presence and time. In response to selecting the wake-up user interface, the user interface is also configured to send an instruction to the peripheral controller for engaging the peripheral device. To determine user status, the processor is configured to determine at least one biometric reading and bed presence; and the user interface device is configured to select one of a group consisting of a biometric user interface, a bed control user interface, and a sleep data user interface as the selected user interface based on the biometric reading and bed presence. The user interface device is also configured to select the selected peripheral action from a plurality of available peripheral actions; send an instruction to the peripheral controller based on the selected peripheral action; and the system further includes a peripheral controller comprising a second processor and computer memory, the peripheral controller being configured to engage the peripheral device according to the peripheral action. The system also includes peripheral sensors configured to generate peripheral data; and a processor device configured to receive the peripheral data; and to determine the user's state based on at least pressure data and the peripheral data. The user interface includes graphical user interface (GUI) elements. The user interface includes audible output and voice-based input.

[0009] The implementation may provide some, all, or none of the following advantages.

[0010] Bed-related user context can be sensed and used to drive automation and / or user interface selection. For example, user context can be sensed automatically without any intentional user input (e.g., button press). This automatic sensing can then be used to provide the user with environmental and user interface adjustments to increase the usability of the relevant technologies. The sensing technology is advanced. The computer-generated user interface technology is advanced. The home automation technology is advanced.

[0011] Other features, aspects, and potential advantages will be apparent from the accompanying description and figures. Attached Figure Description

[0012] Figure 1 An example airbed system is shown.

[0013] Figure 2This is a block diagram illustrating examples of the components of an air bed system.

[0014] Figure 3 An example environment is shown, including a bed that communicates with devices located in and around the home.

[0015] Figure 4A and Figure 4B This is a block diagram of an example data processing system that can be associated with a bed.

[0016] Figure 5 and Figure 6 This is a block diagram of an example motherboard that can be used in a data processing system that can be associated with a bed.

[0017] Figure 7 This is a block diagram of an example of a subboard that can be used in a data processing system that can be associated with a bed.

[0018] Figure 8 This is a block diagram of an example motherboard without a daughterboard that can be used in a data processing system that can be associated with a bed.

[0019] Figure 9 This is a block diagram of an example of a sensor array that can be used in a data processing system that can be associated with a bed.

[0020] Figure 10 This is a block diagram of an example control array that can be used in a data processing system that can be associated with a bed.

[0021] Figure 11 This is a block diagram of an example computing device that can be used in a data processing system that can be associated with a bed.

[0022] Figures 12-16 This is a block diagram of an example cloud service that can be used in a data processing system that can be associated with a bed.

[0023] Figure 17 This is a block diagram illustrating an example of using a data processing system that can be associated with a bed to automate peripheral devices around the bed.

[0024] Figure 18 This is a schematic diagram illustrating examples of computing devices and mobile computing devices.

[0025] Figure 19 This is a swimlane diagram of an example process for sensing user state and engaging the machine based on that state.

[0026] Figures 20-22 This is a flowchart of an example process for sensing user status and engaging machines based on that user status.

[0027] Figures 23A-27 This is an example graphical user interface (GUI).

[0028] Similar reference symbols in the various figures indicate similar elements.

[0029] Detailed description

[0030] Beds and associated sensors can be used to sense a user's state because it is related to the bed and the environment. For example, it can sense whether the user is in bed or out of bed, their sleep state (e.g., awake, asleep, deep sleep, waking up, awake in bed), their biometrics, and so on. Based on the user's state, home automation can be adjusted, and various user interfaces can be selected to suit the sensed state. For example, when the user is awake in bed, a user interface with bed controls can be displayed, while when the user is awake out of bed, a different user interface with a summary of the user's sleep history can be displayed. This technology can be used with various user-sensing hardware, including airbeds with pressure sensors, strap or pad sensors placed next to the mattress, or other hardware.

[0031] Example airbed hardware

[0032] Figure 1 An example air bed system 100 including a bed 112 is shown. The bed 112 includes at least one air chamber 114, which is surrounded by a resilient border 116 and enclosed by a bed ticking 118. The resilient border 116 may include any suitable material, such as foam.

[0033] like Figure 1As shown, bed 112 may be a dual-chamber design having a first fluid chamber and a second fluid chamber (e.g., a first air chamber 114A and a second air chamber 114B). In alternative embodiments, bed 112 may include a chamber for use with a fluid suitable for the application, rather than air. In some embodiments, such as single beds or children's beds, bed 112 may include a single air chamber 114A or 114B or multiple air chambers 114A and 114B. The first air chamber 114A and the second air chamber 114B may be in fluid communication with pump 120. Pump 120 may be in electrical communication with remote control 122 via control box 124. Control box 124 may include a wired or wireless communication interface for communicating with one or more devices including remote control 122. Control box 124 may be configured to operate pump 120 to cause an increase or decrease in the fluid pressure of the first air chamber 114A and the second air chamber 114B based on commands input by a user using remote control 122. In some embodiments, the control box 124 is integrated into the housing of the pump 120.

[0034] The remote controller 122 may include a display 126, an output selection mechanism 128, a pressure increase button 129, and a pressure decrease button 130. The output selection mechanism 128 allows a user to switch the airflow generated by the pump 120 between a first air chamber 114A and a second air chamber 114B, thus enabling the control of multiple air chambers using a single remote controller 122 and a single pump 120. For example, the output selection mechanism 128 may be a physical controller (e.g., a switch or button) or an input controller displayed on the display 126. Alternatively, separate remote control units may be provided for each air chamber, and each remote control unit may include the ability to control multiple air chambers. The pressure increase button 129 and the pressure decrease button 130 allow a user to increase or decrease the pressure in the air chamber selected using the output selection mechanism 128, respectively. Adjusting the pressure in the selected air chamber can result in a corresponding adjustment of the stiffness of the respective air chamber. In some embodiments, the remote controller 122 may be omitted or modified to suit the application. For example, in some embodiments, the bed 112 may be controlled by a computer, tablet, smartphone, or other device that is wired or wirelessly connected to the bed 112.

[0035] Figure 2 This is a block diagram illustrating examples of the components of an airbed system. For example, these components could be used in example airbed system 100. Figure 2As shown, the control box 124 may include a power supply 134, a processor 136, a memory 137, a switching mechanism 138, and an analog-to-digital (A / D) converter 140. For example, the switching mechanism 138 may be a repeater or a solid-state switch. In some embodiments, the switching mechanism 138 may be located in the pump 120 instead of in the control box 124.

[0036] Pump 120 and remote controller 122 communicate bidirectionally with control box 124. Pump 120 includes motor 142, pump manifold 143, safety valve 144, first control valve 145A, second control valve 145B, and pressure transducer 146. Pump 120 is fluidly connected to first air chamber 114A and second air chamber 114B via first conduit 148A and second conduit 148B, respectively. First control valve 145A and second control valve 145B can be controlled by switching mechanism 138 and are operable to manage the flow of fluid between pump 120 and first air chamber 114A and second air chamber 114B.

[0037] In some embodiments, pump 120 and control box 124 may be provided and packaged as a single unit. In some alternative embodiments, pump 120 and control box 124 may be provided as physically separate units. In some embodiments, control box 124, pump 120, or both are integrated or otherwise included within the bed frame or bed support structure supporting bed 112. In some embodiments, control box 124, pump 120, or both are located outside the bed frame or bed support structure (e.g., in…). Figure 1 (as shown in the example).

[0038] Figure 2 The example airbed system 100 depicted includes two air chambers 114A and 114B and a single pump 120. However, other embodiments may include an airbed system having two or more air chambers and one or more pumps included in the airbed system to control the air chambers. For example, separate pumps may be associated with each air chamber of the airbed system, or pumps may be associated with multiple chambers of the airbed system. Separate pumps may allow each air chamber to be inflated or deflated independently and simultaneously. Additionally, additional pressure transducers may be included in the airbed system, for example, such that separate pressure transducers can be associated with each air chamber.

[0039] In use, processor 136 can, for example, send a command to reduce pressure to one of air chambers 114A or 114B, and switching mechanism 138 can be used to convert the low-voltage command signal sent by processor 136 to a higher operating voltage sufficient to operate safety valve 144 of pump 120 and open control valves 145A or 145B. Opening safety valve 144 allows air to escape from air chambers 114A or 114B through respective air ducts 148A or 148B. During venting, pressure transducer 146 can send pressure readings to processor 136 via A / D converter 140. A / D converter 140 can receive analog information from pressure transducer 146 and convert it into digital information usable by processor 136. Processor 136 can send the digital signal to remote controller 122 to update display 126, thereby conveying pressure information to the user.

[0040] As another example, processor 136 can send a command to increase pressure. Pump motor 142 can be energized in response to the command to increase pressure and electrically operate corresponding valves 145A or 145B to deliver air through air ducts 148A or 148B to one of the designated air chambers 114A or 114B. When air is delivered to the designated air chamber 114A or 114B to increase the stiffness of that chamber, pressure transducer 146 can sense the pressure within pump manifold 143. Furthermore, pressure transducer 146 can send the pressure reading to processor 136 via A / D converter 140. Processor 136 can use the information received from A / D converter 140 to determine the difference between the actual pressure and the desired pressure in air chamber 114A or 114B. Processor 136 can send the digital signal to remote controller 122 to update display 126, thereby conveying pressure information to the user.

[0041] In general, the pressure sensed within pump manifold 143 during inflation or deflation can provide an approximation of the pressure in the respective air chambers fluidly in communication with pump manifold 143. An example method for obtaining a pump manifold pressure reading that is substantially equivalent to the actual pressure within the air chambers includes turning off pump 120, allowing the pressure in air chambers 114A or 114B to equalize with the pressure in pump manifold 143, and then sensing the pressure within pump manifold 143 using pressure transducer 146. Therefore, providing a sufficient amount of time to allow the pressure in pump manifold 143 to equalize with the pressure in chambers 114A or 114B can yield a pressure reading that is an accurate approximation of the actual pressure in air chambers 114A or 114B. In some embodiments, multiple pressure sensors (not shown) can be used to continuously monitor the pressure in air chambers 114A and / or 114B.

[0042] In some implementations, the information collected by pressure transducer 146 can be analyzed to determine various states of a person lying on bed 112. For example, processor 136 can use the information collected by pressure transducer 146 to determine the heart rate or respiratory rate of the person lying on bed 112. For example, a user may lie on one side of bed 112, including chamber 114A. Pressure transducer 146 can monitor pressure fluctuations in chamber 114A, and this information can be used to determine the user's heart rate and / or respiratory rate. As another example, the collected data can be used to perform additional processing to determine a person's sleep state (e.g., awake, light sleep, deep sleep). For example, processor 136 can determine when a person fell asleep and various sleep states while asleep.

[0043] Additional information associated with the user of the airbed system 100, which can be determined using information collected by pressure transducer 146, includes the user's movement, the user's presence on the surface of bed 112, the user's weight, the user's cardiac arrhythmias, and apnea. For example, in detecting user presence, pressure transducer 146 can be used to determine, for example, the presence of a user on bed 112 via changes in total pressure and / or via one or more of a respiratory rate signal, a heart rate signal, and / or other biometric signals. For instance, a simple pressure detection process can identify an increase in pressure as an indication of the presence of a user on bed 112. As another example, if the detected pressure increases above a specified threshold (to indicate that a person or other object above a certain weight is on bed 112), processor 136 can determine that the user is on bed 112. As yet another example, processor 136 can identify an increase in pressure by combining the detected slight, rhythmic fluctuations in pressure corresponding to the user's presence on bed 112. The presence of rhythmic fluctuations can be identified as being caused by the user's breathing or heart rhythm (or both). Breathing or heartbeat detection can distinguish between a user present on the bed and another object placed on the bed (e.g., a clothes box).

[0044] In some embodiments, pressure fluctuations can be measured at pump 120. For example, one or more pressure sensors may be located within one or more chambers of pump 120 to detect pressure fluctuations within pump 120. Pressure fluctuations detected at pump 120 may indicate pressure fluctuations in one or both of chambers 114A and 114B. One or more sensors located at pump 120 may be in fluid communication with one or both of chambers 114A and 114B, and the sensors may be operable to determine the pressure within chambers 114A and 114B. Control box 124 may be configured to determine at least one vital sign (e.g., heart rate, respiratory rate) based on the pressure within chamber 114A or chamber 114B.

[0045] In some embodiments, control box 124 can analyze pressure signals detected by one or more pressure sensors to determine the heart rate, respiratory rate, and / or other vital signs of a user lying or sitting in chamber 114A or chamber 114B. More specifically, when a user is lying on bed 112 located above chamber 114A, each heartbeat, breath, and other movement of the user can generate a force transmitted to chamber 114A on bed 112. As a result of the force input to chamber 114A due to the user's movement, a wave can propagate through chamber 114A and enter pump 120. Pressure sensors located at pump 120 can detect the wave, and therefore the pressure signals output by the sensors can indicate information about the user's heart rate, respiratory rate, or other information.

[0046] Regarding sleep state, the airbed system 100 can determine the user's sleep state using various biometric signals such as the user's heart rate, breathing, and / or movement. While the user is sleeping, the processor 136 can receive one or more of the user's biometric signals (e.g., heart rate, breathing, and movement) and determine the user's current sleep state based on the received biometric signals. In some embodiments, signals indicating pressure fluctuations in one or both of chambers 114A and 114B can be amplified and / or filtered to allow for more accurate detection of heart rate and respiratory rate.

[0047] Control box 124 can perform pattern recognition algorithms or other calculations based on amplified and filtered pressure signals to determine the user's heart rate and respiratory rate. For example, the algorithm or calculation may be based on the assumption that the heart rate portion of the signal has a frequency in the range of 0.5 Hz to 4.0 Hz, and that the respiratory rate portion of signal a has a frequency in the range of less than 1 Hz. Control box 124 can also be configured to determine other characteristics of the user based on the received pressure signals, such as blood pressure, tossing and turning movements, rolling movements, limb movements, weight, the presence or absence of the user, and / or the user's identity. Techniques for monitoring user sleep using heart rate information, respiratory rate information, and other user information are disclosed in U.S. Patent Application No. 20100170043 entitled "APPARATUS FOR MONITORING VITAL SIGNS," the entire contents of which are incorporated herein by reference.

[0048] For example, pressure transducer 146 can be used to monitor the air pressure in chambers 114A and 114B of bed 112. If the user on bed 112 does not move, the change in air pressure in chambers 114A or 114B can be relatively small and can be attributed to breathing and heartbeat. However, when the user on bed 112 moves, the air pressure in the mattress can fluctuate by a much larger amount. Therefore, the pressure signal generated by pressure transducer 146 and received by processor 136 can be filtered and indicated as corresponding to movement, heartbeat, or breathing.

[0049] In some implementations, instead of performing data analysis via processor 136 within control box 124, a digital signal processor (DSP) can be provided to analyze the data collected by pressure transducer 146. Alternatively, the data collected by pressure transducer 146 can be sent to a cloud-based computing system for remote analysis.

[0050] In some embodiments, the example airbed system 100 also includes a temperature controller configured to increase, decrease, or maintain the temperature of the bed, for example, for the comfort of the user. For example, the padding may be placed on top of or part of bed 112, or it may be placed on top of or part of one or both of chambers 114A and 114B. Air may be pushed through the padding and released to cool the user on the bed. Conversely, the padding may include heating elements that can be used to keep the user warm. In some embodiments, the temperature controller may receive temperature readings from the padding. In some embodiments, separate paddings are used on different sides of bed 112 (e.g., corresponding to the positions of chambers 114A and 114B), thereby providing different temperature control for different sides of the bed.

[0051] In some implementations, a user of the airbed system 100 can input a desired temperature for the surface of the bed 112 (or a portion thereof) using an input device, such as a remote controller 122. The desired temperature can be encapsulated in a command data structure containing the desired temperature, and a temperature controller can be used to control it as the desired component. The command data structure can then be transmitted to the processor 136 via Bluetooth or another suitable communication protocol. In various examples, the command data structure is encrypted before transmission. The temperature controller can then configure its components to increase or decrease the temperature of the padding based on the temperature input by the user to the remote controller 122.

[0052] In some implementations, data can be passed from the component back to the processor 136 or transmitted to one or more display devices (e.g., display 126). For example, current temperature, bed pressure, current position of the base, or other information determined by the sensor elements of the temperature controller can be transmitted to the control box 124. The control box 124 can then transmit the received information to a remote controller 122, where the received information can be displayed to the user (e.g., on display 126).

[0053] In some embodiments, the example airbed system 100 also includes an adjustable base and a hinge controller configured to adjust the position of the bed (e.g., bed 112) by adjusting the adjustable base that supports the bed. For example, the hinge controller can adjust bed 112 from a flat position to a position where the head portion of the mattress is tilted upwards (e.g., to allow a user to sit on the bed and / or watch television). In some embodiments, bed 112 includes multiple separate hingeable sections. For example, portions of the bed corresponding to the positions of chambers 114A and 114B can be hinged independently to allow one person on the surface of bed 112 to rest in a first position (e.g., a flat position) while a second person rests in a second position (e.g., a tilted position where the head is raised at an angle from the waist). In some embodiments, separate positions can be set for two different beds (e.g., two pairs of beds placed adjacent to each other). The base of bed 112 may include more than one area that can be adjusted independently. The hinge controller can also be configured to provide different levels of massage to one or more users on bed 112.

[0054] Examples of beds in a bedroom environment

[0055] Figure 3An example environment 300 is shown, including a bed 302 communicating with devices located in and around the home. In the illustrated example, the bed 302 includes a pump 304 for controlling the air pressure within two air chambers 306a and 306b (as described above with respect to air chambers 114A-114B). The pump 304 further includes circuitry for controlling inflation and deflation functions performed by the pump 304. This circuitry is further programmed to detect fluctuations in the air pressure of the air chambers 306a-306b and to use the detected fluctuations in air pressure to identify the bed presence of the user 308, the sleep state of the user 308, the movement of the user 308, and biometric signals of the user 308 (e.g., heart rate and respiratory rate). In the illustrated example, the pump 304 is located within the support structure of the bed 302, and control circuitry 334 for controlling the pump 304 is integrated with the pump 304. In some embodiments, the control circuitry 334 is physically separated from the pump 304 and communicates with the pump 304 wirelessly or via a wired connection. In some embodiments, pump 304 and / or control circuitry 334 are located outside of bed 302. In some embodiments, various control functions may be performed by a system located in different physical locations. For example, circuitry for controlling the operation of pump 304 may be located inside the pump housing of pump 304, while control circuitry 334 for performing other functions associated with bed 302 may be located in another part of bed 302 or outside of bed 302. As another example, control circuitry 334 located within pump 304 may communicate with control circuitry 334 at a remote location via LAN or WAN (e.g., the Internet). As yet another example, control circuitry 334 may be included in... Figure 1 and Figure 2 In the control box 124.

[0056] In some embodiments, in addition to pump 304 and control circuitry 334, one or more devices may be used to identify a user's bed presence, sleep state, movement, and biometric signals. For example, in addition to pump 304, bed 302 may include a second pump, each of the two pumps being connected to a corresponding one of the air chambers 306a-306b. For example, pump 304 may be in fluid communication with air chamber 306b to control the inflation and deflation of air chamber 306b and to detect user signals (e.g., bed presence, sleep state, movement, and biometric signals) of a user located above air chamber 306b, while the second pump is in fluid communication with air chamber 306a to control the inflation and deflation of air chamber 306a and to detect user signals of a user located above air chamber 306a.

[0057] As another example, bed 302 may include one or more pressure-sensitive pads or surface portions operable to detect motion, including user presence, user movement, breathing, and heart rate. For example, a first pressure-sensitive pad may be incorporated into the surface of bed 302 over the left side portion of bed 302, where a first user is typically positioned during sleep, and a second pressure-sensitive pad may be incorporated into the surface of bed 302 over the right side portion of bed 302, where a second user is typically positioned during sleep. Motion detected by one or more pressure-sensitive pads or surface portions can be used by control circuitry 334 to identify the user's sleep state, in-bed status, or biometric signals.

[0058] In some implementations, information detected by the bed (e.g., motion information) is processed by control circuitry 334 (e.g., control circuitry 334 integrated with pump 304) and provided to one or more user devices (e.g., user device 310) for presentation to user 308 or other users. Figure 3 In the depicted example, user equipment 310 is a tablet computer; however, in some embodiments, user equipment 310 may be a personal computer, smartphone, smart TV (e.g., TV 312), or other user equipment capable of wired or wireless communication with control circuitry 334. User equipment 310 may communicate with control circuitry 334 of bed 302 via a network or via direct peer-to-peer communication. For example, control circuitry 334 may be connected to a LAN (e.g., via a Wi-Fi router) and communicate with user equipment 310 via the LAN. As another example, both control circuitry 334 and user equipment 310 may be connected to and communicate with the Internet. For example, control circuitry 334 may be connected to the Internet via a Wi-Fi router, and user equipment 310 may be connected to the Internet via communication with a cellular communication system. As another example, control circuitry 334 may communicate directly with user equipment 310 via a wireless communication protocol (e.g., Bluetooth). As yet another example, control circuitry 334 may communicate with user equipment 310 via, for example, a wireless communication protocol such as ZigBee, Z-Wave, infrared, or another wireless communication protocol suitable for the application. As another example, the control circuit 334 can communicate with the user equipment 310 via, for example, a wired connection such as a USB connector, a serial / RS232 connection, or another wired connection suitable for the application.

[0059] User device 310 may display various sleep-related information and statistics, or interactions between user 308 and bed 302. For example, the user interface displayed by user device 310 may present information including the amount of deep sleep experienced by user 308 over a period of time (e.g., a single night, a week, a month, etc.), the ratio of deep sleep to restless sleep, the time interval between user 308 going to bed and user 308 falling asleep, the total amount of time spent in bed 302 within a given time period, user 308's heart rate over a period of time, user 308's respiratory rate over a period of time, or other information relating to user interactions with bed 302 by user 308 or one or more other users. In some embodiments, information for multiple users may be presented on user device 310; for example, information for a first user positioned above air chamber 306a may be presented together with information for a second user positioned above air chamber 306b. In some embodiments, the information presented on user device 310 may vary according to the age of user 308. For example, the information presented on user device 310 can evolve with the age of user 308, so that different information is presented on user device 310 depending on whether user 308 is a child or an adult.

[0060] User device 310 can also serve as an interface to control circuitry 334 of bed 302 to allow user 308 to input information. The information input by user 308 can be used by control circuitry 334 to provide better information to the user or to various control signals used to control functions of bed 302 or other devices. For example, the user can input information such as weight, height, and age, and control circuitry 334 can use this information to provide user 308 with a comparison of the user's tracked sleep information with the sleep information of others with similar weight, height, and / or age. As another example, user 308 can use user device 310 as an interface to control the air pressure of air chambers 306a and 306b, to control various reclining or tilting positions of bed 302, to control the temperature of one or more surface temperature control devices of bed 302, or to allow control circuitry 334 to generate control signals for other devices (as described in more detail below).

[0061] In some implementations, in addition to user equipment 310 or alternative user equipment 310, the control circuitry 334 of bed 302 (e.g., control circuitry 334 integrated into pump 304) can communicate with other first, second, or third-party devices or systems. For example, control circuitry 334 can communicate with television 312, lighting system 314, thermostat 316, security system 318, or other household devices such as oven 322, coffee maker 324, lamp 326, and nightlight 328. Other examples of devices and / or systems that control circuitry 334 can communicate with include systems for controlling blinds 330, one or more devices for detecting or controlling the state of one or more doors 332 (e.g., detecting whether a door is open, detecting whether a door is locked, or automatically locking a door), and systems for controlling garage door 320 (e.g., control circuitry 334 integrated with a garage door opener for identifying the open or closed state of garage door 320 and for causing the garage door opener to open or close garage door 320). Communication between the control circuitry 334 of bed 302 and other devices can occur via a network (e.g., LAN or the Internet) or point-to-point communication (e.g., using Bluetooth, radio communication, or a wired connection). In some embodiments, the control circuitry 334 of different beds 302 can communicate with different groups of devices. For example, a children's bed cannot communicate with and / or control the same devices as an adult bed. In some embodiments, the bed 302 can evolve with the user's age, such that the control circuitry 334 of bed 302 communicates with different devices based on the user's age.

[0062] Control circuit 334 can receive information and input from other devices / systems and use this received information and input to control the operation of bed 302 or other devices. For example, control circuit 334 can receive information from thermostat 316 indicating the current ambient temperature of the house or room where bed 302 is located. Control circuit 334 can use this received information (along with other information) to determine whether the temperature of all or part of the surface of bed 302 should be raised or lowered. Then, control circuit 334 can cause the heating or cooling mechanism of bed 302 to raise or lower the surface temperature of bed 302. For example, user 308 can indicate a desired sleeping temperature of 74 degrees Celsius, while a second user of bed 302 can indicate a desired sleeping temperature of 72 degrees Celsius. Thermostat 316 can indicate to control circuit 334 that the current temperature of the bedroom is 72 degrees Celsius. The control circuit 334 can recognize that the user 308 has indicated a desired sleep temperature of 74 degrees and send a control signal to the heating pad located on the side of the bed where the user 308 is located to raise the temperature of a portion of the surface of the bed 302, wherein the user 308 is positioned to raise the temperature of the sleep surface of the user 308 to the desired temperature.

[0063] Control circuit 334 can also generate control signals for other devices and propagate these control signals to those devices. In some embodiments, the control signals are generated based on information collected by control circuit 334, including information relating to user interaction with bed 302 performed by user 308 and / or one or more other users. In some embodiments, information collected from one or more other devices, rather than from bed 302, is used when generating control signals. For example, when generating control signals for various devices communicating with control circuit 334 of bed 302, information related to environmental events (e.g., ambient temperature, ambient noise level, and ambient light level), time of day, day of the year, day of the week, or other information may be used. For example, information about the time of day may be combined with information about the movement and bed-being of user 308 to generate control signals for lighting system 314. In some implementations, instead of providing control signals to one or more other devices, control circuitry 334 may provide collected information (e.g., information related to user movement, bed condition, sleep state, or biometric signals of user 308) to one or more other devices to allow the collected information to be used by the other devices when generating control signals. For example, control circuitry 334 of bed 302 may provide information from the user to a central controller (not shown) relating to user interaction with bed 302, which the central controller may use to generate control signals for various devices, including bed 302.

[0064] Still referencing Figure 3The control circuit 334 of bed 302 can generate control signals for controlling the operation of other devices and, in response to information collected by the control circuit 334 (including the user 308's bed-keeping status, the user 308's sleep state, and other factors), transmit the control signals to other devices. For example, the control circuit 334 integrated with pump 304 can detect characteristics of the mattress of bed 302, such as an increase in pressure in air chamber 306b, and use the detected increase in air pressure to determine that the user 308 is present on bed 302. In some embodiments, the control circuit 334 can identify the user 308's heart rate or respiratory rate to identify that the increase in pressure is due to a person sitting, lying, or otherwise placed on bed 302, rather than an inanimate object (e.g., a suitcase) already placed on bed 302. In some embodiments, information indicating the user's bed-keeping status is combined with other information to identify the user 308's current or possible future state. For example, a user's presence in bed detected at 11:00 AM could indicate that the user is sitting on the bed (e.g., tying her shoelaces or reading) and does not intend to go to sleep, while a user's presence in bed detected at 10:00 PM could indicate that user 308 is sleeping at night and intends to fall asleep soon. As another example, if control circuit 334 detects that user 308 has already left bed 302 at 6:30 AM (e.g., indicating that the user has woken up for the day), and then detects user 308's presence in bed again at 7:30 AM, control circuit 334 can use this information to suggest that the newly detected presence in bed may be temporary (e.g., when user 308 is tying her shoelaces before going to work), rather than indicating that user 308 intends to stay in bed 302 for an extended period.

[0065] In some implementations, control circuitry 334 can use collected information (including information related to user interaction between user 308 and bed 302, as well as environmental information, time information, and input received from the user) to identify user 308's usage patterns. For example, control circuitry 334 can use information collected over a period of time indicating user 308's bed-being and sleep state to identify the user's sleep patterns. For example, based on user presence and biometric information collected over a week, control circuitry 334 can identify that user 308 typically goes to bed between 9:30 PM and 10:00 PM, typically falls asleep between 10:00 PM and 11:00 PM, and typically wakes up between 6:30 AM and 6:45 AM. Control circuitry 334 can use patterns that are recognizable to the user to better process and identify user interaction between user 308 and bed 302.

[0066] For example, given the above example of user 308's bed-being status, sleep, and wake-up patterns, if user 308 is detected in bed at 3:00 PM, control circuit 334 can determine that the user's presence in bed is only temporary, and use this determination to generate a different set of control signals than would be generated if control circuit 334 determined that user 308 was sleeping at night. As another example, if control circuit 334 detects that user 308 has left bed at 3:00 AM, control circuit 334 can use the patterns identified for user 308 to determine that the user is only temporarily out of bed (e.g., using the bathroom, or drinking a glass of water) and not actually awake for the day. Conversely, if control circuit 334 identifies that user 308 has left bed 302 at 6:40 AM, control circuit 334 can determine that the user is awake for the day and generate a different set of control signals than would be generated if control circuit 334 determined that user 308 was only temporarily out of bed (possibly when user 308 left bed 302 at 3:00 AM). For other users 308, getting out of bed at 3:00 AM may be a normal wake-up time, and control circuit 334 can learn and respond to this.

[0067] As described above, the control circuit 334 of bed 302 can generate control signals for controlling the functions of various other devices. These control signals can be generated, at least in part, based on detected interactions between user 308 and bed 302, as well as other information including time, date, temperature, etc. For example, control circuit 334 can communicate with television 312, receive information from television 312, and generate control signals for controlling the functions of television 312. For example, control circuit 334 can receive an indication from television 312 that television 312 is currently on. If television 312 is located in a different room from bed 302, control circuit 334 can generate a control signal to turn off television 312 when it is determined that user 308 has gone to sleep at night. For example, if user 308 is detected in bed 302 within a specific time range (e.g., between 8:00 PM and 7:00 AM) for a duration longer than a threshold time period (e.g., 10 minutes), control circuit 334 can use this information to determine that user 308 is going to sleep at night. If the television 312 is turned on (as indicated by communication received from the television 312 via the control circuit 334 of the bed 302), the control circuit 334 can generate a control signal to turn off the television 312. The control signal can then be transmitted to the television (e.g., via a directional communication link between the television 312 and the control circuit 334 or via a network). As another example, instead of turning off the television 312 in response to detecting that a user is in bed, the control circuit 334 can generate a control signal that lowers the volume of the television 312 by a predetermined amount.

[0068] As another example, when it is detected that user 308 has left bed 302 within a specified time range (e.g., between 6:00 AM and 8:00 AM), control circuitry 334 can generate a control signal to turn on television 312 and tune it to a predetermined channel (e.g., user 308 has indicated a preference to watch the morning news when leaving bed in the morning). Control circuitry 334 can generate a control signal and pass it to television 312 to turn on television 312 and tune it to a desired station (which may be stored in control circuitry 334, television 312, or another location). As another example, when it is detected that user 308 has gotten up for the day, control circuitry 334 can generate and pass a control signal to turn on television 312 and begin playing previously recorded programs from a digital video recorder (DVR) communicating with television 312.

[0069] As another example, if the television 312 is located in the same room as the bed 302, the control circuit 334 will not cause the television 312 to turn off in response to the detection of the user's presence. Instead, the control circuit 334 may generate and transmit a control signal to turn off the television 312 in response to determining that the user 308 is asleep. For example, the control circuit 334 may monitor the user 308's biometric signals (e.g., movement, heart rate, respiratory rate) to determine that the user 308 has fallen asleep. When the user 308 is detected to be asleep, the control circuit 334 generates and transmits a control signal to turn off the television 312. As another example, the control circuit 334 may generate a control signal to turn off the television 312 after a threshold period of time after the user 308 has fallen asleep (e.g., 10 minutes after the user has fallen asleep). As another example, the control circuit 334 generates a control signal to lower the volume of the television 312 after determining that the user 308 has fallen asleep. As yet another example, the control circuit 334 generates and transmits a control signal to cause the television volume to gradually decrease over a period of time and then turn off the television in response to determining that the user 308 has fallen asleep.

[0070] In some implementations, the control circuit 334 can similarly interact with other media devices, such as computers, tablets, smartphones, stereo systems, etc. For example, after detecting that the user 308 has fallen asleep, the control circuit 334 can generate a control signal and transmit it to the user device 310 to turn off or lower the volume of a video or audio file that the user device 310 is playing.

[0071] Control circuitry 334 may additionally communicate with lighting system 314, receiving information from lighting system 314 and generating control signals for controlling the functions of lighting system 314. For example, when it detects that a user is in bed 302 during a specific time frame (e.g., between 8:00 PM and 7:00 AM) for a duration longer than a threshold time period (e.g., 10 minutes), control circuitry 334 of bed 302 may determine that user 308 is sleeping at night. In response to this determination, control circuitry 334 may generate control signals to turn off lights in one or more rooms other than the room where bed 302 is located. This control signal may then be transmitted to lighting system 314 and executed by lighting system 314 to instruct the lights in the indicated rooms to turn off. For example, control circuitry 334 may generate and transmit control signals to turn off lights in all common rooms but not in other bedrooms. As another example, the control signal generated by control circuit 334 can instruct that lights in all rooms except the room where bed 302 is located will be turned off, while one or more lights located outside the house containing bed 302 will be turned on in response to determining that user 308 is sleeping at night. Alternatively, control circuit 334 can generate and transmit a control signal to turn on nightlight 328 in response to determining that user 308 is in bed or that user 308 is asleep. As another example, control circuit 334 can generate a first control signal and a second control signal, the first control signal for turning off a first set of lights (e.g., lights in common rooms) in response to determining that user 308 is in bed, and the second control signal for turning off a second set of lights (e.g., lights in the room where bed 302 is located) in response to determining that user 308 is asleep.

[0072] In some implementations, in response to determining that user 308 is sleeping at night, control circuitry 334 of bed 302 can generate a control signal to enable lighting system 314 to implement a sunset lighting scheme in the room where bed 302 is located. The sunset lighting scheme may include, for example, combining with changes in the color of light in the bedroom environment (e.g., adding an amber tint to the bedroom lighting) to dim the lights (gradually over time or all at once). The sunset lighting scheme can help user 308 fall asleep when control circuitry 334 has determined that user 308 is sleeping at night.

[0073] Control circuit 334 can also be configured to implement a sunrise lighting scheme when user 308 wakes up in the morning. Control circuit 334 can determine that user 308 has woken up that day, for example, by detecting that user 308 has left bed 302 (i.e., is no longer present on bed 302) during a specified time period (e.g., between 6:00 AM and 8:00 AM). As another example, control circuit 334 can determine that user 308 has woken up by monitoring user 308's movement, heart rate, respiratory rate, or other biometric signals, even if user 308 has not yet left bed. If control circuit 334 detects that user 308 has woken up during the specified time period, control circuit 334 can determine that user 308 has woken up that day. The specified time period can be based, for example, on previously recorded user bedtime information collected over a period of time (e.g., two weeks), indicating that user 308 typically wakes up between 6:30 AM and 7:30 AM that day. In response to control circuitry 334 determining that user 308 is awake, control circuitry 334 may generate a control signal to cause lighting system 314 to implement a sunrise lighting scheme in the bedroom where bed 302 is located. The sunrise lighting scheme may include, for example, turning on lights (e.g., lamp 326, or other lights in the bedroom). The sunrise lighting scheme may also include gradually increasing the light level in the room where bed 302 is located (or in one or more other rooms). The sunrise lighting scheme may also include turning on only lights of a specified color. For example, the sunrise lighting scheme may include illuminating the bedroom with blue lights to gently assist user 308 in waking up and becoming active.

[0074] In some implementations, control circuitry 334 can generate different control signals for controlling the actions of one or more components (e.g., lighting system 314) based on the time of day during which user interaction with bed 302 is detected. For example, control circuitry 334 can use historical user interaction information between user 308 and bed 302 to determine that user 308 typically falls asleep between 10:00 PM and 11:00 PM and usually wakes up between 6:30 AM and 7:30 AM on weekdays. If user 308 is detected leaving bed at 3:00 AM, control circuitry 334 can use this information to generate a first set of control signals for controlling lighting system 314, and if user 308 is detected leaving bed after 6:30 AM, control circuitry 334 can use this information to generate a second set of control signals for controlling lighting system 314. For example, if user 308 leaves bed before 6:30 AM, control circuitry 334 can turn on a light guiding user 308 to the bathroom. As another example, if user 308 gets out of bed before 6:30 a.m., control circuit 334 can turn on lights that guide user 308 to the kitchen (e.g., this could include turning on night light 328, under-bed lighting, or light 326).

[0075] As another example, if user 308 leaves bed after 6:30 a.m., control circuitry 334 can generate a control signal to cause lighting system 314 to activate the sunrise lighting scheme, or to turn on one or more lights in the bedroom and / or other rooms. In some implementations, if user 308 is detected leaving bed before their designated wake-up time, control circuitry 334 causes lighting system 314 to turn on a dimmer light than it would if user 308 was detected leaving bed after their designated wake-up time. Having lighting system 314 turn on only a dim light when user 308 leaves bed at night (i.e., before user 308's normal wake-up time) can prevent other occupants of the house from being awakened by the lights, while still allowing user 308 to see in order to reach the bathroom, kitchen, or another destination within the house.

[0076] Historical user interaction information used for interactions between user 308 and bed 302 can be used to identify user sleep and wake-up periods. For example, user bedtime and sleep time can be determined for a set time period (e.g., two weeks, one month, etc.). Control circuitry 334 can then identify typical time ranges or periods when user 308 goes to bed, typical periods when user 308 falls asleep, and typical periods when user 308 wakes up (and in some cases, different periods when user 308 wakes up and when user 308 actually gets out of bed). In some implementations, buffer periods can be added to these time periods. For example, if a user is identified as typically sleeping between 10:00 PM and 10:30 PM, a half-hour buffer can be added to the time periods in each direction, such that any detection of user going to bed between 9:30 PM and 11:00 PM is interpreted as user 308 sleeping at night. As another example, detection of user 308's bedtime can begin half an hour before the earliest typical time extending from when user 308 goes to bed, until the user's typical wake-up time (e.g., 6:30 AM) can be interpreted as user sleeping at night. For example, if a user typically goes to bed between 10:00 PM and 10:30 PM, and the user is detected in bed at 12:30 AM, this can be interpreted as the user sleeping at night, even though it falls outside the user's typical sleep time, because it occurs before the user's normal wake-up time. In some implementations, different time periods are identified for different times of the year (e.g., earlier bedtimes in winter compared to summer) or different times of the week (e.g., the user wakes up earlier on weekday mornings than on weekend mornings).

[0077] Control circuitry 334 can distinguish between prolonged sleep (e.g., nighttime) and shorter periods of time spent on bed 302 (e.g., naps) by sensing the duration of user 308's presence. In some examples, control circuitry 334 can distinguish between prolonged sleep (e.g., nighttime) and shorter periods of time spent on bed 302 by sensing the duration of user 308's sleep. For example, control circuitry 334 can set a time threshold such that if the time sensed for user 308 on bed 302 is longer than the threshold, user 308 is considered to have gone to bed. In some examples, the threshold could be approximately 2 hours, so that if the time sensed for user 308 on bed 302 is greater than 2 hours, control circuitry 334 registers it as an extended sleep event. In other examples, the threshold could be greater than two hours or less than two hours.

[0078] Control circuitry 334 can detect recurring prolonged sleep events to automatically determine the typical bedtime range of user 308, without requiring user 308 to input the bedtime range. This allows control circuitry 334 to accurately estimate when user 308 is likely to fall asleep due to prolonged sleep events, regardless of whether user 308 typically uses a conventional or non-conventional sleep schedule. Control circuitry 334 can then use the knowledge of user 308's bedtime range to control one or more components (including bed 302 and / or components of non-bed peripheral devices) differently based on sensing bedtime during or outside the bedtime range.

[0079] In some examples, control circuitry 334 can automatically determine the bedtime range of user 308 without user input. In some examples, control circuitry 334 can automatically determine the bedtime range of user 308 and combine it with user input. In some examples, control circuitry 334 can directly set the bedtime range based on user input. In some examples, control circuitry 334 can associate different bedtimes with different days of the week. In each of these examples, control circuitry 334 can control one or more components (e.g., lighting system 314, thermostat 316, safety system 318, oven 322, coffee machine 324, lamp 326, and nightlight 328) based on the sensed bedtime status and bedtime range.

[0080] Control circuit 334 can additionally communicate with thermostat 316, receive information from thermostat 316, and generate control signals for controlling the functions of thermostat 316. For example, user 308 can indicate their preference for different temperatures at different times based on their sleep state or bed condition. For example, user 308 may prefer an ambient temperature of 72 degrees Celsius when out of bed, 70 degrees Celsius when in bed but awake, and 68 degrees Celsius when sleeping. Control circuit 334 of bed 302 can detect user 308's bed condition at night and determine that user 308 is sleeping at night. In response to this determination, control circuit 334 can generate a control signal to cause thermostat 316 to change the temperature to 70 degrees Celsius. Control circuit 334 can then transmit the control signal to thermostat 316. When user 308 is detected sleeping or asleep within the bed time range, control circuit 334 can generate and transmit a control signal to cause thermostat 316 to change the temperature to 68 degrees Celsius. The next morning, once it is determined that the user has woken up that day (e.g., user 308 gets out of bed after 6:30 a.m.), the control circuit 334 can generate and transmit a control signal to cause the thermostat to change the temperature to 72 degrees.

[0081] In some implementations, control circuitry 334 may similarly generate control signals to cause one or more heating or cooling elements on the surface of bed 302 to change temperature at different times in response to user interaction with bed 302 or at various pre-programmed times. For example, when user 308 is detected to be asleep, control circuitry 334 may activate a heating element to raise the temperature of one side of the surface of bed 302 to 73 degrees Celsius. As another example, when user 308 is detected to be awake that day, control circuitry 334 may deactivate a heating or cooling element. As yet another example, user 308 may pre-program various times at which the temperature on the surface of the bed should rise or fall. For example, the user may program bed 302 to raise the surface temperature to 76 degrees Celsius at 10:00 PM and lower the surface temperature to 68 degrees Celsius at 11:30 PM.

[0082] In some implementations, in response to detecting that user 308 is in bed and / or is sleeping, control circuitry 334 can cause thermostat 316 to change the temperature in different rooms to different values. For example, in response to determining that user 308 is sleeping at night, control circuitry 334 can generate and transmit control signals to cause thermostat 316 to set the temperature in one or more bedrooms of the house to 72 degrees and the temperature in other rooms to 67 degrees.

[0083] The control circuit 334 can also receive temperature information from the thermostat 316 and use that temperature information to control the functions of the bed 302 or other devices. For example, as described above, the control circuit 334 can adjust the temperature of the heating element included in the bed 302 in response to the temperature information received from the thermostat 316.

[0084] In some implementations, control circuitry 334 may generate and transmit control signals for controlling other temperature control systems. For example, in response to determining that user 308 has woken up that day, control circuitry 334 may generate and transmit a control signal to activate the floor heating element. For example, control circuitry 334 may cause the floor heating system in the master bedroom to turn on in response to determining that user 308 has woken up that day.

[0085] Control circuit 334 may additionally communicate with security system 318, receive information from security system 318, and generate control signals for controlling the functions of security system 318. For example, in response to detecting that user 308 is asleep at night, control circuit 334 may generate control signals to engage or disengage security functions of the security system. Control circuit 334 may then pass the control signals to security system 318 to engage security system 318. As another example, control circuit 334 may generate and pass control signals to disable security system 318 in response to determining that user 308 woke up during the day (e.g., user 308 was no longer present in bed 302 after 6:00 AM). In some embodiments, control circuit 334 may generate and pass a first set of control signals to engage a first set of security features in response to detecting that user 308 is in bed, and may generate and pass a second set of control signals to engage a second set of security features in response to detecting that user 308 is asleep.

[0086] In some implementations, control circuitry 334 may receive an alarm from security system 318 (and / or a cloud service associated with security system 318) and notify user 308 of the alarm. For example, control circuitry 334 may detect that user 308 is sleeping at night and, in response, generate and transmit a control signal to engage or disengage security system 318. Security system 318 may then detect a security breach (e.g., someone has opened door 332 without entering a security code, or someone has opened a window when security system 318 is engaged). Security system 318 may transmit the security breach to control circuitry 334 of bed 302. In response to the communication received from security system 318, control circuitry 334 may generate a control signal to alert user 308 of the security breach. For example, control circuitry 334 may cause bed 302 to vibrate. As another example, control circuitry 334 may cause parts of bed 302 to articulate (e.g., raise or lower the head section) to wake user 308 and alert the user of the security breach. As another example, control circuitry 334 can generate and transmit control signals to cause light 326 to flash at regular intervals to warn user 308 of a security vulnerability. As another example, control circuitry 334 can warn user 308 of bed 302 about a security vulnerability in another bed's bedroom, such as an open window in a child's bedroom. As another example, control circuitry 334 can send a warning to a garage door controller (e.g., to close and lock the door). As another example, control circuitry 334 can send a warning for deactivation of a security system.

[0087] Control circuit 334 may additionally generate and transmit control signals for controlling garage door 320, and receive information indicating the state of garage door 320 (i.e., open or closed). For example, in response to determining that user 308 is sleeping at night, control circuit 334 may generate a request and transmit that request to the garage door opener or another device capable of sensing whether garage door 320 is open. Control circuit 334 may request information about the current state of garage door 320. If control circuit 334 receives a response indicating that garage door 320 is open (e.g., from garage door opener), control circuit 334 may notify user 308 that the garage door is open, or generate a control signal to cause garage door opener to close garage door 320. For example, control circuit 334 may send a message indicating that garage door is open to user equipment 310. As another example, control circuit 334 may cause bed 302 to vibrate. As another example, control circuitry 334 may generate and transmit a control signal to cause lighting system 314 to flash one or more lights in the bedroom to alert user 308 to check a warning on user equipment (in this example, a warning about the garage door 320 being open). Alternatively or additionally, control circuitry 334 may generate and transmit a control signal to cause garage door opener to close garage door 320 in response to recognizing that user 308 is asleep at night and garage door 320 is open. In some embodiments, the control signal may vary according to the age of user 308.

[0088] Control circuitry 334 can similarly send and receive communications for controlling or receiving status information related to door 332 or oven 322. For example, when it is detected that user 308 is sleeping at night, control circuitry 334 can generate a request and transmit the request to the device or system to detect the status of door 332. The information returned in response to the request can indicate various states of door 332 (e.g., open, closed but unlocked, or closed and locked). If door 332 is open or closed but unlocked, control circuitry 334 can warn user 308 of the door status, for example, in the manner described above with reference to garage door 320. Alternatively, or in addition to warning user 308, control circuitry 334 can generate and transmit control signals to lock or close and lock door 332. If door 332 is closed and locked, control circuitry 334 can determine that no further action is required.

[0089] Similarly, when it is detected that user 308 is sleeping at night, control circuit 334 can generate a request and pass the request to oven 322 to request the status of oven 322 (e.g., open or closed). If oven 322 is open, control circuit 334 can alert user 308 and / or generate and pass a control signal to turn oven 322 off. If oven is already off, control circuit 334 can determine that no further action is needed. In some implementations, different alerts can be generated for different events. For example, if security system 318 has detected a breach, control circuit 334 causes light 326 (or one or more other lights via lighting system 314) to flash in a first mode, in a second mode if garage door 320 is open, in a third mode if door 332 is open, in a fourth mode if oven 322 is open, and in a fifth mode if another bed has detected that its user has gotten out of bed (e.g., a sensor in children's bed 302 senses that user 308's child has left bed at midnight). Other examples of warnings that can be processed by the control circuitry 334 of bed 302 and transmitted to the user include: a smoke detector detecting smoke (and transmitting this smoke detection to the control circuitry 334), a carbon monoxide detector detecting carbon monoxide, a heater malfunction, or a warning from any other device capable of communicating with the control circuitry 334 and detecting events that should draw the attention of the user 308.

[0090] The control circuit 334 can also communicate with a system or device for controlling the state of the blinds 330. For example, in response to determining that user 308 is asleep at night, the control circuit 334 can generate and transmit a control signal to close the blinds 330. As another example, in response to determining that user 308 has woken up that day (e.g., the user has left bed after 6:30 a.m.), the control circuit 334 can generate and transmit a control signal to open the blinds 330. Conversely, if user 308 has left bed before user 308's normal wake-up time, the control circuit 334 can determine that user 308 has not woken up that day and will not generate a control signal to open the blinds 330. As yet another example, the control circuit 334 can generate and transmit a control signal to close a first set of blinds in response to detecting that user 308 is in bed, and generate and transmit a control signal to close a second set of blinds in response to detecting that user 308 is asleep.

[0091] Control circuit 334 can generate and transmit control signals for controlling other household appliances in response to detecting interaction between the user and bed 302. For example, in response to determining that user 308 has woken up that day, control circuit 334 can generate a control signal and transmit it to coffee maker 324 to start brewing coffee. As another example, control circuit 334 can generate a control signal and transmit it to oven 322 to start preheating (for users who prefer freshly toasted bread in the morning). As yet another example, control circuit 334 can use information indicating that user 308 has woken up that day, as well as information indicating that it is currently winter and / or the outside temperature is below a threshold, to generate and transmit a control signal to turn on the engine block heater in a car.

[0092] As another example, control circuitry 334 may generate and transmit a control signal to cause one or more devices to enter sleep mode in response to detecting that user 308 is in bed or asleep. For example, control circuitry 334 may generate a control signal to cause user 308's mobile phone to switch to sleep mode. Control circuitry 334 may then transmit the control signal to the mobile phone. Later, upon determining that user 308 has woken up that day, control circuitry 334 may generate and transmit a control signal to cause the mobile phone to switch out of sleep mode.

[0093] In some implementations, control circuitry 334 may communicate with one or more noise control devices. For example, upon determining that user 308 is sleeping at night or is asleep, control circuitry 334 may generate and transmit control signals to activate one or more noise cancellation devices. For instance, the noise cancellation devices may be included as part of bed 302 or located in a bedroom having bed 302. As another example, upon determining that user 308 is sleeping at night or is asleep, control circuitry 334 may generate and transmit control signals to turn the volume of one or more sound generating devices (e.g., stereo radio, computer, tablet, etc.) on, off, increase, or decrease.

[0094] Additionally, the function of bed 302 is controlled by control circuitry 334 in response to user interaction with bed 302. For example, bed 302 may include an adjustable base and a hinge controller configured to adjust the position of one or more portions of bed 302 by adjusting the adjustable base supporting the bed. For example, the hinge controller may adjust bed 302 from a flat position to a position where the head of the mattress is tilted upwards (e.g., to allow the user to sit on the bed and / or watch television). In some embodiments, bed 302 includes multiple separate hingeable sections. For example, portions of the bed corresponding to the positions of air chambers 306a and 306b may be hinged independently to allow one person resting on the surface of bed 302 in a first position (e.g., a flat position) while a second person rests in a second position (e.g., a tilted position where the head is raised at an angle from the waist). In some embodiments, separate positions may be provided for two different beds (e.g., two pairs of beds placed adjacent to each other). The base of bed 302 may include more than one area that can be adjusted independently. The hinge controller can also be configured to provide different levels of massage to one or more users on the bed 302, or to vibrate the bed to send a warning to user 308 as described above.

[0095] Control circuitry 334 can adjust the position of bed 302 in response to interaction between the user and the bed 302 (e.g., the tilt and lowering position of user 308 and / or another user). For example, control circuitry 334 can cause the hinge controller to adjust bed 302 to a first reclined position of user 308 in response to sensing that user 308 is in bed. Control circuitry 334 can cause the hinge controller to adjust bed 302 to a second reclined position (less reclined or flat position) in response to determining that user 308 is sleeping. As another example, control circuitry 334 can receive communication from television 312 indicating that user 308 has turned off television 312, and in response, control circuitry 334 can cause the hinge controller to adjust the position of bed 302 to a preferred user sleeping position (e.g., because user has turned off television 312 while user 308 is in bed indicating that user 308 wants to sleep).

[0096] In some implementations, control circuitry 334 can control the hinge controller to wake one user of bed 302 without waking the other user. For example, user 308 and user 2 of bed 302 can each set different wake-up times (e.g., 6:30 AM and 7:15 AM, respectively). When user 308's wake-up time arrives, control circuitry 334 can cause the hinge controller to vibrate or change the position of only one side of the bed on which user 308 is located to wake user 308 without disturbing the second user. When the second user's wake-up time arrives, control circuitry 334 can cause the hinge controller to vibrate or change the position of only one side of the bed on which the second user is located. Alternatively, when the second wake-up time occurs, control circuitry 334 can use other methods (e.g., an audio alarm or turning on a light) to wake the second user, and since user 308 is already awake, the control circuitry 334 will not be disturbed when attempting to wake the second user.

[0097] Still referencing Figure 3 The control circuit 334 of bed 302 can utilize information from interactions between multiple users and bed 302 to generate control signals for controlling various other devices. For example, control circuit 334 can wait until both user 308 and the second user are detected as being on bed 302 before generating control signals for actions such as engaging safety system 318 or instructing lighting system 314 to turn off lights in various rooms. As another example, control circuit 334 can generate a first set of control signals to turn off lighting system 314 when user 308 is detected as being in bed, and generate a second set of control signals to turn off a second set of lights in response to detecting the second user's presence in bed. As yet another example, control circuit 334 can wait until it has determined that both user 308 and the second user have woken up that day before generating control signals to open blinds 330. As another example, in response to determining that user 308 has left the bed and woken up that day, but the second user is still asleep, control circuit 334 can generate and transmit a first set of control signals to cause coffee machine 324 to start brewing coffee, disable security system 318, turn on light 326, turn off night light 328, cause thermostat 316 to raise the temperature in one or more rooms to 72 degrees Celsius, and open blinds (e.g., blinds 330) in the room (not the bedroom where bed 302 is located). Subsequently, in response to detecting that the second user is no longer in bed (or the second user has woken up), control circuit 334 can generate and transmit a second set of control signals to, for example, cause lighting system 314 to turn on one or more lights in the bedroom, open blinds in the bedroom, and turn on television 312 to a predetermined channel.

[0098] Example of a data processing system associated with a bed

[0099] This section describes examples of systems and components that can be used, for example, for data processing tasks associated with a bed. In some cases, multiple examples of a particular component or group of components are presented. Some of these examples are redundant and / or mutually exclusive alternatives. Connections between components are shown as examples to illustrate possible network configurations for allowing communication between components. Different forms of connections may be used, whether technically necessary or desired. Connections generally refer to logical connections that can be created using any technically feasible form. For example, a network on a motherboard may be created using printed circuit boards, wireless data connections, and / or other types of network connections. For clarity, some logical connections are not shown. For example, connections to power supplies and / or computer-readable storage may not be shown for clarity, as many or all components of a particular component may require connection to power supplies and / or computer-readable storage.

[0100] Figure 4A This is a block diagram of an example of a data processing system 400 that can be associated with a bed system, the bed system including the above-mentioned... Figures 1-3 The system 400 includes a pump motherboard 402 and a pump daughterboard 404. The system 400 includes a sensor array 406, which may include one or more sensors configured to sense physical phenomena of the environment and / or the bed, and to report such sensing back to the pump motherboard 402 for, for example, analysis. The system 400 also includes a controller array 408, which may include one or more controllers configured to control logical control devices of the bed and / or the environment. The pump motherboard 402 can communicate with one or more computing devices 414 and one or more cloud services 410 via a local area network, the Internet 412, or other technically suitable means. Each of these components will be described in more detail below, some with multiple example configurations.

[0101] In this example, pump mainboard 402 and pump subboard 404 are communicatively connected. They can be conceptually described as the center or hub of system 400, while other components are conceptually described as spokes of system 400. In some configurations, this may mean that each spoke component communicates primarily or exclusively with pump mainboard 402. For example, sensors in the sensor array may not be configured or able to communicate directly with their corresponding controllers. Instead, each spoke component can communicate with mainboard 402. Sensors in sensor array 406 can report sensor readings to mainboard 402, and in response, mainboard 402 can determine that controllers in controller array 408 should adjust some parameters of the logically controlled devices or otherwise modify the state of one or more peripheral devices. In one case, if the bed temperature is determined to be overheated, pump mainboard 402 can determine that the temperature controller should cool the bed.

[0102] One advantage of a central and branch network configuration (sometimes referred to as a star network) compared to, for example, a mesh network with dynamic routing is reduced network traffic. If a particular sensor generates a large, continuous flow of traffic, that traffic can be passed to the mainboard 402 through only one branch of the network. The mainboard 402 can, for example, group the data and compress it into a smaller data format for retransmission and storage in the cloud service 410. Alternatively or alternatively, the mainboard 402 can respond to the large flow by generating a single small command message to be sent along different branches of the network. For example, if the large data flow is pressure readings transmitted several times per second from the sensor array 406, the mainboard 402 can respond to the controller array with a single command message to increase the pressure in the air chamber. In this case, the single command message can be orders of magnitude smaller than the pressure reading flow.

[0103] As another advantage, the central and branch network configuration allows for a scalable network that can accommodate components that are being added, removed, or fail. This allows for, for example, more, fewer, or different sensors in sensor array 406, more, fewer, or different controllers in controller array 408, more, fewer, or different computing devices 414, and / or cloud services 410. For example, if a particular sensor fails or is obsolete due to a newer version of the sensor, system 400 can be configured such that only motherboard 402 needs to be updated for the replacement sensor. This allows for, for example, product differentiation, where the same motherboard 402 can support entry-level products with fewer sensors and controllers, higher-value products with more sensors and controllers, and customer personalization, where customers can add components of their own choice to system 400.

[0104] Additionally, a range of airbed products can utilize a system 400 with different components. In applications where each airbed in the product line includes both a central logic unit and a pump, the mainboard 402 (and optionally a subboard 404) can be designed to fit within a single universal housing. Then, for each upgrade of the products in the product line, additional sensors, controllers, cloud services, etc., can be added. Compared to a product line where each product has a custom logic control system, designing all products from this basic design line reduces design, manufacturing, and testing time.

[0105] Each component discussed above can be implemented using various technologies and configurations. Some examples of each component will be discussed further below. In some alternatives, two or more components in system 400 may be implemented as a single alternative component; some components may be implemented as multiple independent components; and / or some functions may be provided by different components.

[0106] Figure 4BThis is a block diagram illustrating some communication paths of the data processing system 400. As previously described, the motherboard 402 and pump board 404 can serve as the hub for peripherals and cloud services of the system 400. In cases where the pump board 404 communicates with cloud services or other components, communication from the pump board 404 can be routed through the pump motherboard 402. This can allow, for example, the bed to have only a single connection to the Internet 412. The computing device 414 may also have a connection to the Internet 412, possibly through the same gateway used by the bed and / or possibly through a different gateway (e.g., a community service provider).

[0107] Previously, several cloud services were described 410. For example... Figure 4B As shown, some cloud services (e.g., cloud services 410d and 410e) can be configured such that the pump motherboard 402 can communicate directly with the cloud service—that is, the motherboard 402 can communicate with cloud service 410 without using another cloud service 410 as an intermediary. Alternatively or alternatively, some cloud services 410 (e.g., cloud service 410f) may only be reached by the pump motherboard 402 through an intermediate cloud service (e.g., cloud service 410e). Although not shown here, some cloud services 410 may be reached directly or indirectly by the pump motherboard 402.

[0108] Furthermore, some or all of the cloud services 410 can be configured to communicate with other cloud services. This communication may include data transfer and / or remote function calls in any technically suitable format. For example, a cloud service 410 may request a copy of data from another cloud service 410, for example, to back up, coordinate, migrate, or to perform computations or data mining. In another example, many cloud services 410 may contain data indexed based on specific users tracked by user account cloud 410c and / or bed data cloud 410a. When accessing data specific to a user or bed, these cloud services 410 may communicate with user account cloud 410c and / or bed data cloud 410a.

[0109] Figure 5 This is a block diagram of an example motherboard 402 that can be used in a data processing system associated with a bed system, the bed system including the components described above. Figures 1-3 Those described. In this example, compared to the other examples described below, the motherboard 402 consists of relatively few components and can be limited to providing a relatively limited set of features.

[0110] The motherboard includes a power supply 500, a processor 502, and computer memory 512. Typically, a power supply includes hardware for receiving power from an external source and supplying it to the motherboard 402. The power supply may include, for example, battery packs and / or wall socket adapters, AC-to-DC converters, DC-to-AC converters, power regulators, capacitor banks, and / or one or more interfaces for providing power of current type, voltage, etc., as required by other components of the motherboard 402.

[0111] Processor 502 is typically a device used to receive input, perform logical determinations, and provide output. Processor 502 may be a central processing unit, a microprocessor, general-purpose logic circuitry, application-specific integrated circuits (ASICs), combinations thereof, and / or other hardware used to perform the required functions.

[0112] Memory 512 is typically one or more devices used for storing data. Memory 512 may include long-term stable data storage (e.g., on a hard disk), short-term unstable data storage (e.g., on random access memory), or any other technically suitable configuration.

[0113] Mainboard 402 includes pump controller 504 and pump motor 506. Pump controller 504 can receive commands from processor 502 and, in response, control the function of pump motor 506. For example, pump controller 504 can receive a command from processor 502 to increase the pressure in an air chamber by 0.3 psi (PSI). In response, pump controller 504 engages a valve, configuring pump motor 506 to pump air into a selected air chamber, and can engage pump motor 506 for a time corresponding to 0.3 PSI, or until a sensor indicates that the pressure has increased by 0.3 PSI. In an alternative configuration, the message can specify that the chamber should be inflated to a target PSI, and pump controller 504 can engage pump motor 506 until the target PSI is reached.

[0114] The valve solenoid 508 can control the air chamber to which the pump is connected. In some cases, solenoid 508 can be directly controlled by processor 502. In other cases, solenoid 508 can be controlled by pump controller 504.

[0115] The remote interface 510 of the motherboard 402 allows the motherboard 402 to communicate with other components of the data processing system. For example, the motherboard 402 can communicate with one or more daughterboards, peripheral sensors, and / or peripheral controllers via the remote interface 510. The remote interface 510 can provide any technically suitable communication interface, including but not limited to multiple communication interfaces such as WiFi, Bluetooth, and copper wired networks.

[0116] Figure 6This is a block diagram of an example motherboard 402 that can be used in a data processing system associated with a bed system, the bed system including the components described above. Figures 1-3 Those described. (Referencing) Figure 5 Compared to the described motherboard 402, Figure 6 The motherboard in the middle can contain more components and provide more functions in some applications.

[0117] In addition to the power supply 500, processor 502, pump controller 504, pump motor 506, and valve solenoid 508, the motherboard 402 is shown to have a valve controller 600, pressure sensor 602, universal serial bus (USB) stack 604, WiFi radio 606, Bluetooth Low Energy (BLE) radio 608, ZigBee radio 610, Bluetooth radio 612, and computer memory 512.

[0118] Similar to how pump controller 504 translates commands from processor 502 into control signals for pump motor 506, valve controller 600 can translate commands from processor 502 into control signals for valve solenoid 508. In one example, processor 502 can command valve controller 600 to connect the pump to a specific air chamber in a group of air chambers in the air bed. Valve controller 600 can control the position of valve solenoid 508 such that the pump is connected to the indicated air chamber.

[0119] Pressure sensor 602 can read readings from one or more air chambers of the air bed. Pressure sensor 602 can also perform digital sensor regulation.

[0120] Motherboard 402 may include a set of network interfaces, including but not limited to those shown herein. These network interfaces may allow the motherboard to communicate with any number of devices (including but not limited to peripheral sensors, peripheral controllers, computing devices, and devices and services connected to the Internet 412) via wired or wireless networks.

[0121] Figure 7 This is a block diagram of an example of a daughterboard 404 that can be used in a data processing system associated with a bed system, the bed system comprising the components described above. Figures 1-3The descriptions are as follows. In some configurations, one or more daughterboards 404 may be connected to the motherboard 402. Some daughterboards 404 may be designed to offload specific and / or partitioned tasks from the motherboard 402. This may be advantageous, for example, if the specific task is computationally intensive, proprietary, or subject to future revisions. For instance, a daughterboard 404 may be used to compute a specific sleep data metric. This metric may be computationally intensive, and computing the sleep metric on a daughterboard 404 can free up resources on the motherboard 402 while the metric is being computed. Additionally and / or alternatively, the sleep metric may be subject to future revisions. To update the system 400 with a new sleep metric, it may only be necessary to replace the daughterboard 404 that computes the metric. In this case, the same motherboard 402 and other components can be used, thus saving the need to perform unit tests on additional components, instead of performing unit tests only on the daughterboard 404.

[0122] The daughterboard 404 is shown having a power supply 700, a processor 702, a computer-readable storage 704, a pressure sensor 706, and a WiFi radio 708. The processor can use the pressure sensor 706 to collect information about the pressure in one or more air chambers of the air bed. From this data, the processor 702 can execute algorithms to calculate sleep metrics. In some examples, sleep metrics can be calculated solely from the pressure of the air chambers. In other examples, sleep metrics can be calculated from one or more other sensors. In examples requiring different data, the processor 702 can receive the data from one or more appropriate sensors. These sensors may be internal to the daughterboard 404, accessible via the WiFi radio 708, or otherwise communicate with the processor 702. Once the sleep metrics are calculated, the processor 702 can report the sleep metrics to, for example, the motherboard 402.

[0123] Figure 8 This is a block diagram of an example of a motherboard 800 without a daughterboard that can be used in a data processing system associated with a bed system, the bed system including the components described above. Figures 1-3 Those described. In this example, motherboard 800 can perform the reference... Figure 6 The motherboard 402 and Figure 7 The sub-board 404 describes most, all, or more of the features.

[0124] Figure 9 This is a block diagram of an example sensor array 406 that can be used in a data processing system associated with a bed system, the bed system including the above-mentioned sensor array 406. Figures 1-3 Those described. Typically, sensor array 406 is a conceptual grouping of some or all peripheral sensors that communicate with motherboard 402 but are not local to motherboard 402.

[0125] Peripheral sensors of sensor array 406 can communicate with motherboard 402 via one or more network interfaces on the motherboard. These network interfaces include, but are not limited to, USB stack 1112, WiFi radio 606, Bluetooth Low Energy (BLE) radio 608, ZigBee radio 610, and Bluetooth radio 612, depending on the specific sensor configuration. For example, a sensor that outputs readings via a USB cable can communicate via USB stack 1112.

[0126] Some of the peripheral sensors 900 in sensor array 406 may be bed-mounted sensors 900. These sensors may, for example, be embedded in the bed structure and sold with the bed, or subsequently fixed to the bed structure. Other peripheral sensors 902 and 904 may communicate with motherboard 402, but optionally are not mounted to the bed. In some cases, some or all of the bed-mounted sensors 900 and / or peripheral sensors 902 and 904 may share networking hardware, including conduits, multi-wire cables, or plugs containing wires from each sensor, connecting all associated sensors to motherboard 402 when attached. In some embodiments, one, some, or all of sensors 902, 904, 906, 908, and 910 may sense one or more features of the mattress, such as pressure, temperature, light, sound, and / or one or more other features of the mattress. In some embodiments, one, some, or all of sensors 902, 904, 906, 908, and 910 may sense one or more features outside the mattress. In some embodiments, pressure sensor 902 can sense the pressure of the mattress, while some or all of sensors 902, 904, 906, 908 and 910 can sense one or more features of the mattress and / or the exterior of the mattress.

[0127] Figure 10 This is a block diagram of an example controller array 408 that can be used in a data processing system associated with a bed system, the bed system including the above-mentioned... Figures 1-3 Those described. Typically, the controller array 408 is a conceptual grouping of some or all peripheral controllers that communicate with the motherboard 402 but are not local to the motherboard 402.

[0128] Peripheral controllers of controller array 408 can communicate with motherboard 402 via one or more network interfaces, including but not limited to USB stack 1112, WiFi radio 1114, Bluetooth Low Energy (BLE) radio 1116, ZigBee radio 610, and Bluetooth radio 612, depending on the configuration of a specific sensor. For example, a controller receiving commands via a USB cable can communicate via USB stack 1112.

[0129] Some of the controllers in controller array 408 may be bed-mounted controllers 1000, including but not limited to temperature controller 1006, light controller 1008, and / or speaker controller 1010. These controllers may, for example, be embedded in the bed structure and sold with the bed, or subsequently fixed to the bed structure. Other peripheral controllers 1002 and 1004 may communicate with motherboard 402, but are optionally not mounted to the bed. In some cases, some or all of the bed-mounted controllers 1000 and / or peripheral controllers 1002 and 1004 may share networking hardware, including conduits, multi-wire cables, or plugs containing wires from each controller, connecting all associated controllers to motherboard 402 when attached.

[0130] Figure 11 This is a block diagram of an example of a computing device 414 that can be used in a data processing system associated with a bed system, the bed system including the components described above. Figures 1-3 The computing device 414 may include, for example, a computing device used by a user in a bed. Example computing devices 414 include, but are not limited to, mobile computing devices (e.g., mobile phones, tablets, laptops) and desktop computers.

[0131] The computing device 414 includes a power supply 1100, a processor 1102, and a computer-readable storage 1104. User input and output can be transmitted via, for example, a speaker 1106, a touchscreen 1108, or other components not shown (e.g., a pointing device or a keyboard). The computing device 414 can run one or more applications 1110. These applications may include, for example, applications that allow users to interact with the system 400. These applications may allow users to view information about the bed (e.g., sensor readings, sleep metrics) or configure the characteristics of the system 400 (e.g., setting desired firmness for the bed, setting desired characteristics for peripheral devices). In some cases, the computing device 414 may be used in addition to or in place of the previously described remote controller 122.

[0132] Figure 12 This is a block diagram of an example of a bed data cloud service 410a that can be used in a data processing system associated with a bed system, the bed system including the above-mentioned... Figures 1-3 Those described. In this example, the bed data cloud service 410a is configured to collect sensor data and sleep data from a specific bed, and when generating sensor data and sleep data, match the sensor data and sleep data with one or more users using the bed.

[0133] The bed data cloud service 410a is shown to have a network interface 1200, a communication manager 1202, server hardware 1204, and server system software 1206. Furthermore, the bed data cloud service 410a is shown to have a user identification module 1208, a device management module 1210, a sensor data module 1212, and an advanced sleep data module 1214.

[0134] Network interface 1200 typically includes hardware and low-level software for allowing one or more hardware devices to communicate over a network. For example, network interface 1200 may include network cards, routers, modems, and other hardware required to allow components of bed data cloud service 410a to communicate with each other and other targets via, for example, the Internet 412. Communication manager 1202 typically includes hardware and software that operate on network interface 1200. This includes software for initiating, maintaining, and dismantling network communications used by bed data cloud service 410a. For example, this includes TCP / IP, SSL or TLS, Torrent, and other communication sessions over a local area network or wide area network. Communication manager 1202 may also provide load balancing and other services to other components of bed data cloud service 410a.

[0135] Server hardware 1204 typically includes physical processing equipment for instantiating and maintaining the bed data cloud service 410a. This hardware includes, but is not limited to, processors (e.g., central processing units, ASICs, graphics processors) and computer-readable storage (e.g., random access memory, stable hard disks, tape backups). One or more servers can be configured as a geographically separated or connected cluster, multi-computer, or data center.

[0136] Server system software 1206 typically includes software that runs on server hardware 1204 to provide an operating environment for applications and services. Server system software 1206 may include an operating system running on a physical server, virtual machines instantiated on a physical server to create numerous virtual servers, and server-level operations such as data migration, redundancy, and backup.

[0137] User identification 1208 may include or reference data related to users of the bed with an associated data processing system. For example, users may include customers, owners, or other users registered with the bed data cloud service 410a or another service. Each user may have, for example, a unique identifier, user credentials, contact information, billing information, demographic information, or any other technically appropriate information.

[0138] Device Manager 1210 may include or reference data related to the bed or other products associated with the data processing system. For example, a bed may include products registered or sold to a system associated with Bed Data Cloud Service 410a. Each bed may have, for example, a unique identifier, model and / or serial number, sales information, geographic information, delivery information, a list of associated sensors and control peripherals, etc. Additionally, one or more indexes stored by Bed Data Cloud Service 410a may identify users associated with the bed. For example, the index may record bed sales to users, users sleeping on the bed, etc.

[0139] Sensor data 1212 can record raw or compressed sensor data recorded by a bed with an associated data processing system. For example, the bed's data processing system may include temperature sensors, pressure sensors, and light sensors. Readings from the sensors, either in their raw form or in a format generated from raw data from the sensors (e.g., sleep metrics), can be transmitted by the bed's data processing system to a bed data cloud service 410a for storage in sensor data 1212. Additionally, one or more indexes stored by the bed data cloud service 410a can identify the user and / or bed associated with sensor data 1212.

[0140] The bed data cloud service 410a can use any available data to generate advanced sleep data 1214. Typically, advanced sleep data 1214 includes sleep metrics and other data generated from sensor readings. For example, some of these calculations can be performed within the bed data cloud service 410a rather than locally on the bed's data processing system, because the calculations are computationally complex or require significant memory space or processor power unavailable on the bed's data processing system. This can help allow the bed system to operate with a relatively simple controller while still remaining part of a system performing relatively complex tasks and calculations.

[0141] Figure 13 This is a block diagram of an example of a sleep data cloud service 410b that can be used in a data processing system associated with a bed system, the bed system including the above-mentioned... Figures 1-3 Those described. In this example, the sleep data cloud service 410b is configured to record data related to a user's sleep experience.

[0142] The sleep data cloud service 410b is shown to have a network interface 1300, a communication manager 1302, server hardware 1304, and server system software 1306. Furthermore, the sleep data cloud service 410b is shown to have a user identification module 1308, a pressure sensor manager 1310, a pressure-based sleep data module 1312, a raw pressure sensor data module 1314, and a non-pressure sleep data module 1316.

[0143] The pressure sensor manager 1310 may include or reference data related to the configuration and operation of pressure sensors in the bed. For example, this data may include identifiers of the types of sensors in a particular bed, their settings, calibration data, etc.

[0144] Pressure-based sleep data 1312 can use raw pressure sensor data 1314 to calculate sleep metrics associated with the pressure sensor data. For example, user presence, movement, weight change, heart rate, and respiratory rate can all be determined from the raw pressure sensor data 1314. Additionally, one or more indexes stored by the sleep data cloud service 410b can identify users associated with pressure sensors, raw pressure sensor data, and / or pressure-based sleep data.

[0145] Non-stress sleep data 1316 can use other data sources to calculate sleep metrics. For example, user-inputted preferences, light sensor readings, and sound sensor readings can all be used to track sleep data. Additionally, one or more indexes stored by the sleep data cloud service 410b can identify users associated with other sensors and / or non-stress sleep data 1316.

[0146] Figure 14 This is a block diagram of an example user account cloud service 410c that can be used in a data processing system associated with a bed system. The bed system includes the features described above. Figures 1-3 Those described. In this example, the User Accounts Cloud Service 410c is configured to record a list of users and identify other data associated with those users.

[0147] The user account cloud service 410c is shown to have a network interface 1400, a communication manager 1402, server hardware 1404, and server system software 1406. Furthermore, the user account cloud service 410c is shown to have a user identification module 1408, a purchase history module 1410, an engagement module 1412, and an application usage history module 1414.

[0148] User identification module 1408 may include or reference user-related data associated with the bed having an associated data processing system. For example, users may include customers, owners, or other users who have registered with user account cloud service 410a or another service. Each user may have, for example, a unique identifier and user credentials, demographic information, or any other technically appropriate information.

[0149] The purchase history module 1410 may include or reference data related to user purchases. For example, purchase data may include sales contact information, billing information, and sales personnel information. Additionally, one or more indexes stored by the user account cloud service 410c may identify users associated with purchased items.

[0150] The Join 1412 can track users and / or managers of bed or cloud services who interact with manufacturers, suppliers, and other stakeholders. This Join data may include communications (e.g., emails, service calls), data from sales (e.g., sales receipts, configuration logs), and social network interactions.

[0151] The usage history module 1414 can contain data about user interactions with one or more applications and / or remote controllers. For example, a monitoring and configuration application can be distributed to run on, for example, computing device 412. This application can log and report user interactions stored in the application usage history module 1414. Additionally, one or more indexes stored by the user account cloud service 410c can identify the user associated with each log entry.

[0152] Figure 15 This is a block diagram of an example point-of-sale cloud service 1500 that can be used in a data processing system associated with a bed system. The bed system includes the components mentioned above. Figures 1-3 Those described. In this example, the Point of Sale Cloud Service 1500 is configured to record data related to a user's purchases.

[0153] The point-of-sale cloud service 1500 is shown to have a network interface 1502, a communication manager 1504, server hardware 1506, and server system software 1508. Furthermore, the point-of-sale cloud service 1500 is shown to have a user identification module 1510, a purchase history module 1512, and a settings module 1514.

[0154] The purchase history module 1512 may include or reference purchase-related data from the user identified in the user identification module 1510. Purchase information may include, for example, sales data, price and location of sale, delivery address, and configuration options selected by the user at the time of sale. These configuration options may include choices made by the user regarding how they wish their newly purchased bed to be set up, and may include, for example, the expected sleep schedule, a list of peripheral sensors and controllers that they have already installed or will install.

[0155] The bed setup module 1514 may include or reference data related to the installation of the bed purchased by the user. Bed setup data may include, for example, the date and address of bed delivery, the person receiving the delivery, the configuration applied to the bed at the time of delivery, the names of one or more people who will sleep in the bed, and which side of the bed each person will use, etc.

[0156] Data recorded in the point-of-sale cloud service 1500 can be referenced by the user's bed system at a later date to control the bed system's functions and / or send control signals to peripheral components based on the data recorded in the point-of-sale cloud service 1500. This allows sales personnel to collect information from users at the point of sale, which subsequently facilitates the automation of the bed system. In some examples, some or all aspects of the bed system can be automated with little or no user input required after the point of sale. In other examples, the data recorded in the point-of-sale cloud service 1500 can be used in conjunction with various supplementary data collected from user input.

[0157] Figure 16 This is a block diagram of a sample environment cloud service 1600 that can be used in a data processing system associated with a bed system. The bed system includes the components mentioned above. Figures 1-3 Those described. In this example, the Environmental Cloud Service 1600 is configured to record data related to the user's home environment.

[0158] The environmental cloud service 1600 is shown to have a network interface 1602, a communication manager 1604, server hardware 1606, and server system software 1608. Furthermore, the environmental cloud service 1600 is shown to have a user identification module 1610, an environmental sensor module 1612, and an environmental factors module 1614.

[0159] The environmental sensor module 1612 may include a list of sensors that the user has already installed on their bed in the user identification module 1610. These sensors include any sensors that can detect environmental variables—light sensors, noise sensors, vibration sensors, thermostats, etc. Additionally, the environmental sensor module 1612 may store historical readings or reports from those sensors.

[0160] The environmental factors module 1614 may include reports generated based on data from the environmental sensor module 1612. For example, for a user with light sensor data in the environmental sensor module 1612, the environmental factors module 1614 may maintain a report indicating the frequency and duration of instances of increased lighting when the user is asleep.

[0161] In the examples discussed herein, each cloud service 410 is shown to have some of the same components. In various configurations, these same components may be shared partially or completely between services, or they may be separate. In some configurations, each service may have separate copies of some or all of the components that are the same or different in some respects. Furthermore, these components are provided merely as illustrative examples. In other examples, each cloud service may have a technically possible number, type, and style of components.

[0162] Figure 17 This is a block diagram illustrating an example of using a data processing system that can be associated with a bed (e.g., the bed in the bed system described herein) to automate peripheral devices around the bed. Shown here is a behavior analysis module 1700 running on a pump motherboard 402. For example, the behavior analysis module 1700 may be one or more software components stored in computer memory 512 and executed by processor 502. Typically, the behavior analysis module 1700 may collect data from various sources (e.g., sensors, non-sensor local sources, cloud data services) and use behavior algorithms 1702 to generate one or more actions to be taken (e.g., sending commands to peripheral controllers, sending data to cloud services). This could be useful, for example, in tracking user behavior and automating communication with the user's bed.

[0163] The behavior analysis module 1700 can collect data from any technically suitable source, such as data about the characteristics of the bed, the environment of the bed, and / or the user of the bed. Some such sources include any of the sensors in the sensor array 406. For example, this data can provide the behavior analysis module 1700 with information about the current state of the environment surrounding the bed. For example, the behavior analysis module 1700 can access readings from the pressure sensor 902 to determine the pressure in the air chamber of the bed. From this reading, and potentially other data, the presence of a user in the bed can be determined. In another example, the behavior analysis module can access the light sensor 908 to detect the amount of light in the environment of the bed.

[0164] Similarly, the behavior analytics module 1700 can access data from cloud services. For example, the behavior analytics module 1700 can access bed cloud service 410a to access historical sensor data 1212 and / or advanced sleep data 1214. Other cloud services 410 (including those not previously described) can be accessed by the behavior analytics module 1700. For example, the behavior analytics module 1700 can access weather reporting services, third-party data providers (e.g., traffic and news data, emergency broadcast data, user travel data), and / or clock and calendar services.

[0165] Similarly, the behavior analysis module 1700 can access data from non-sensor sources 1704. For example, the behavior analysis module 1700 can access local clock and calendar services (e.g., components of processor 502 or motherboard 402).

[0166] The behavior analysis module 1700 can aggregate and prepare the data for use by one or more behavior algorithms 1702. Behavior algorithms 1702 can be used to learn user behavior and / or perform actions based on the state and / or predicted user behavior of the accessed data. For example, behavior algorithm 1702 can use available data (e.g., pressure sensor data, non-sensor data, clock and calendar data) to create a model of when the user goes to sleep each night. Subsequently, the same or different behavior algorithms 1702 can be used to determine whether an increase in air chamber pressure is likely to instruct the user to go to bed, and if so, send some data to a third-party cloud service 410 and / or engaging devices such as pump controller 504, base actuator 1706, temperature controller 1008, under-bed lighting 1011, peripheral controller 1002, or peripheral controller 1004, to name just a few.

[0167] In the example shown, behavior analysis module 1700 and behavior algorithm 1702 are depicted as components of motherboard 402. However, other configurations are possible. For example, the same or similar behavior analysis module and / or behavior algorithm may run in one or more cloud services, and the resulting output may be sent to motherboard 402, a controller in controller array 408, or any other technically suitable receiver.

[0168] Figure 18 Examples of computing devices 1800 and mobile computing devices that can be used to implement the techniques described herein are shown. Computing device 1800 is intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. Mobile computing devices are intended to represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the embodiments of the invention described and / or claimed in this document.

[0169] Computing device 1800 includes a processor 1802, a memory 1804, a storage device 1806, a high-speed interface 1808 connected to the memory 1804 and a plurality of high-speed expansion ports 1810, and a low-speed interface 1812 connected to a low-speed expansion port 1814 and the storage device 1806. Each of the processor 1802, memory 1804, storage device 1806, high-speed interface 1808, high-speed expansion port 1810, and low-speed interface 1812 is interconnected using various buses and can be mounted on a common motherboard or otherwise suitable. Processor 1802 can process instructions for execution within computing device 1800, including instructions stored in memory 1804 or storage device 1806, to display graphical information of a GUI on an external input / output device (e.g., a display 1816 coupled to high-speed interface 1808). In other embodiments, multiple processors and / or multiple buses, as well as multiple memories and memory types, may be suitably used. Additionally, multiple computing devices can be connected, each providing a portion of the necessary operation (e.g., as a server group, blade server group, or multiprocessor system).

[0170] The memory 1804 stores information within the computing device 1800. In some embodiments, the memory 1804 is a volatile memory cell. In some embodiments, the memory 1804 is a non-volatile memory cell. The memory 1804 may also be another form of computer-readable medium, such as a magnetic disk or optical disk.

[0171] Storage device 1806 provides large-capacity storage for computing device 1800. In some embodiments, storage device 1806 may be a computer-readable medium or contain computer-readable media, such as a floppy disk device, hard disk device, optical disk device, magnetic tape device, flash memory or other similar solid-state storage device, or an array of devices including devices in a storage area network or other configurations. A computer program product may be embodied in an information carrier. The computer program product may also contain instructions that, when executed, perform one or more methods (e.g., the methods described above). The computer program product may also be embodied in a computer or machine-readable medium, such as memory 1804, storage device 1806, or memory on processor 1802.

[0172] High-speed interface 1808 manages bandwidth-intensive operations of computing device 1800, while low-speed interface 1812 manages less bandwidth-intensive operations. This functional allocation is merely exemplary. In some embodiments, high-speed interface 1808 is coupled to memory 1804, display 1816 (e.g., via a graphics processor or accelerator), and high-speed expansion port 1810, which can accept various expansion cards (not shown). In some embodiments, low-speed interface 1812 is coupled to storage device 1806 and low-speed expansion port 1814. Low-speed expansion port 1814, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, Wireless Ethernet), may be coupled to one or more input / output devices, such as a keyboard, pointing device, scanner, or, for example, via a network adapter, to network devices such as a switch or router.

[0173] As shown in the figure, computing device 1800 can be implemented in a variety of different forms. For example, it can be implemented as a standard server 1820, or multiple times in a group of such servers. Furthermore, it can be implemented in a personal computer such as a laptop computer 1822. It can also be implemented as part of a rack server system 1824. Alternatively, components of computing device 1800 can be combined with other components in mobile devices (not shown) (e.g., mobile computing device 1850). Each of these devices can contain one or more of computing device 1800 and mobile computing device 1850, and the entire system can consist of multiple computing devices communicating with each other.

[0174] Mobile computing device 1850 includes a processor 1852, memory 1864, input / output devices such as a display 1854, a communication interface 1866, a transceiver 1868, and other components. Mobile computing device 1850 may also include storage devices, such as microdrives or other devices, to provide additional storage. Each of the processor 1852, memory 1864, display 1854, communication interface 1866, and transceiver 1868 is interconnected using various buses, and the components may be mounted on a common motherboard or otherwise suitably mounted.

[0175] Processor 1852 can execute instructions within mobile computing device 1850, including instructions stored in memory 1864. Processor 1852 can be implemented as a chipset including individual and multiple analog and digital processors. Processor 1852 can provide, for example, coordination of other components of mobile computing device 1850, such as control of user interface, applications running by mobile computing device 1850, and wireless communications performed by mobile computing device 1850.

[0176] Processor 1852 can communicate with the user via control interface 1858 and display interface 1856 coupled to display 1854. Display 1854 can be, for example, a TFT (Thin Film Transistor Liquid Crystal Display) or OLED (Organic Light Emitting Diode) display or other suitable display technology. Display interface 1856 can include suitable circuitry for driving display 1854 to present graphics and other information to the user. Control interface 1858 can receive commands from the user and translate them for submission to processor 1852. Furthermore, external interface 1862 can provide communication with processor 1852 to enable near-field communication between mobile computing device 1850 and other devices. External interface 1862 can provide, in some embodiments, wired communication, or in others, wireless communication, and multiple interfaces can be used.

[0177] Memory 1864 stores information within mobile computing device 1850. Memory 1864 can be implemented as one or more computer-readable media, volatile memory cells, or non-volatile memory cells. Extended memory 1874 can also be provided and connected to mobile computing device 1850 via an extended interface 1872, which may include, for example, a SIMM (Single In-line Memory Module) card interface. Extended memory 1874 can provide additional storage space for mobile computing device 1850, or it may store applications or other information for mobile computing device 1850. Specifically, extended memory 1874 may include instructions for performing or supplementing the above-described processes, and may also include security information. Therefore, for example, extended memory 1874 can be provided as a security module for mobile computing device 1850 and can be programmed with instructions that allow secure use of mobile computing device 1850. Furthermore, secure applications and additional information, such as placing identification information on the SIMM card in a non-attackable manner, can be provided via a SIMM card.

[0178] The memory may include, for example, flash memory and / or NVRAM (non-volatile random access memory), as described below. In some embodiments, the computer program product may be embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods (e.g., the methods described above). The computer program product may be a computer or machine-readable medium, such as memory 1864, extended memory 1874, or memory on processor 1852. In some embodiments, the computer program product may be received in a propagated signal, for example, via transceiver 1868 or external interface 1862.

[0179] Mobile computing device 1850 can communicate wirelessly via communication interface 1866, which may include digital signal processing circuitry if necessary. Communication interface 1866 can provide communication under various modes or protocols, such as GSM voice calls (Global System for Mobile Communications), SMS (Short Message Service), EMS (Enhanced Messaging Service) or MMS messages (Multimedia Messaging Service), CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access), PDC (Personal Digital Cellular), WCDMA (Wideband Code Division Multiple Access), CDMA2000, or GPRS (General Packet Radio Service). This communication can occur, for example, using a radio frequency transceiver 1868. Furthermore, short-range communication can occur, for example, using Bluetooth, WiFi, or other transceivers (not shown). Additionally, GPS (Global Positioning System) receiver module 1870 can provide additional navigation and location-related wireless data to mobile computing device 1850, which can be appropriately used by applications running on mobile computing device 1850.

[0180] The mobile computing device 1850 can also communicate audibly using an audio codec 1860, which can receive voice information from a user and convert it into usable digital information. The audio codec 1860 can also generate audible sound for the user, for example, through a speaker (e.g., in the handset of the mobile computing device 1850). Such sound can include sounds from voice telephone calls, recorded sounds (e.g., voice messages, music files, etc.), and sounds generated by applications operating on the mobile computing device 1850.

[0181] As shown in the figure, the mobile computing device 1850 can be implemented in a variety of different forms. For example, it can be implemented as a cellular phone 1880. It can also be implemented as part of a smartphone 1882, a personal digital assistant, or other similar mobile devices.

[0182] Various implementations of the systems and techniques described herein can be implemented in digital electronic circuits, integrated circuits, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementations in one or more computer programs executable and / or interpretable on a programmable system, which includes at least one programmable processor, which may be specialized or general-purpose, coupled to receive data and instructions from a storage system, at least one input device, and at least one output device, and to transmit data and instructions to the storage system, at least one input device, and at least one output device.

[0183] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in high-level procedural and / or object-oriented programming languages ​​and / or in assembly / machine language. As used herein, the terms machine-readable medium and computer-readable medium refer to any computer program product, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term machine-readable signal refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0184] To provide interaction with the user, the systems and techniques described herein can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user) and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including sound, speech, or tactile input.

[0185] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or middleware components (e.g., an application server), or front-end components (e.g., a client computer with a graphical user interface or a web browser through which a user can interact with embodiments of the systems and techniques described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0186] A computing system may include clients and servers. Clients and servers are typically geographically separated and usually interact through a communication network. The relationship between clients and servers is established by computer programs running on the respective computers and having a client-server relationship with each other.

[0187] Figure 19This is a swimlane diagram of an example process 1900 for sensing user status and engaging the machine based on that status. For clarity, process 1900 is described with reference to components of data processing system 400. However, the same or similar process can be performed using one or more other systems. For example, a different processor on a remote web server, rather than a processor physically located on or in a bed, could be used for 1906.

[0188] Pressure sensor 602 can generate pressure data 1902. For example, pressure sensor 602 can sense the air pressure within one or more airbags of the bed. If a user lies on the bed with the airbags sealed, the user can apply a force to the airbags as the airbags support the user, increasing the air pressure inside the airbags. Pressure sensor 602 can sense this increased air pressure. When this occurs, pressure sensor 602 can generate a data stream of pressure values ​​based on the pressure of the airbags. Pressure sensor 602 can transmit the data stream to processor 502.

[0189] Peripheral sensor 902 can generate peripheral data 1904. Peripheral sensor 902 can be positioned in the user's environment to sense natural phenomena that can be used to determine the user's state. For example, if peripheral sensor 902 is a smartwatch and / or activity tracker, sensor 902 can sense the user's biometrics, such as heartbeats, breathing movements, body movements, etc. If peripheral sensor 902 is a lighting sensor, sensor 902 can sense a lit room at night, indicating that the user may be in a lit room. When this occurs, peripheral sensor 902 can generate a data stream of sensed values ​​based on the sensed phenomenon. Pressure sensor 602 can transmit the data stream to processor 502.

[0190] Processor 502 can determine user state 1906. For example, the processor can use data streams from pressure sensor 602 and / or peripheral sensors 902 to identify one or more aspects of one or more users. This can include the number of users, the user's position relative to the bed (e.g., in bed, not in bed), the user's sleep state (e.g., awake, asleep, in deep sleep, awake, awake in bed), the user's biometrics (e.g., heart rate, respiratory rate, body temperature, activity level), and other information about the user. Processor 502 can make this information available to user interface device 1902. For example, processor 502 can send messages directly to user interface device 1902 and store the information locally or remotely in a location accessible to user interface device 1902, etc.

[0191] User interface device 1902 selects a user interface and / or peripheral actions 1908. User interface device 1902 is a device capable of receiving and / or transmitting data and capable of presenting a user interface. The format of the user interface can depend on the physical capabilities of the interface device 1902. For example, a laptop, tablet, or telephone may have a screen that displays the user interface in the form of a graphical user interface (GUI). These user interfaces may also include audio, haptic (vibration), or other elements. In some examples, user interface device 1902 may be a home automation device that can display the user interface in the form of an audible interface. For example, a home automation hub may receive input in the form of user voice commands and display output in the form of audio computer speech. As will be recognized, other forms of user interfaces are possible.

[0192] Based on the determined user state, the user interface device selects at least one user interface and / or at least one peripheral action from a pool of possible user interfaces and / or possible peripheral actions. Some example selections will be described later in this document.

[0193] User interface device 1902 displays user interface 1910. For example, the user interface device may present a GUI selected 1908 by user interface device 1902 on a screen. The user interface device may emit an audible interface selected 1908 by user interface device 1902 from a speaker. Peripheral controller 1002 engages peripheral device 1912. For example, the peripheral controller may issue commands requested by user interface device 1902 (e.g., increase lighting, change room temperature).

[0194] Figures 20-22 This is a flowchart of an example process for sensing a user's state and engaging the machine based on that state. For example, these processes can be used in conjunction with a user interface device 1902 to select a user interface and / or peripheral action 1908.

[0195] In process 2000, the user interface is selected based on the bed-being situation. For example, process 2000 may be used to allow the user interface device 1902 to present a user interface GUI (e.g., pressure adjustment, height adjustment) for bed control when the user is in bed and may be interested in increasing their comfort in bed. However, when the user is not in bed, they are less likely to be interested in adjusting the bed and more interested in obtaining measurements of their sleep quality, duration, etc., from previous nights. Therefore, when the user is not in bed, the user interface device 1902 may provide the user with a sleep data GUI.

[0196] Determining the user's in-bed status 2002. For example, processor 502 may collect sensor data (e.g., from pressure sensors and / or one or more peripheral sensors 902) and use that sensor data to determine whether the user of user interface device 1902 is in bed. This may include, for example, applying time series of pressure data to an presence classifier that generates an in-bed / out-of-bed classification, but other processes for determining the in-bed status are also possible.

[0197] If the user is in bed 2004, the bed control user interface 2006 is displayed. For example, if the user is in their bed and accesses an application related to their bed using their phone (i.e., user interface device 1902), the application can be launched directly into the user interface GUI containing user interface elements to adjust the bed. These interface elements may include buttons, sliders, or other elements that, when manipulated, cause the bed to change pressure, hinge the base, engage heating or cooling elements, etc.

[0198] If the user is not in bed 2004, the sleep data user interface 2008 is displayed. For example, if the user is not in their bed and accesses a bed-related application using their phone (i.e., user interface device 1902), the application can be launched directly into the user interface GUI, which contains user interface elements that display the user's historical sleep data. Interface elements may include labels, graphics, and animations that display data (raw or aggregated data) collected from the user's previous sleep sessions. This may include sleep quality metrics, length of time spent in bed or asleep, tranquility or restlessness (e.g., movement during sleep), biometrics (e.g., heart rate, respiratory rate, temperature), or other data.

[0199] In process 2100, the user interface and automation are selected based on the user's position within their sleep routine. That is, the user's state is categorized into one of the possible states: "before bedtime," "bedtime to wakeup," and "awake." Depending on the state, different user interfaces are presented to the user, and the user's environment can be automated.

[0200] Determining the user's in-bed status 2102. For example, processor 502 may collect sensor data (e.g., from pressure sensors and / or one or more peripheral sensors 902) and use that sensor data to determine whether the user of user interface device 1902 is in bed. This may include, for example, applying time series of pressure data to an presence classifier that generates an in-bed / out-of-bed classification, but other processes for determining the in-bed status are also possible.

[0201] If the user is not in bed 2104, a sleep data user interface 2106 is displayed. For example, if the user is not in their bed and accesses a bed-related application using their phone (i.e., user interface device 1902), the application can be launched directly into a user interface GUI containing user interface elements that display the user's historical sleep data. Interface elements may include labels, graphics, and animations that display data (raw or aggregated data) collected from the user's previous sleep sessions. This may include sleep quality metrics, length of time spent in bed or asleep, tranquility or restlessness (e.g., movement during sleep), biometrics (e.g., heart rate, respiratory rate, temperature), or other data.

[0202] If the user is in bed 2104, the time of day 2108 can be determined. For example, the user interface device 1902 can consult a real-time clock and access the time of day in hours, minutes, and seconds within a 24-hour cycle. The user interface device 1902 can categorize the current time as a "wakeup time" or not. For example, the user can specify that they typically wake up at a specific time (e.g., 6:30 AM), and the wakeup time can be set to a time window starting at 6:30 AM and lasting for 30 minutes. In another example, the user interface device 1902 can access historical user behavior data to identify windows when the user has historically woken up, and this can be used to determine the user's wakeup time.

[0203] If the current time is outside the wake-up time 2110, the bed control user interface 2112 is displayed. That is, the user may be lying in bed while trying to fall asleep, reading, etc., and may want to adjust the bed for greater comfort. If the user is in bed and accessing a bed-related application using their phone (i.e., user interface device 1902), the application can be launched directly into the user interface GUI containing user interface elements to adjust the bed. These interface elements may include buttons, sliders, or other elements that, when manipulated, cause the bed to change pressure, hinge the base, engage heating or cooling elements, etc.

[0204] If the current time is within the wake-up time 2110, the wake-up user interface 2114 is displayed, and the room lighting 2116 is slowly increased. This might be used to capture a user waking from a night's sleep. When they wake up, they might be interested in how well they slept and can access the application on their user interface device 1902. The wake-up screen can present an application that can be launched directly into a user interface GUI containing user interface elements that display the previous night's sleep data (and optionally, historical sleep data from previous nights). Additionally, the wake-up user interface can include other information that the user might be interested in during the day, such as the user's weather forecast, upcoming appointment list, etc.

[0205] Additionally, to help the user wake up, one or more automated events can be executed. In this example, the lighting controller is instructed to slowly increase the light in the user's environment by engaging the lighting at its lowest level and then gradually increasing the level over a period of time. In other examples, other automated events can be used to supplement or replace this example. For example, the ambient or bed temperature can be changed, the bed firmness can be changed, etc.

[0206] In process 2200, the user interface is selected based on the user's biometrics and in-bed condition. For example, if the user is displaying unexpected biometric readings, this could be an important finding that can be presented to the user immediately, as it can indicate health issues that the user should be aware of before, for example, adjusting the comfort of their bed.

[0207] 2202. Determine the user's biometrics. For example, processor 502 may use stress data and / or peripheral data to generate one or more data objects to record readings of the user's body. This may include using data from the bed and / or may include using data from non-bed sources such as activity trackers, medical devices, etc.

[0208] If the user is displaying unexpected biometrics 2204, then the biometric user interface 2206 is displayed. For example, if the user's heart rate, body temperature, and breathing pattern are determined by a classifier to be more like the heart rate, body temperature, and breathing pattern of a person with a specific physiological condition (e.g., fever, risk of an impending heart attack), then the biometric user interface can be displayed.

[0209] In some cases, multiple different biometric user interfaces are available, and one is selected based on the severity of the biometric classification. For example, a "fever" classification might be assigned a "low" severity level, and when a user selects their bed app on their phone, a low-severity biometric user interface can be displayed. However, "risk of impending heart attack" might be assigned a "high" severity level, and a high-severity biometric user interface can be selected. This high-severity biometric user interface could have push notification functionality, allowing an audible warning to be issued on the user's phone or a speaker in a home automation center, or a message could be sent to nurses or caregivers in a healthcare setting.

[0210] If the user is displaying the expected biometrics 2204, then the user's in-bed status 2208 is determined. For example, processor 502 may collect sensor data (e.g., from pressure sensors and / or one or more peripheral sensors 902) and use that sensor data to determine whether the user of user interface device 1902 is in bed. This may include, for example, applying time series of pressure data to an presence classifier that generates an in-bed / out-of-bed classification, but other processes for determining the in-bed status are also possible.

[0211] If the user is in bed 2210, the bed control user interface 2212 is displayed. For example, if the user is in their bed and accessing an application related to their bed using their phone (i.e., user interface device 1902), the application can be launched directly into the user interface GUI containing user interface elements to adjust the bed. These interface elements may include buttons, sliders, or other elements that, when manipulated, cause the bed to change pressure, hinge the base, engage heating or cooling elements, etc.

[0212] If the user is not in bed 2210, a sleep data user interface 2214 is displayed. For example, if the user is not in their bed and accesses a bed-related application using their phone (i.e., user interface device 1902), the application can be launched directly into a user interface GUI containing user interface elements that display the user's historical sleep data. Interface elements may include labels, graphics, and animations that display data (raw or aggregated data) collected from the user's previous sleep sessions. This may include sleep quality metrics, length of time spent in bed or asleep, tranquility or restlessness (e.g., movement during sleep), biometrics (e.g., heart rate, respiratory rate, temperature), or other data.

[0213] Figures 23A-27These are example graphical user interfaces (GUIs) 2300-2700. The GUI can be used as part of computer applications associated with beds, bed monitoring devices, home automation, etc. Navigation between GUIs 2300-2700 can be accomplished by the user directly inputting information into the device displaying the GUI 2300-2700. Additionally or alternatively, the application can switch to a specific GUI 2300-2700 based on the user's state 1906.

[0214] GUI 2300 is an example sleep data user interface. GUI 2300 presents sleep data, for example, when the user gets out of bed. As shown here, GUI 2300 includes a sleep data element 2302 located above the biometric element 2304.

[0215] GUI 2350 is an example sleep data user interface that can be used when a user's biometric level is outside the expected range. GUI 2350 presents sleep data, for example, when the user gets out of bed. As shown here, GUI 2350 includes a biometric element 2304 located above the sleep data element 2302.

[0216] GUI 2400 is a sample bed control user interface. GUI 2400 presents bed controls to the user and can be displayed when the user is in bed.

[0217] GUI 2500 is an example of a user profile user interface. In GUI 2500, users can be prompted to update their sleep profiles, for example, in response to assessments of changes in weight or other factors indicated by the user's biometrics.

[0218] GUI 2600 is an example of an account user interface. In GUI 2600, users can access and edit their personal contacts and other account information.

[0219] GUI 2700 is an example of an error-based user interface. In GUI 2700, if the system detects an error or problem, or the user identifies it, the application can help the user resolve the error or problem with their hardware.

Claims

1. A system comprising: a bed having a mattress; a sensor configured to generate sensor data of the mattress; a processor device configured to: receive the sensor data; and determine a user state from at least the sensor data; a user interface device comprising user interface hardware configured to provide a plurality of user interfaces for an application, the user interface device configured to: select a selected user interface from the plurality of user interfaces based on the user state determined from at least the sensor data, wherein the selected user interface is a bed control user interface when the user state indicates a user is present on the bed; and wherein the application launches the selected user interface on the user interface device.

2. The system of claim 1, wherein: to determine the user state, the processor device is configured to determine a presence of the user on the bed; and the user interface device is further configured to select the selected user interface from a group consisting of the bed control user interface and a sleep data user interface based on the presence of the user on the bed.

3. The system of claim 1, wherein: to determine the user state, the processor device is configured to determine a presence and a time of the user on the bed; and the user interface device is configured to select the selected user interface from a group consisting of the bed control user interface, a wake-up user interface, and a sleep data user interface based on the presence and the time of the user on the bed. in response to selecting the wake-up user interface, the user interface device is further configured to send instructions to a peripheral controller to engage a peripheral device.

4. The system of claim 3, wherein, 5. The system of any of claims 1-4, wherein: to determine the user state, the processor device is configured to determine at least one biometric reading and a presence of the user on the bed; and the user interface device is configured to select the selected user interface from a group consisting of a biometric user interface, the bed control user interface, and a sleep data user interface based on the at least one biometric reading and the presence of the user on the bed.

6. The system of any of claims 1-4, wherein: the user interface device is further configured to: select a selected peripheral action from a plurality of available peripheral actions; send instructions to a peripheral controller based on the selected peripheral action; and wherein the peripheral controller comprises a second processor and computer memory, and the peripheral controller is configured to engage a peripheral device according to the selected peripheral action.

7. The system of any of claims 1-4, wherein: the sensor comprises at least one peripheral sensor and a pressure sensor, the peripheral sensor configured to generate peripheral data, and the pressure sensor configured to generate pressure data; and wherein the processor device is further configured to receive at least one of the peripheral data; and ​ wherein the user state is determined from at least one of the peripheral data and the pressure data.

8. The system of any one of claims 1-4, wherein, The selected user interface includes a graphical user interface (GUI) element.

9. The system of any one of claims 1-4, wherein, The selected user interface includes an audible output and a voice-based input.

10. A method comprising: receiving sensor data generated by a sensor of a bed having a bed mattress; determining a user state from at least the sensor data; selecting, by a user interface device comprising user interface hardware capable of providing a user interface, a selected user interface for an application from a plurality of user interfaces, wherein the selected user interface is a bed control user interface when the user state indicates a user is present on the bed; and wherein the application launches the selected user interface on the user interface device.

11. The method of claim 10, wherein: determining the user state comprises determining an in-bed condition; and selecting the selected user interface comprises selecting, based on the in-bed condition, one of a group consisting of the bed control user interface and a sleep data user interface as the selected user interface.

12. The method of claim 10, wherein: determining the user state comprises determining an in-bed condition and a time; and selecting the selected user interface comprises selecting, based on the in-bed condition and the time, one of a group consisting of the bed control user interface, a wake-up user interface, and a sleep data user interface as the selected user interface.

13. The method of claim 12, further comprising sending, in response to selecting the wake-up user interface, an instruction to a peripheral controller to engage a peripheral device.

14. The method of any of claims 10-13, wherein: determining a user state from at least the sensor data further comprises determining at least one biometric reading and an in-bed condition; and selecting the selected user interface comprises selecting, based on the at least one biometric reading and in-bed condition, one of a group consisting of a biometric user interface, the bed control user interface, and a sleep data user interface as the selected user interface.

15. The method of any of claims 10-13, further comprising: selecting a selected peripheral action from a plurality of available peripheral actions; and sending, based on the selected peripheral action, an instruction to a peripheral controller; and engaging, in accordance with the selected peripheral action, a peripheral device.

16. The method of any of claims 10-13, further comprising: receiving peripheral data from a peripheral sensor; and determining a user state from at least the sensor data and the peripheral data.

17. The method of any one of claims 10-13, wherein, The selected user interface includes a graphical user interface (GUI) element.

18. The method of any one of claims 10-13, wherein, The selected user interface includes an audible output and a voice-based input.

19. A system comprising: one or more processors; computer memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform actions comprising: receiving sensor data generated by a sensor of a bed having a mattress; determining a user state from at least the sensor data; selecting, by a user interface device comprising user interface hardware capable of providing a user interface, a selected user interface for an application from a plurality of user interfaces, wherein the selected user interface is a bed control user interface when the user state indicates a user is present on the bed; and wherein the application launches the selected user interface on the user interface device.

20. The system of claim 19, wherein, The actions further include: determining the user state includes determining an in-bed condition; and selecting the selected user interface includes selecting, based on the in-bed condition, one of a group consisting of the bed control user interface and a sleep data user interface as the selected user interface.

21. A system comprising: a bed having a mattress; a sensor configured to sense a user on the mattress and generate user data; a processor device configured to: receive the user data; and determine a user state from at least the user data; a user interface device comprising user interface hardware capable of providing a user interface, the user interface device configured to: select a selected user interface for an application from a plurality of user interfaces, wherein the selected user interface is selected according to a user state determined from at least the user data such that when the user state is a first state, the selected user interface is a first user interface, and when the user state is a second state different from the first state, the selected user interface is a second user interface different from the first user interface; and wherein the application launches the selected user interface on the user interface device; wherein the first state includes the user being on the mattress and the first user interface includes a control interface configured for controlling the mattress.

22. The system of claim 21, wherein, The second state includes the user not being on the mattress.

23. The system of claim 22, wherein, The second user interface includes a report interface configured to report information about a previous sleep session. The second user interface includes a report interface configured to report information about a previous sleep session.

Images