WO2023164327A1

WO2023164327A1 - Sleep-cycle processing in a communication device

Info

Publication number: WO2023164327A1
Application number: PCT/US2023/060513
Authority: WO
Inventors: Prakash Guda; Swetang SHARMA; Aparna Navalgund
Original assignee: Stryker Corporation
Priority date: 2022-02-28
Filing date: 2023-01-12
Publication date: 2023-08-31

Abstract

A method and system for controlling sleep cycle of a battery-powered wireless communication device (WCD). An example method includes the WCD detecting that the WCD has lost wireless coverage, and, responsive to the detecting, the WCD transitioning into a sleep state and then periodically waking from the sleep state to scan for wireless coverage. In this process, the periodic waking could be according to a sleep cycle defining how long the WCD remains in the sleep state between instances of the WCD waking to scan for wireless coverage. Further, while the WCD remains out of wireless coverage, the WCD could progressively increase the sleep cycle.

Description

SLEEP-CYCLE PROCESSING IN A COMMUNICATION DEVICE

REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 63/268,699, filed February 28, 2022, and to U.S. Provisional Patent Application No. 63/269,220, filed March 11, 2022, the entirety of each which is hereby incorporated by reference.

BACKGROUND

[0002] Providing patient care in healthcare facilities (e.g., hospitals) generally necessitates interaction between healthcare workers (e.g., doctors, nurses, pharmacists, technicians, nurse practitioners, etc.) and between those healthcare workers and various devices/ systems that support treatment of patients.

[0003] Many healthcare facilities have already installed one or more wireless networks to support wireless communication devices such as laptop computers and mobile phones that could facilitate this interaction. These wireless networks typically use standard wireless networking protocols, such as one of the 802.11 standards, with wireless access points distributed throughout the facilities and coupled with each other and/or with other network nodes using wireless mesh networking and/or wired (e.g., Ethernet) networking. When in coverage of such a network, healthcare workers may thus use their wireless communication devices in a conventional manner, to engage in calls with each other and perhaps to communicate with a centralized healthcare management system, among other possibilities.

SUMMARY

[0004] One challenge that healthcare workers could face when using conventional wireless communication devices to communicate with each other and with supporting systems in typical healthcare facilities is that it may be inconvenient or impractical for the healthcare workers to hold and operate those devices as they go about their business. Even though some devices may support hands-free communication, a user may still need to hold and physically interact with the device to engage in certain functions such as powering on the device, dialing calls, or the like. For instance, a user may need to hold the device while interacting with a graphical user interface on a screen of the device and/or with a physical keypad or other such interface of the device.

[0005] As presently contemplated, a solution to this problem is to equip healthcare workers with specialized communication devices that rely largely on voice interaction. Such a device could be small, portable, and lightweight, configured to be worn by a healthcare worker (e.g., clipped to a shirt collar or worn on a neck-strap), and could operate in an always-on state, enabling the healthcare worker to quickly and conveniently place and receive calls, receive alerts, and interact with supporting systems, all without a need to hold the device and with minimal or no need to even touch the device.

[0006] Representative healthcare facilities could be configured with a communication system and associated systems that support use of such devices, and each healthcare worker could wear and use one of the devices. In particular, the communication system could include a wireless network having one or more wireless access points that the devices could communicate with using a standard or proprietary wireless communication protocol. And the communication system could include a central computing system that the devices could communicate with through the network and that controls and/or facilitates various communication operations. The healthcare workers could then conveniently make use of their devices to place and receive calls with each other and to engage in communication with the central computing system, to facilitate accessing healthcare information, receiving or sending messages, indications, or alerts, and engaging in other communications.

[0007] A representative communication device, also referred to as a “user device” or electronic device, could be powered by a rechargeable battery and could include one or more microphones for receiving voice or other audio input and one or more speakers and/or other interfaces for outputting voice or other audio. Further, the device could include one or more LEDs, haptic actuators, and/or other mechanisms for presenting visual, haptic, or other indications or alerts to the user. And the device could include a WiFi communication module or other wireless communication module to enable the device to communicate with the central computing system.

[0008] When such a device powers on within the healthcare system or otherwise enters into the healthcare system, the device may use its WiFi module to scan for WiFi coverage and may acquire WiFi connectivity with a nearby access point, and the device may then engage in signaling through the network with the central computing system, to register its presence and active state in the system. Once the device is so connected and registered, the device may then engage in communications with and through the central computing system, to facilitate communicating with other users and with associated systems.

[0009] In an example implementation, the device could be configured to receive voice commands from its user and to convey those voice commands to the central computing system for processing. For example, to initiate a voice call to another user, the user may speak call-initiation voice command designating a name of the other user, the device may responsively convey that voice command to the central computing system, and the central computing system may then engage in signaling to set up the requested voice call to the other user and may bridge the call, enabling the users to talk with each other. As another example, to request assistance or action to serve a patient, the user may speak an associated voice command expressing the request, the device may responsively convey that voice command to the central computing system, and the central computing system may process the request for assistance, perhaps conveying the request to one or more associated users and/or departments for handling.

[0010] One technical issue that could arise in practice with such a device is that providing “always-on” service could result in significant battery drain.

[0011] To help address this issue, the device could be configured to operate discontinuously, by transitioning to a low-power sleep state after a period of inactivity and/or upon leaving WiFi coverage for instance, and then transitioning back to a full-power state in response to certain triggers, such as periodically and/or upon receipt of an incoming message or upon user utterance of a wake word (e.g., word or phrase).

[0012] While within WiFi coverage, for instance, the device could transition to a low-power sleep state in which the device powers off or otherwise reduces power consumption of its host processor and various other components, including putting its WiFi module into a sleep state in which the WiFi module wakes up periodically in accordance with a protocol to check for any incoming unicast or multicast traffic. From that state, the device could then transition back to full-power state in response to receiving a unicast or multicast WiFi packet that may carry or precede an alert, message, call, or other signal from the central computing system, and the device could also transition at least partly back to the full-power state periodically to send a heartbeat message to the central computing system, to inform the central computing system that the device remains actively connected.

[0013] Whereas, when the device leaves WiFi coverage, the device could transition to a low-power sleep state in which the device powers off or otherwise reduces power consumption of its host processor and other components including the device’s WiFi module. From this state, the device could then transition back to full-power state periodically to newly scan for WiFi coverage, i.e., to determine if the device has re-entered WiFi coverage. Further, the device could likewise transition back to the full-power state and scan for WiFi coverage when the device detects user utterance of the wake word. Upon newly finding WiFi coverage, the device could then reacquire WiFi connectivity and remain in the full-power state until transitioning once again to the sleep state.

[0014] Unfortunately, however, this discontinuous operation may itself also give rise to another technical issue. Namely, if the device has left WiFi coverage and has responsively transitioned to the low-power sleep state with its WiFi module powered down, and if the device will periodically wake up from that sleep state to newly scan for WiFi coverage, at issue is how often the device should do so. Scanning for WiFi coverage may contribute to battery drain. Therefore, waking up too often in this situation could result in significant battery drain. On the other hand, waking up too infrequently in this situation could delay the device’s re-connection with the system after the device has actually re-entered WiFi coverage.

[0015] Disclosed herein are technical solutions that may help to address this issue.

[0016] As to the period of waking up from the low-power sleep state to scan for WiFi coverage, the device could be configured to wake up every N seconds to newly scan for coverage, i.e., to sleep for N seconds between instances of scanning for coverage, and the device could increase that sleep period progressively over time. For instance, upon leaving WiFi coverage and entering the sleep state, the device could wake up every 2 seconds to newly scan for coverage. Then after some time in this state, the device could increase its sleep cycle to 4 seconds so the device would wake up every 4 seconds to newly scan for coverage. And then after some time in this new state, the device could increase its sleep cycle to 8 seconds, so that the device would wake up every 8 seconds to newly scan for coverage, and so forth.

[0017] Optimally, this progressive increasing of the device’s sleep cycle could help to balance the factors noted above. If a user of the device leaves WiFi coverage for just a short break and then returns, the sleep cycle would be short and the device may re-connect relatively quickly after the user re-enters coverage. Whereas, if the user leaves WiFi coverage for a longer time, the sleep cycle would become longer, which could help to conserve the device’s battery energy.

[0018] These as well as other aspects, advantages, and alternatives will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference, where appropriate, to the accompanying drawings. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise.

BRIEF DESCRIPTION OF THE FIGURES

[0019] Figure 1 is a simplified illustration of an example communication system in which an example user device may operate.

[0020] Figure 2 is a simplified block diagram depicting example application programs in a central computing system operable in the system of Figure 1.

[0021] Figure 3 A illustrates a left/front side perspective view of an example user device.

[0022] Figure 3B illustrates a right/back side perspective view of the example user device.

[0023] Figure 3C illustrates a right side view of the example user device.

[0024] Figure 3D illustrates a left side view of the example user device.

[0025] Figure 3E illustrates a top side view of the example user device.

[0026] Figure 3F illustrates a bottom side view of the example user device.

[0027] Figure 3G illustrates an exploded view of the example user device.

[0028] Figure 3H illustrates a view of the example user device worn by an example user.

[0029] Figure 4 is a simplified block diagram showing hardware components of the example user device.

[0030] Figure 5 is a flow chart depicting an example method for power control in an example user device.

DETAILED DESCRIPTION

[0031] Example systems, methods and apparatus are contemplated herein. Any example embodiment or feature described herein is not necessarily to be construed as preferred or advantageous over other embodiments or features. Further, the example embodiments described herein are not meant to be limiting. It will be readily understood that certain aspects of the disclosed systems, methods, and apparatus can be arranged and combined in a wide variety of different configurations, all of which are contemplated herein. In addition, the particular arrangements shown in the figures should not be viewed as limiting. It should be understood that other embodiments might include more or less of each element shown in a particular figure. Additionally, some of the illustrated elements may be combined or omitted. Yet further, an example embodiment may include elements that are not illustrated in the figures.

[0032] Example embodiments described herein relate to systems, methods, and apparatus for enabling communications in a communication system. The communication system could comprise a user device for each user, one or more access points with which each user device may communicate, and a central computing system that may control and facilitate communication within the communication system. The central computing system and the access points may be connected together by a computer/communications network, such as a local area network (LAN), a wide area network (WAN), or another other similar network.

[0033] As noted above, the user device could be a portable wireless device that supports hands-free, voice communications. The user device could include one or more microphones that receive voice commands and other voice input from a user, and one or more speakers that generate audible output signals. Further, the user device could include a wireless communication module, enabling the device to connect with the network and engage in communication through the system.

[0034] The user device could be sufficiently small and lightweight enough so that the user could comfortably wear the device by clipping the device onto the user’s collar or shirt pocket or wearing the device on a lanyard around the user’s neck. In an example implementation, hands-free operation of the device using voice commands uttered by the user may also require the device to be situated within no more than a particular distance below the chin of the user so that the device can receive the voice audio (e.g., an utterance) from the user with sufficient volume and at an expected angle of arrival, to facilitate recognition and processing of the voice by the device and/or the central computing system. [0035] Figure 1 is a simplified illustration of example communication system 100 that could enable communication between users each equipped with the representative user device, and between those users and supporting systems. As illustrated, the example communication system includes multiple user devices 102, multiple wireless access points 104, and a central computing system 106, such as a server computer or cluster of computers. Further, as shown, the central computing system 106 and access points 104 could be connected with each other over a communication network 108, such as a LAN and/or WAN, to facilitate communication between the user devices 102 and the computing system 106. In addition, as shown, the computing system may be connected to a telephone system 110, such as the private branch exchange (PBX) system and voicemail system, to facilitate connecting outside calls. And the communication system 100 could further include a backup computing system 112 (shown in phantom), also with the computer network 108.

[0036] In an example implementation, the access points 104 could be located in a workplace or other facility (e.g., building), such as within healthcare facilities for instance, or could be distributed among multiple such facilities. For instance, for a large work environment encompassing multiple facilities, network 108 might comprise multiple LANs interconnected through the Internet or other WAN, with access points 104 distributed throughout each LAN. In that implementation, the central computing system 106 could also be distributed throughout the various facilities, and/or a central system could control communications within and between all of the facilities. Other arrangements could be possible as well.

[0037] The access points 104 of the wireless commination system 100 may be wireless access points that use standard wireless protocols, likely IEEE 802.11 standards supporting WiFi communication, but also possibly other protocols such as BLUETOOTH, ZIGBEE, or the like. In other embodiments, the access points could comprise cellular base stations operating according to a cellular wireless protocol, such as Long Term Evolution (LTE) or 5G New Radio (5G NR), among other possibilities. In any case, the wireless communication module of each user device 102 could be configured to support corresponding communication. For instance, if the access points 104 support WiFi communication according to 802.11 standards, each user device’s wireless communication module could correspondingly support WiFi communication and service by the access points 104.

[0038] Each access point 104 could provide a respective coverage area within which to serve user devices 102. The range of this coverage area could depend on various factors, such as antenna configuration, power settings, and wireless communication protocol for instance. Further, to permit handoff of user devices between the access points 104, the access points 104 could be positioned and configured so that their coverage areas overlap with each other as shown in the figure. When a user device initially powers on or otherwise enters into coverage of this system, the user device may scan for coverage of an access point. And upon detecting coverage of an access point with sufficient signal strength, the user device may then engage in signaling to connect with the access point. Once connected with the access point, the user device may then engage in communication through the network 108 with the central computing system 106 and ultimately with other user devices and/or with supporting systems.

[0039] In an example implementation, the central computing system 106 could be responsible for the overall control and operation of the communication system 100. To facilitate this, the central computing system 106 could include a network communication interface (e.g., Ethernet interface) for communicating on network 108, and could further include one or more processing units (e.g., one or more general purpose processors such as microprocessors, and/or one or more specialized processors such as digital signal processors or application specific integrated circuits), non-transitory data storage (e.g., one or more volatile and/or non-volatile storage components such as read-only memory (ROM), random access memory (RAM), electrically erasable programmable read only memory (EEPROM), flash memory, optical storage, magnetic storage, or the like), and program instructions stored in the data storage and executable by the processing unit(s) to carry out various computing system operations. Without limitation, for instance, the computing system 106 could be programmed with software application programs running on an operating system such as a Windows or Linux based operating system.

[0040] Among other operations, the central computing system 106 could maintain records of profile and presence state of the user devices 102 that are configured to operate in the communication system 100. For instance, the computing system 106 could maintain profile records that assign particular users to particular user devices 102 and that include other associated information such as user name, job title, department, and contact lists, as well as voice signatures or the like. Further, the computing system 106 could maintain presence or registration records, indicating for each device whether and when the device is present and connected within the communication system and perhaps which access point is currently serving the device. [0041] Once a user device 102 connects with an access point in the communication system 100, the user device 102 may then engage in registration signaling with the computing system 106 to register its presence in the communication system 100, and the computing system 106 may update a presence record for the user and the user device 102 accordingly. Further, while so connected, the user device 102 may also send periodic heartbeat messages to the computing system 106 to inform the computing system 106 that the user device 102 remains actively connected. And when the computing system 106 stops receiving those heartbeat messages from a user device 102 or otherwise learns that the user device 102 is no longer actively connected in the communication system 100, the computing system 106 may update the user’s and device’s presence record to indicate that the user device 102 is no longer actively connected.

[0042] Figure 2 is a simplified block diagram depicting example application programs that could be included in the computing system 106. As shown in Figure 2, the example application programs include a speech interface 200, a call manager 202, a connection manager 204, and an administrator 206. In an example implementation, the speech interface 200 could include a conventional software-based engine that supports text- to-speech and speech-to-text conversion, enabling the computing system to receive, interpret, and execute voice commands from the user devices 102 and to provide voice-based messaging to the user devices 102 for presentation. The call manager 202 could include a conference bridge system that supports setting up and connecting calls between the user devices 102 and perhaps with an external telephone network, and may support two-party and multi-party calls. The connection manager 204 may function to maintain presence and registration information regarding user devices 102 as noted above. And the administrator 206 may provide a web-based interface to facilitate configuring and monitoring of the communication system 100. Other arrangements could be possible as well.

[0043] As noted above, the user device 102 could be a lightweight, portable, battery powered device, configured to support voice-based communication and wireless network communication. Such a device could take various forms. Without limitation, Figures 3A-3G depict a representative example device as user device 302.

[0044] As shown in Figures 3A-3G, the example user device 302 includes a device housing 304, with an associated clip assembly 306 that enables clipping of the device onto a user’s collar, shirt pocket, or the like, or onto a lanyard worn around the user’s neck.

[0045] As shown in the exploded view of Figure 3G, the housing 304 of the device 302 could be formed from multiple pieces that are joined together. For example, the housing 304 could have a front cover 308 and a back cover 310. In other embodiments, the housing 304 may be formed as a single piece construction. The housing 304 could be constructed using a variety of manufacturing processes, such as, for example, injection molding and/or vacuum forming. In addition, the housing 304 could be formed from a number of materials, including, but not limited to, thermoplastic polyurethane (TPU), plastic, metal, rubber, and/or a combination of these and/or other materials.

[0046] As shown in Figures 3A, 3D, and 3G, the device 302 includes a linear microphone array 312, which is shown accessible through holes in a front surface of the housing 304 but could alternatively be arranged to be accessible through holes at a side surface or elsewhere on the device 304. The linear array 312 could include three linearly aligned microphones as shown, or could alternatively include a different number of linearly aligned microphones, optimally at least two microphones that are vertically spaced from each other by a distance on the order of 2 to 5 centimeters or so. (In an alternative implementation, the microphones could be horizontally offset from each other rather than being directly in line with each other, but would still be vertically spaced from each other.) The microphones of the linear array 312 could be digital microphones configured to receive acoustic input and to convert the acoustic input into a stream of digital samples for processing by the device 302.

[0047] In addition, as shown in Figures 3B, 3C, and 3F, the device 302 includes a speaker 314, which is shown accessible through holes at a bottom side surface of the housing 304 but could alternatively be disposed elsewhere on the housing 304, optimally far enough away from the microphones 312 to help prevent feedback or other issues. The speaker 314 is configured to output voice, tones, and/or other audio to be heard by the user.

[0048] As additionally shown in Figures 3A-3G, the device 302 includes a number of user-accessible buttons, such as an activation button 318, a do-not-disturb/hold button 320, a panic button 322, and volume-control buttons 324.

[0049] The activation button 318 may be a primary control for user interaction with the device 302, as an alternative or in addition to voice control of the device 302. Further, the activation button 318 could invoke various different device functions depending on context. For instance, depending on context, the user may engage the activation button 318 to initiate a dialog with a system agent (the “Genie”) or may engage the activation button 318 to accept an incoming call or to initiate other call-related functions. In addition, the device 302 may respond differently to engaging on the activation button depending on whether the user presses and immediately releases the button or the user presses, momentarily holds, and then releases the button. [0050] The do-not-disturb/hold button 320 may also be a momentary push button, or may be a toggle switch, specifically for placing the user device 302 in a do-not-disturb (DND) mode if no call is currently in progress or in a hold mold if a call is in progress. As shown, the DND/hold button 320 could be disposed at the top of the device 302, for convenient access. Further, the DND /hold button 302 may be backlit by a multi-color LED that is normally inactive but that turns on when the device 302 is in the DND mode or hold mode, possibly lighting differently depending on which of these modes is on - such as blinking while the device 302 is in the DND mode or being continuously illuminated while the device 302 is in the hold mode.

[0051] The panic button 322 may likewise be a momentary push button, situated near or at the top of the device 302 for convenient access. When the user engages the panic button 322, the device 302 may send a panic message, which may cause the central computing system 106 to send notifications to other users, indicating an emergency or urgent matter. Further, the adjustment control buttons 324 may have a push-button configuration and be situated along a side of device 302 as shown, enabling the user to change volume of audio output (e.g., speaker) of the user device 302.

[0052] In addition to the LED indicators of the DND/hold button, the device 302 may include a number of other surface-facing LED indicators, some of which are shown in Figures 3A, 3E, and 3G. These indicators include a status indicator 326, a connectivity indicator 328, an alert indicator 330, and a message indicator 332. Further, the device may also include an internal haptic device configured to produce haptic vibration to indicate various alerts, status, or other information.

[0053] The status indicator 326 is integrated with the activation button 318 and could output various different colors to indicate various different operations states of the device 302. For instance, the status indicator 326 may slowly blink a green light to indicate that the device 302 is within wireless coverage of the communication system 100, the status indicator may slowly blink a red light to indicate that the device 302 is not within coverage of the system 100. Further, other blinking patterns and light colors could be used to indicate other conditions, such as that battery level of the device is threshold low for instance. The status indicator 326 and activation button 318 may also cooperatively display a logo, design, or other pattern, such as a company logo, as shown in Figure 3G for instance.

[0054] The connectivity indicator 328 could indicate whether the device 302 is connected with the communication system 100, such as whether the device has established WiFi connectivity with an access point 104 for instance. Like the status indicator 326, the connectivity indicator 328 may present various different colors and/or blinking patterns to indicate various different states. For instance, the connectivity indicator 328 could present a solid green light to indicate when the user device is connected with the system 100 and could present a white or yellow light to indicate when the user device is not connected with the system 100.

[0055] The alert indicator 330 could function to present an alert to the user of the device 302 and may present different colors to indicate various different alerts. Further, the message indicator 332 could function to notify the user that a message has been received for the user, e.g., that the computing system 106 has received a message that is waiting to be delivered to the user. The message indicator 332 may present various different colors and/or blinking patterns to indicate various different message states. For instance, the message indicator could present a fast blinking green light to indicate that a message is waiting for the user.

[0056] To facilitate portable use, the device 302 further includes a rechargeable battery 334 to power various components of the device 302. As shown in Figures 3B and 3G, the battery 334 could be configured to fit within a battery receptacle at the back of the device 302 in order to establish electrical communication with and supply power to various device components. Further, the battery 334 could be removable by a user to facilitate recharging or replacing the battery. Alternatively, the battery 334 could be permanently housed within the device 302, possibly not removable by the user, and the device 302 could include a wired, inductive, or other mechanism to recharge the battery 334. The battery could be of various types, such as nickel metal hydride (NiMH), nickel cadmium (NiCd), Lithium Ion (Li-Ion), or lithium polymer (Li-Poly), among other possibilities. Further, the device 302 could alternatively use more than one battery and/or another power source.

[0057] Because the example device 302 may be largely voice controlled, the device 302 might not include any display screen. Alternatively, the device may include one or more display screens.

[0058] In use, to enable the device 302 to receive and process voice commands spoken by the user and to receive other voice audio spoken by the user, it may be best to situate the device 302 about 6 inches below the chin of the user, as shown in Figure 3H. Further, with the linear microphone array 312 oriented as shown the figures, it may be best to orient the device 302 itself vertically when worn by the user (i.e., with the top of the device 302 facing straight up) so that the linear microphone array of the device 302 will also be oriented vertically. This vertical orientation of the microphone array could help facilitate the device’s evaluation of separate microphone audio channels as a basis to determine whether received voice audio is spoken by the user wearing the device or rather by another user. To so orient the device, the clip assembly 306 could be configured with one or more pivot points that enable the device to rotate at its juncture with the clip assembly and hang downward in the desired vertical orientation if possible. In an alternative implementation, a user may carry the user device 302 in a pocket or holster, and the user may then remove the device 302 and bring it into the optimal position to support providing voice commands and other voice audio.

[0059] As shown in the exploded view of Figure 3G, the example user 302 device contains a printed circuit board (PCB) 336. This PCB is configured with numerous components to facilitate operation of the device 302.

[0060] Without limitation, Figure 4 is next a simplified block diagram illustrating hardware components of the device 302 in an example implementation. As shown in Figure 4, the device includes a central processing unit (CPU) 402, non-transitory data storage 404, microphones 406, speaker(s) 408, an audio interface 410, a voice recognizer 412, indicators 414, buttons 416, a wireless communication interface 418, and a power-supply subsystem 420. In the example implementation, many of these components could be mounted on the PCB 400.

[0061] The CPU 402 functions as a host processor of the device 302, configured generally to control operation of the device 302. CPU 402 could be a processor with an ARM core running a Linux operating system, among other possibilities and could be mounted on the PCB 336 in electrical, optical, or other communication with various device components as shown, through various pins of the CPU 402.

[0062] The CPU 402 could have at least a full-power state and a low-power sleep state and could selectively operate in either of these states. In the full-power state, the CPU 402 could be fully operational, with its CPU clock and system clock running and the CPU executing various applications and performing various computations, consuming a level of battery energy to perform its operations. Whereas, in the sleep state, the CPU clock and various other CPU operations may be halted, so the CPU 402 could consume far less battery energy. Power state of the CPU 402 could operate in accordance with a state machine, which could involve transitioning the CPU 402 from the full-power state to the sleep state in response to various triggers (e.g., after a period of inactivity, or upon learning that the device 302 has left coverage of the system 100) and transitioning the CPU 402 from the sleep state to the full-power state in response to various triggers (e.g., periodically to send heartbeat messages or to scan for WiFi coverage, or upon receipt of an interrupt signal such as when the device 302 detects wake-word utterance), among other possibilities.

[0063] The non-transitory data storage 404, which could likewise be mounted on the PCB 336, could comprise one or more volatile and/or non-volatile storage components such as ROM, RAM, EEPROM, flash memory, or optical storage, among other possibilities. For instance, the data storage 404 could include DDR3L memory and/or flash memory. While the data storage 404 is shown separate from the CPU 402, the data storage could alternatively be integrated in whole or in part with the CPU 402. The non-transitory data storage 404 could hold program instructions (e.g., compiled or non-compiled program logic and/or machine code) executable by the CPU 402 to carry out or cause the device 302 to carry out various device processing operations discussed herein. Further, the non-transitory data storage 404 could hold reference data for access by the CPU 402 to facilitate carrying out some of those operations.

[0064] The microphones 406, which could also be mounted on the PCB 336, could define the linear microphone array 312 noted above. As indicated above, the microphones 406 could be digital microphones configured to receive acoustic input defining an audio waveform and provide digital output in the form of a sequence of digital samples of the received audio waveform, in a pulse density modulation (PDM) or pulse code modulation (PCM) format for instance, for processing by the CPU 402 and/or the voice recognizer 412. Like the CPU 402, the microphones 406 could have a full-power state and a low-power state and, through CPU control, could selectively operate in and transition between these states. When the CPU 402 transitions to its sleep state, the CPU 402 may also cause one or more of the microphones 406 to enter their sleep state but may keep at least two of the microphones in their full-power state to facilitate their receipt of audio that may represent the wake word.

[0065] The speaker(s) 408, which could also be mounted on the PCB 336, could comprise a low profile micro speaker outputting acoustic audio. And the audio interface 410, which could also be mounted on the PCB 336, could be a high-performance, low power audio codec, which could perform analog-to-digital and digital-to-analog conversion among other operations. Digital audio output from the CPU 402 could pass to the audio interface 410, the audio interface could convert that audio to an analog audio waveform, and the speaker(s) 408 could output the audio to be heard by a user. The device 302 may also include an amplifier (not shown) to amplify the audio for output. In addition, the example device 302 may also include a port for connecting a headset and/or may support a wireless headset connection, to facilitate private listening. [0066] The voice recognizer 412, which could also be mounted on the PCB 336, could be a dedicated speech-recognition chipset that operates with low power consumption and could be configured to recognize utterance of particular wake words and other key words. The voice recognizer could run deep-learning algorithms to efficiently detect utterance of a defined wake word, such as “OK Vocera” for instance and could respond to detecting utterance the wake word by signaling to the CPU 402 to trigger further processing.

[0067] The indicators 414, which could likewise be mounted on the PCB 336, could comprise the LED indicators noted above, such as the status indicator 326, the connectivity indicator 328, the alert indicator 330, and the message indicator 332. And the buttons 416, which could have communication interfaces with the CPU 402, could comprise the buttons noted above, such as the activation button 318, the DND/hold button 320, the panic button 322, and the volume-control buttons 324.

[0068] The wireless communication interface 418, which may also be mounted on the PCB 336, could comprise one or more wireless interfaces configured to enable short- range communication with one or more networks according to one or more wireless local area network (WWAN) protocols such as IEEE 802.11, BLUETOOTH, or ZIGBEE protocols for instance. Further, the wireless communication interface 418 may also include one or more interfaces to enable long-range (e.g., cellular) communication according to one or more wireless wide area network (WWAN) protocols such as LTE or 5G NR. for instance. The wireless communication interface 418 could comprise one or more transceivers with transmit and receive chains, as well as one or more antennas to facilitate air-interface communication with access points, base stations, or the like. In some implementations, the antenna(s) of could be integrated with the housing 304, clip assembly 306, or other component. Alternatively, the antenna(s) could reside completely within the device 302.

[0069] Like the CPU 402 and one or more other components of the device 302, the wireless communication interface 418 could have a full-power state and a low-power sleep state and could selectively operate in either of these or other states, under control of the CPU 402 for instance.

[0070] Upon transitioning to full-power state, the wireless communication interface 418 (e.g., WiFi module) could scan for coverage of an access point 104 having a predefined service set identifier (SSID), and upon finding such coverage with sufficient signal strength, the wireless communication interface 418 could engage in signaling with the access point 104, to establish a connection between the wireless communication interface 418 and the access point 104, and thus between the device 302 and the access point 104. Upon establishing this connection, the wireless communication interface 418 could then signal to the CPU 402 to inform the CPU 402 that the device is now connected, and the CPU 402 could then take further action, such as to engage in communication over that connection and network 108 with central computing system 106 for instance.

[0071] While so connected with an access point 104, the wireless communication interface 418 could further regularly monitor its coverage strength. This monitoring could facilitate triggering handoff of the wireless communication interface 418 between access points as the device 302 moves from one access point’s coverage to another access point’s coverage. Further, this monitoring could enable the wireless communication interface 418 to detect when it loses wireless coverage (e.g., when a user takes the device 302 out of range of the communication system 10). Upon losing wireless coverage, the wireless communication interface 418 could then transition to the sleep state and could wake up periodically, possibly under CPU control, to newly scan for wireless coverage. Further, while within wireless coverage, the wireless communication interface 418 may from time to time transition from its full-power state to its sleep state. And when in the sleep state while within wireless coverage, the wireless communication interface may wake up periodically to check for any unicast and/or messages being wirelessly transmitted to the device 302 and may then transition back to the sleep state absent receipt of such a message.

[0072] The power-supply subsystem 420 could then include the battery 334 noted above, configured to supply power to the CPU 402 and other components of the device 302. Further, the power-supply subsystem 420 could include a battery-level gauge (e.g., a voltmeter or coulomb counter), possibly integrated with the battery 334, configured to monitor, report, and manage battery charge level, which could support lighting of a batterylevel indicator when appropriate.

[0073] To facilitate use of the example user device 302 in practice, a healthcare organization (e.g., hospital) or other organization could equip its facilities with a communication system 100 like that shown in Figure 1 and could equip each of its workers (e.g., professionals, support staff, and others) with a respective instance of the user device 302. Further, an administrator of the organization could register each such user and user device 302 with the system, through a web-based interface with computing system 106 for instance.

[0074] An administrator or user could power on the user device 302 by simply inserting the battery 334 into the device 302, without a need to press a power button, as the device 302 may operate in an always-on state from the user’s perspective even though components of the device 302 may transition operate in a sleep state from time to time. So powering on the device 302 could in turn trigger the device scanning for and acquiring wireless connectivity if possible, and engaging in other device operations.

[0075] When a user receives an instance of the device 302, perhaps at the time of initial battery insertion, the device 302 may prompt the user to identify himself or herself verbally. Further, the user may need to speak a password provided by the administrator, or the computing system 106 may evaluate a voice signature of the user to confirm that the user is an authorized user. Once the user has identified himself or herself, and upon possible authentication, the computing system 106 may then establish a record associating the user with the instance of the user device 302, so that the system 106 could then interact with the user by interacting with that instance of the device 302 (e.g., to facilitate routing calls, messages, and alerts to the user). Once the user is assigned to a given device 302, the device 302 may also output a verbal welcome greeting personalized to the user (e.g., “Hello, John”).

[0076] In an example implementation, a particular user device 302 may be assigned to at most one user at a time, and each user may be assigned to just one device 302 at a time. Though a given user device 302 may be reassigned to a different user at another time.

[0077] After a user device 302 is assigned to a user, the device 302 may enter the low-power sleep state. In that state, as noted above, the user could utter the predefined wake word to wake up the device, in response to which the device could then transition to a fullpower state in order to engage in various device operations.

[0078] When the device 302 is operating in full-power state, as the user then utters voice commands or provides other voice audio, the device could transmit that audio through network 108 to the computing system 106 for analysis and processing and/or the device itself may analyze and process some such voice audio. Likewise, the device could receive voice audio and other audio from the computing system 106 and could output that audio audibly for hearing by the user. Further, the device could engage in various other signaling with the computing system 106.

[0079] For instance, if the user wishes to call another user named “Bob Smith”, the user may initiate that communication by speaking the voice command “Call Bob Smith”. As the device 302 receives this voice audio, the device 302 may then pass the audio in digital form to the central computing system 106, and a speech recognition engine at the computing system 106 may interpret the command, learning that the user wishes to call user Bob Smith. And in response, the computing system 106 may then engage in signaling with Bob Smith’s user device 302 and may bridge the user with Bob Smith so that they can engage in the call. In one implementation, voice call audio could then flow between the user and Bob Smith through the central computing system 106. In an alternative implementation, the central computing system 106 could operate as a third party call controller, to set up the voice call more directly between the two parties.

[0080] As noted above, the present disclosure provides technical mechanisms to help address the technical problems discussed above. In particular, the disclosure provides mechanisms that may help to improve power management in a battery-powered wireless communication device.

[0081] As discussed above, a technical issue relates to how often the device 302 should scan for wireless coverage once the device has left wireless coverage. In an arrangement like that discussed above, this issue could arise if a user who is equipped with the example user device 302 leaves wireless coverage of communication system 100 altogether, such as by moving out of the coverage that is cooperatively provided by the access points 104 of the system 100. When the device 302 leaves that wireless coverage, its wireless communication interface 418 may detect the absence of that wireless coverage and may, possibly after a hysteresis period to help ensure actual loss of connection, responsively signal to the CPU 402 to inform the CPU 402 that the device is no longer wirelessly connected.

[0082] In one implementation of the device 302, the CPU 402 may respond to this indicated loss of connection by transitioning the device 302 from its current power state to a sleep state. Among possibly other operations, this transitioning of the device to the sleep state could involve the CPU 402 signaling to various components of the device to direct and thus cause them to transition to low-power sleep states of their own and the CPU 402 then also transitioning to a sleep state of its own.

[0083] At least one device component that the CPU 402 thereby puts in the sleep state could be the wireless communication interface 418. Transitioning the wireless communication interface 418 to the sleep state could involve the wireless communication 418 interface tuning off its transceiver, so that the wireless communication interface 418 stops transmitting and receiving radio frequency electromagnetic energy, thus helping to conserve power of the device 302. Further, transitioning the wireless communication interface 418 to the sleep state could involve the wireless communication interface 418 powering down and/or discontinuing other aspects of its operation as well or instead, which could also help to conserve power.

[0084] In this implementation, once the CPU 402 has put at least the wireless communication interface 418 in the sleep state, the CPU 402 could also put itself into the sleep state. Transitioning the CPU 402 to the sleep state could involve the CPU 402 powering down various aspects of its own operation as noted above, such as halting its CPU clock and various computations, which could also help to conserve battery power. In the sleep state, however, the CPU 402 may still retain some rudimentary operation, such as running a realtime internal counter and also monitoring for receipt of interrupt signaling from other device components that may be seeking to communicate with the CPU 402 (e.g., in response to user pressing of a button or uttering the wake word).

[0085] In this device sleep state, the CPU 402 could operate to periodically wake up the wireless communication interface 418 to cause the wireless communication interface 418 to newly scan for wireless coverage. The CPU 402 could do this by using or applying its internal counter to measure passage of time corresponding with a defined time interval or sleep cycle of N seconds, and upon passage of the N seconds, could itself transition back to its full power state and then signal to the wireless communication interface 418 in a manner to which the wireless communication interface 418 would respond by transitioning back to its full power state and re-scanning for wireless coverage. If the wireless communication interface 418 thereby finds sufficiently strong wireless coverage, it could proceed to connect and could accordingly signal its new connected state to the CPU 402. Whereas, if the wireless communication interface 418 does not find sufficiently strong wireless coverage, it could responsively inform the CPU 402 that the device remains out of coverage, and the wireless communication interface 418 and CPU 402 could both responsively return to their sleep states. Then the CPU 402 could repeat this process, again measuring passage of N seconds, and so forth.

[0086] As noted above, the challenge with this process is how to set the sleep cycle. Namely, it would be best to set that sleep cycle to a duration that is not too long, so that, in case a user of the device 302 has just briefly taken the device 302 out of coverage (e.g., to take a short break) and then returns to coverage, there would be minimal delay (no more than N seconds) before the device reacquires connectivity. On the other hand, it would also be best to not set the sleep cycle to a duration that is too short, since a short sleep cycle could contribute to battery drain as the device 302 frequently wakes up and scans for wireless coverage.

[0087] As noted above, a technical solution to this problem is to have the device progressively 302 increase its sleep cycle while the device remains out of wireless coverage. Namely, over time in response to the device 302 remaining out of wireless coverage of the system 100, the device 302 could progressively increase its sleep cycle from a duration N to duration greater than N.

[0088] Without limitation, for instance, the device 302 could start with a sleep cycle on the order of 2 seconds. In response to passage of a period of time encompassing multiple sleep cycles, (e.g., after 30 seconds, a minute, or another period) and the device 302 remaining out of wireless coverage, the device 302 could then increase its sleep cycle to 4 seconds. Further, in response to passage of yet another period of time encompassing multiple sleep cycles (possibly the same 30 seconds, minute, or other period, or possibly a greater or lesser duration) and the device 302 still remaining out of wireless, the device 302 could then further increase its sleep cycle to 8 seconds. And the device 302 could continue this progressive increasing of its sleep cycle responsive to remaining out of wireless coverage, until reaching a configured maximum sleep cycle, perhaps on the order of a minute or so. Of course, the durations noted here are merely examples; other examples could be possible as well.

[0089] To carry out this process in practice, the CPU 402 could progressively increase the amount of time that the CPU 402 waits in accordance with its internal counter. For instance, with the same example, when the CPU 402 first learns that the device 302 is out of wireless coverage, the CPU 402 could put the wireless communication interface 418 to sleep and could itself go to sleep and apply its internal counter to measure passage of a sleep cycle of 2 seconds, and upon passage of that time, the CPU 402 could then wake up itself and wake up the wireless communication interface 418, to trigger the wireless communication device 418 newly scanning for coverage. In response to passage of an amount of time (e.g., a count of sleep cycles) encompassing multiple such sleep cycles and the device still being out of wireless coverage, the CPU 402 could then repeat this process but could increase the sleep cycle to 4 seconds, and so forth.

[0090] Figure 5 is a flow chart depicting an example method for controlling sleep cycle of a battery-powered wireless communication device (WCD) such as user device 302 or another device. As shown in Figure 5, at block 500, the method includes the WCD detecting that the WCD has lost wireless coverage. And at block 502, the method then includes, responsive to the detecting, the WCD transitioning to a sleep state and the WCD then periodically waking from the sleep state to scan for wireless coverage, with the periodic waking occurring according to a sleep cycle defining how long the WCD remains in the sleep state between instances of the WCD waking to scan for wireless coverage. Further, at block 504, the method includes, while the WCD remains out of wireless coverage, the WCD progressively increasing the sleep cycle.

[0091] In line with the discussion above, the WCD in this method could be a wearable device, and the method could be carried out while the WCD is being worn by a user. Further, as discussed above, the act of detecting that the WCD has lost wireless coverage could involve detecting that the WCD has lost WiFi coverage.

[0092] As additionally discussed by way of example above, the WCD could comprise a host processor (e.g., CPU), in which case the detecting, transitioning, and progressively increasing could be carried out by the host processor. For instance, the act of detecting that the WCD has lost wireless coverage could involve the host processor receiving from a wireless communication interface of the WCD a signal indicating that the WCD has lost wireless coverage. And each instance of the WCD waking from the sleep state to scan for wireless coverage could involve the host processor signaling to the wireless communication interface to cause the wireless communication interface to wake up and scan for wireless coverage.

Further, as discussed above, the act of progressively increasing the sleep cycle could involve (i) setting the sleep cycle to a first duration, (ii) after passage of multiple instances of the sleep cycle of the first duration, increasing the sleep cycle to a second duration longer than the first duration, (iii) after passage of multiple instances of the sleep cycle of the second duration, increasing the sleep cycle to a third duration longer than the second duration, and so forth, possibly until reaching a maximum sleep cycle.

The present disclosure also contemplates a WCD being configured to carry out this or other methods. In line with the discussion above, for instance, such a WCD could include a wireless a wireless communication interface, a battery, a processor, non-transitory data storage, and program instructions stored in the non-transitory data storage and executable by the processor to carry out the operations of the method. Further, the disclosure also contemplates a non-transitory computer-readable medium having stored thereon (e.g., being encoded with or otherwise embodying) program instructions executable by a processor to cause a battery-powered WCD to carry out such operations.

[0093] Exemplary embodiments have been described above. Those skilled in the art will understand, however, that changes and modifications may be made to these embodiments without departing from the true scope and spirit.

Claims

CLAIMS What is claimed is:

1. A method for controlling sleep cycle of a battery-powered wireless communication device (WCD), the method comprising: detecting by the WCD that the WCD has lost wireless coverage; responsive to the detecting, transitioning by the WCD into a sleep state and then periodically waking by the WCD from the sleep state to scan for wireless coverage, wherein the periodic waking is according to a sleep cycle defining how long the WCD remains in the sleep state between instances of the WCD waking to scan for wireless coverage; and while the WCD remains out of wireless coverage, progressively increasing by the WCD the sleep cycle.

2. The method of claim 1, wherein the WCD is a wearable device, the method being carried out while the WCD is being worn by a user.

3. The method of claim 1, wherein detecting that the WCD has lost wireless coverage comprises detecting that the WCD has lost WiFi coverage.

4. The method of claim 1, wherein the WCD comprises a host processor, and wherein the detecting, transitioning, and progressively increasing are carried out by the host processor.

5. The method of claim 4, wherein detecting that the WCD has lost wireless coverage comprises receiving by the host processor from a wireless communication interface of the WCD a signal indicating that the WCD has lost wireless coverage.

6. The method of claim 4, wherein each instance of waking by the WCD from the sleep state to scan for wireless coverage comprises the host processor signaling to a wireless communication interface of the WCD to cause the wireless communication interface to wake up and scan for wireless coverage.

7. The method of claim 1, wherein progressively increasing the sleep cycle comprises: setting the sleep cycle to a first duration; after passage of multiple instances of the sleep cycle of the first duration, increasing the sleep cycle to a second duration longer than the first duration; and after passage of multiple instances of the sleep cycle of the second duration, increasing the sleep cycle to a third duration longer than the second duration.

8. A wireless communication device (WCD) comprising: a wireless communication interface; a battery; a processor; non-transitory data storage; and program instructions stored in the non-transitory data storage and executable by the processor to carry out operations comprising: detecting that the WCD has lost wireless coverage, responsive to the detecting, transitioning into a sleep state and then periodically waking from the sleep state to scan for wireless coverage, wherein the periodic waking is according to a sleep cycle defining how long the WCD remains in the sleep state between instances of the WCD waking to scan for wireless coverage; and while the WCD remains out of wireless coverage, progressively increasing the sleep cycle.

9. The WCD of claim 8, wherein the WCD is a wearable device and wherein the program instructions are executable by the processor to carry out the operations while the WCD is being worn by a user.

10. The WCD of claim 9, wherein the WCD is used in healthcare facilities.

11. The WCD of claim 8, wherein detecting that the WCD has lost wireless coverage comprises detecting that the WCD has lost WiFi coverage.

12. The WCD of claim 8, wherein detecting that the WCD has lost wireless coverage comprises receiving by the processor from the wireless communication interface a signal indicating that the WCD has lost wireless coverage.

13. The WCD of claim 8, wherein each instance of waking by the WCD from the sleep state to scan for wireless coverage comprises the processor signaling to the wireless communication interface to cause the wireless communication interface to wake up and scan for wireless coverage.

14. The WCD of claim 8, wherein progressively increasing the sleep cycle comprises: setting the sleep cycle to a first duration; after passage of multiple instances of the sleep cycle of the first duration, increasing the sleep cycle to a second duration longer than the first duration; and after passage of multiple instances of the sleep cycle of the second duration, increasing the sleep cycle to a third duration longer than the second duration.

15. A non-transitory computer-readable medium having stored thereon program instructions executable by a processor to cause a battery-powered wireless communication device (WCD) to carry out operations comprising: detecting that the WCD has lost wireless coverage; responsive to the detecting, transitioning into a sleep state and then periodically waking from the sleep state to scan for wireless coverage, wherein the periodic waking is according to a sleep cycle defining how long the WCD remains in the sleep state between instances of the WCD waking to scan for wireless coverage; and while the WCD remains out of wireless coverage, progressively increasing the sleep cycle.

16. The non-transitory computer-readable medium of claim 15, wherein the WCD is a wearable device.

17. The non-transitory computer-readable medium of claim 15, wherein non- transitory computer-readable medium is disposed in the WCD.

18. The non-transitory computer-readable medium of claim 15, wherein detecting that the WCD has lost wireless coverage comprises a host processor of the WCD receiving from a wireless communication interface of the WCD a signal indicating that the WCD has lost wireless coverage.

19. The non-transitory computer-readable medium of claim 15, wherein each instance of the WCD waking from the sleep state to scan for wireless coverage comprises a host processor of the WCD signaling to a wireless communication interface of the WCD to cause the wireless communication interface to wake up and scan for wireless coverage.

20. The non-transitory computer-readable medium of claim 15, wherein progressively increasing the sleep cycle comprises: setting the sleep cycle to a first duration; after passage of multiple instances of the sleep cycle of the first duration, increasing the sleep cycle to a second duration longer than the first duration; and after passage of multiple instances of the sleep cycle of the second duration, increasing the sleep cycle to a third duration longer than the second duration.