Methods and systems for disabling sleep alarm based on automated wake detection

Techniques are disclosed for facilitating disabling an alarm in response to particular types of activity-indicative data. More specifically, activity-indicative data (e.g., sensor data or input(s) can be detected prior to a preset alarm time. Upon determining, based on the activity-indicative data, that a wakefulness condition is satisfied (e.g., that the activity-indicative data corresponds to one or more predefined characteristics), a disablement query can be displayed that includes an option to disable the alarm. In response to detecting a selection of the option, the alarm can be disabled such that the alarm stimuli is not to be presented at the preset alarm time.

FIELD OF INVENTION

The present disclosure relates generally to facilitating intelligent and preemptive disablement of an alarm. More specifically, sensor and/or interaction data is monitored to detect measurements corresponding with a wakefulness state, which triggers an alarm disablement process.

BACKGROUND

Various devices have alarm capabilities, such that a user can identify an alarm time, and the device will output an audio signal at the alarm time. However, most alarms are rather inflexible, in that the alarm reliably sounds irrespective of a context.

SUMMARY

In some embodiments, an electronic device is provided that includes one or more data processors and a non-transitory computer readable storage medium containing instructions which, when executed on the one or more data processors, cause the one or more data processors to perform a set of actions. The set of actions include accessing alarm data that indicates that an alarm is enabled to present an alarm stimulus at a preset alarm time and, prior to the preset alarm time, collecting activity-indicative data. The activity-indicative data includes one or more measurements collected by a sensor of the electronic device or one or more inputs received at an interface of the electronic device. The set of actions also includes accessing a wakefulness condition that is configured to be satisfied when the activity-indicative data has one or more characteristics that are specified in the wakefulness condition. The set of actions further includes determining, based on the activity-indicative data and at the electronic device, that the wakefulness condition is satisfied and, in response to the determination that the wakefulness condition is satisfied, displaying a disablement query that includes an option to disable the alarm. The set of actions still further includes detecting a selection, responsive to the disablement query, of the option to disable the alarm and, in response to receipt of the selection, disabling the alarm such that the alarm stimulus is not to be presented at the preset alarm time.

In some embodiments, a computer-program product is provided that is tangibly embodied in a non-transitory machine-readable storage medium. The computer-program product including instructions configured to cause one or more data processors to perform a set of actions. The set of actions includes accessing, at an electronic device, alarm data that indicates that an alarm is enabled to present an alarm stimulus at a preset alarm time and, prior to the preset alarm time, collecting, at the electronic device, activity-indicative data. The activity-indicative data includes one or more measurements collected by a sensor of the electronic device or one or more inputs received at an interface of the electronic device. The set of actions also includes accessing a wakefulness condition that is configured to be satisfied when the activity-indicative data has one or more characteristics that are specified in the wakefulness condition and determining, based on the activity-indicative data and at the electronic device, that the wakefulness condition is satisfied. The set of actions further includes, in response to the determination that the wakefulness condition is satisfied, displaying, by the electronic device, a disablement query that includes an option to disable the alarm and detecting a selection, responsive to the disablement query, of the option to disable the alarm. The set of actions still further includes, in response to receipt of the selection, disabling the alarm such that the alarm stimulus is not to be presented at the preset alarm time.

In some embodiments, a method is provided. Alarm data is accessed at a device, the alarm data indicating that an alarm is enabled to present an alarm stimulus at a preset alarm time. Prior to the preset alarm time, activity-indicative data is collected at the electronic device. The activity-indicative data includes one or more measurements collected by a sensor of the electronic device or one or more inputs received at an interface of the electronic device. A wakefulness condition is accessed that is configured to be satisfied when the activity-indicative data has one or more characteristics that are specified in the wakefulness condition. It is determined, based on the activity-indicative data and at the electronic device, that the wakefulness condition is satisfied. In response to the determination that the wakefulness condition is satisfied, a disablement query is displayed by the electronic device. The disablement query includes an option to disable the alarm. A selection, responsive to the disablement query, of the option to disable the alarm is detected. In response to receipt of the selection, the alarm is disabled such that the alarm stimulus is not to be presented at the preset alarm time.

DETAILED DESCRIPTION

In some embodiments, a device (e.g., a smart phone or smart wearable device) enters a wakefulness-monitoring state during a time period preceding a time of an alarm (e.g., four hours before the time of the alarm). In the wakefulness-monitoring state, activity-indicative data (e.g., sensor data and/or input data) is monitored. Each of one or more conditions can be evaluated using the sensor data and/or interaction data. Each of the one or more conditions can be configured to be satisfied upon detecting (for example) sensor data corresponding to of a magnitude above one or more corresponding thresholds. For example, a condition can be configured to be satisfied when: at least a predefined number of consecutive steps have been detected as estimated using sensor data from (for example) a device's accelerometer(s) and/or gyroscope, a rotation of a device exceeds a predefined angle, a device is unlocked via entry of a pass code or biometric input, a device is in an unlocked state for at least a predefined time, a power source for a device has changed (e.g., a device is unplugged), and/or data collected by an optical sensor detects that a wearable device indicates that it has transitioned from a state indicating that the device is not being worn to a state indicating that it is being worn by a user. It will be appreciated that a condition can depend on a variable derived from sensor data, such as an elbow angle, angle of a user's forearm relative to the horizon, or a step count

In some instances, a condition is based on detection of multiple types of actions, potentially in a specific order. For example, a condition can be configured to be satisfied when motion data collected on a wearable indicates that a user moved from sitting to standing and that other subsequent motion data indicated that the user then walked at least 20 steps. As another example, a condition can be configured to be satisfied when motion data indicates that a device was picked up from a horizontal position and that the device then moved at least 40 feet. A condition may be configured to include Boolean operands (e.g., AND, OR, etc.).

Upon detecting that a condition (or combination of conditions) is satisfied, the device can present a notification that requests input as to whether to disable (or deactivate) the alarm. For example, the notification can state: “Do you want to turn off your 7:00 am alarm?” and include an input option that, when selected via corresponding user input, corresponds to an instruction to disable the alarm. Upon receiving this instruction, the device can disable (e.g., turn off) and/or disable the alarm. In instances when the device is configured to synchronize alarms across multiple devices (e.g., each associated with a same user or user profile), the device can transmit an instruction (e.g., to a coordinating remote server or to one or more of the multiple devices) that corresponds to an instruction to disable the alarm (e.g., and specifically identifying the alarm).

Thus, the device can intelligently infer when a user is awake by monitoring and assessing activity-indicative data (e.g., sensor measurement(s) and/or input data). More specifically, the inference can be positively made in response to detecting activity-indicative data that corresponds to awake profiles as set forth in one or more conditions. The inference can be confirmed upon receiving input from a user, in response to a notification, that indicates that the alarm is to be disabled.

Disclosed techniques have various advantages. For example, intelligently inferring when a user is awake and triggering an alarm-disablement process can avoid annoying a user with a superfluous alarm and further not require the user to remember to interact with the phone to disable the alarm before it is presented. Meanwhile, the actual disablement itself can be semi-automated, such that an alarm is not disabled until user input is received that corresponds to an instruction to disable the alarm. This semi-automated approach reduces the potentially disastrous (in the user's life) consequence of a false-positive wake detection, in which it is inferred that the user is awake, though the alarm is still needed.

Further, the monitoring of activity-indicative data and condition assessment can be restricted to a particular time window preceding an alarm time. This timing constraint can reduce use of processing resources and a quantity of notifications presented to users.

FIG. 1illustrates an example of a setting in which activity-indicative data is detected that triggers a disablement of an alarm. In the illustrated instance, two devices (a smart watch105and a smart phone110) are associated with a profile of a single user115. An alarm for 7 am is enabled for the profile in response to a previous detection of input at smart phone110that has set and/or enabled the alarm. Smart watch105and smart phone110can synchronize alarm data, such that alarm data identifying the enabled 7 am alarm is stored at both smart watch105and smart phone110. The input and alarm data can further indicate that the alarm is designated as a sleep alarm (or bedtime alarm), which can indicate that wakefulness monitoring and a process for wakefulness-triggered alarm disablement are to be performed.

Smart watch105and smart phone110can commence assessing activity-indicative data for indications as to whether to make a wakefulness inference (inferring that a user is awake for the day) at a predefined time before the alarm time. The alarm time can include a preset alarm time, which can correspond to one identified based on input received via an interface of a device (e.g., of smart watch105or smart phone110). Specifically, such assessments can begin thirty minutes before the alarm time, which is 5:30 am. In some instances, the assessment can be performed (for example) at regular intervals (e.g., every minute based on data from the last three minutes or other time period) or continuously.

In the depicted instance, user115has moved from a laying-down position to sitting. A gyroscope, magnetometer and/or accelerometer in smart watch105can detect the corresponding motion. These measurements can be assessed using a wakefulness condition. In this instance, the gyroscope measurements can be a first predefined threshold in a first condition, but the first condition requires not an only above-threshold gyroscope measurement but also a subsequent number of steps in a walking session that exceeds a second predefined threshold (e.g., having exceed the second predefined threshold within a predefined time window from the above-threshold gyroscope measurement). Thus, the first condition is not yet satisfied.

Meanwhile, user115has also unplugged smart phone110from a charging cord120. A second condition can be configured to be satisfied when a device is disconnected from a power source and when the device is moved by at least 50 feet within a subsequent 20-minute time period. Thus, the second condition is not yet satisfied.

User115further has just completed unlocking smart phone110via entry of a passcode. A third condition can be configured to be satisfied when a device transitions from a locked to an unlocked state. Thus, the third condition is satisfied.

Upon detecting that a wakefulness condition is satisfied, a notification can be presented on a display of smart phone110that recites: “Turn off upcoming 7 am alarm?” along with a first input option (e.g., a first virtual button) configured to receive input corresponding to a confirmatory response (“Yes”) and a second input option (e.g., a second virtual button) configured to receive input corresponding to a negative response (“No”).

Here, user115is selecting the “Yes” virtual button. This response can cause smart phone110to disable the 7 am, such that alarm stimuli (e.g., alarm audio and/or haptic signals) are not presented at 7 am. Further, smart phone110can transmit an indication that the 7 am alarm is to be disabled either directly or indirectly to smart watch105, such that the 7 am alarm data stored at smart watch105is disabled. Thus, user115is not unnecessarily annoyed with alarm stimuli at 7 am. Upon disablement, wakefulness monitoring associated with the 7 am alarm can cease.

FIG. 2is an example schematic diagram of an electronic device200(e.g., a smart phone) configured to facilitate selective disablement of alarms in accordance with an embodiment of the present invention. Electronic device200can include a primary processing subsystem202, a storage subsystem204, a user interface206, one or more connection components (e.g., transceiver subsystem208), a power subsystem212, environmental sensors214and a motion co-processor205. Electronic device200can also include other components (not explicitly shown).

Primary processing subsystem202can be implemented as one or more integrated circuits, e.g., one or more single-core or multi-core microprocessors or microcontrollers, examples of which are known in the art. In operation, primary processing subsystem202can control the operation of electronic device200. In various embodiments, primary processing subsystem202can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in primary processing subsystem202and/or in storage media such as storage subsystem204.

Through suitable programming, primary processing subsystem202can provide various functionality for electronic device200. For example, primary processing subsystem202can execute code to facilitate semi-automated disablement of an alarm. The facilitation can include, for example, detecting an indication that a wakefulness condition has been satisfied and presenting a query as to whether a particular alarm is to be disabled. Primary processing subsystem202can detect and characterize any responsive input, which can be communicated to an alarm-controlling module. Further, primary processing subsystem202can generate, enable and/or disable alarms upon receiving corresponding instructions. Primary processing subsystem202can trigger presentation of alarm stimuli at an alarm time of an enabled alarm. In some instances, primary processing subsystem202evaluates each of one or more wakefulness conditions based on activity-indicative data. In some instances, at least some or all of the evaluations of one or more wakefulness conditions is instead performed by motion co-processor205(e.g., to facilitate condition evaluations while electronic device200is in a sleep or low-power state).

Storage subsystem204can be implemented, e.g., using magnetic storage media, flash memory, other semiconductor memory (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination of media, and can include volatile and/or non-volatile media.

In some embodiments, storage subsystem204can store code or instructions for an operating system221and/or one or more application programs (or apps)222to be executed by primary processing subsystem202. Storage subsystem204can store sensor data223, which can include data collected by one or more of environmental sensors214. Storage subsystem204can include modules (e.g., state detector224, step counter225, light detector226and sleep alarm controller228), each of which can be configured as an individual app, a part of an app, a function or other piece of executable code.

State detector224can be configured to detect one or more states of electronic device200, such as charging state (i.e., whether it is connected to a charging source), a sleep state (i.e., whether the device is in a low-power sleep state), and/or a locked state (i.e., whether the device is in a locked state, such that a target biometric or passcode input is required to avail various basic app functionalities). The detections can be made based on (for example) data from power subsystem212, data from connector interface210, monitoring of past state transitions and/or assessments of current state configurations.

Step counter225can be configured to use data from one or more environmental sensors214to detect individual user steps. For example, sensor data can be compared to one or more thresholds or profiles to determine whether a step occurred. Each detected step can be assigned to an epoch that represents continuous walking based on (for example) a continuity of movement (e.g., acceleration and/or deceleration values staying beneath a predefined acceleration threshold and/or a velocity values remaining above a predefined velocity threshold) and/or short interval between steps (e.g., with times between consecutive steps remaining below a predefined interval threshold). In some instances, step counter225first identifies a stepping epoch that include multiple steps (e.g., at least 8) based on frequencies of signals from one or more sensors (e.g., an accelerometer, magnetometer, barometer, gyroscope and/or compass) and then back-assigns steps to the epoch and continues to expand the epoch with detection of any additional steps (e.g., detected based on a step frequency determined for the epoch and sensor data).

Light detector226can be configured to measure an intensity of ambient light. Light detector226can include one or more photosensors to detect an intensity of light in one or more spectrum (e.g., visible light and/or infrared light).

Sleep alarm controller228can be configured to use sensor data, one or more device states, detected steps, one or more detected light intensity and/or other data (e.g., input received at electronic device200) to determine whether a wakefulness condition is satisfied. In some instances, motion co-processor205executes code of sleep alarm controller228to assess one or more wakefulness conditions. Upon detecting that a wakefulness condition is satisfied, sleep alarm controller228can be configured to disable an alarm in an automated or semi-automated manner. With regard to the semi-automated instance, sleep alarm controller228can instruct primary processing subsystem202to present a stimulus that corresponds to a query to a user as to whether to disable an alarm. When a response corresponding to an instruction to disable the alarm is received, sleep alarm controller228can disable the alarm such that alarm stimuli are not presented at the alarm time.

Transceiver subsystem208can allow electronic device200to communicate wirelessly with various electronic devices. Transceiver subsystem208can include a component, such as an antenna (e.g., a radio frequency identification (RFID) tag antenna229) and supporting circuitry to enable data communication over a wireless medium, e.g., using near-field communication (NFC), Bluetooth Low Energy, Bluetooth® (a family of standards promulgated by Bluetooth SIG, Inc.), Zigbee, Wi-Fi (IEEE 802.11 family standards), or other protocols for wireless data communication. In some embodiments, transceiver subsystem208can implement a proximity sensor that supports proximity detection (e.g., via NFC or Bluetooth Low Energy) through a detection of a signal, estimation of signal strength and/or other protocols for determining proximity to another electronic apparatus.

RFID tag antenna229can include, for example, an NFC antenna and/or a loop antenna with one or more loops. In some instances, a length of antenna is less than, e.g., 1, 2, 5 or 10 cm. RFID tag antenna229can include or be a passive, receiving antenna. An operating frequency of RFID tag antenna229can include a low frequency (e.g., 125-134 kHz), high frequency (e.g., between 10-30 MHz, such as 13.56 MHz) or ultra-high frequency (e.g., greater than 800 MHz).

In some embodiments, transceiver subsystem208can provide NFC capability, e.g., implementing the ISO/IEC 18092 standards or the like; NFC can support wireless data exchange between devices over a very short range (e.g., 20 centimeters or less). Transceiver subsystem208can be implemented using a combination of hardware (e.g., driver circuits, antennas, modulators/demodulators, encoders/decoders, and other analog and/or digital signal processing circuits) and software components. Multiple different wireless communication protocols and associated hardware can be incorporated into transceiver subsystem208. In some instances, a same component of transceiver subsystem208can serve to receive incoming signals and transmit outgoing signals. In some instances, different components handle incoming and outgoing signals.

In some embodiments, electronic device200includes a power subsystem212that can provide power management capabilities and power for electronic device200. Power subsystem212can include circuitry to distribute received, converted and/or stored power to other components of electronic device200that require electrical power.

In some (but not other instances), power subsystem212can include a battery230(e.g., a rechargeable battery) and can also include circuitry operable to charge battery230. Thus, in some embodiments, power subsystem212can include a “wireless” charger, such as an inductive charger, to charge battery230. This capability can be used to extend a time during which electronic device200can transmit data (e.g., such that data can be transmitted even when it is not sufficiently close to be powered by a nearby electronic device) and/or can allow electronic device200to communicate using a different communication protocol and/or over a larger range.

In some embodiments, power subsystem212can control power distribution to components within electronic device200to manage power consumption efficiently. For example, power subsystem212can automatically place electronic device200into a “hibernation” or “sleep” state when it is determined or inferred that no electronic device is nearby (e.g., due to a lack of incoming signals). The hibernation or sleep state can serve to inhibit or pause outgoing transmissions of data. In some instances, a device is also in a “locked” state while it is in a hibernation or sleep state and a normal-operation state, in that biometric data or character passcode that matches a stored unlocking data is required to unlock the device and avail basic device features (e.g., use of primary functions of multiple apps, email apps, ability to place a non-emergency call, etc.).

Power subsystem212can also provide other power management capabilities, such as regulating power consumption of other components of electronic device200based on the source and amount of available power, monitoring stored power in battery230, and so on.

In some embodiments, control functions of power subsystem212can be implemented using programmable or controllable circuits operating in response to control signals generated by primary processing subsystem202in response to program code executing thereon, or as a separate microprocessor or microcontroller. Power subsystem212can be configured to detect whether a power source is a battery or another source (e.g., an AC source). Power subsystem212can be configured to detect whether (or when) electronic device200is charging and/or connecting to a physical charging element (e.g., a charging cord).

In some instances, electronic device200includes one or more environmental sensors214, such as one or more electronic, mechanical, electromechanical, optical, or other devices that provide information related to internal external conditions around electronic device200. Environmental sensors214in some embodiments can provide digital signals to primary processing subsystem202, e.g., on a push (e.g., streaming or regular-communication) basis or in response to polling by processing subsystem202as desired. Any type and combination of sensors can be used; shown by way of example are an accelerometer232, a GPS receiver234, a gyroscope236, a magnetometer238and an ambient light sensor240. One or more of environmental sensors214(e.g., accelerometer232, GPS receiver234, gyroscope236and magnetometer238) can be configured to detect information about a motion and/or location of electronic device200.

Accelerometer232can detect an acceleration of electronic device200(e.g., generally or in each of one or more directions). For example, accelerometer232can include a three-axis or six-axis accelerometer. Accelerometer data can identify (for example) an acceleration experienced along each of one or more (e.g., three or six) axes and can further identify an orientation of electronic device200. GPS receiver234can receive communications from multiple GPS satellites and estimate a location of electronic device200. It will be appreciated that other sensors can also be included in addition to or instead of these examples.

Gyroscope236can include, for example, a MEMS gyroscope that detects an orientation of electronic device200. For example, gyroscope236can identify an angular position of electronic device200along one or more (e.g., three) axes.

Magnetometer238can be configured to measure characteristics of a magnetic field. Such characteristics can be used to identify geospatial directions (e.g., identifying which direction, relative to electronic device200) is north.

Ambient light sensor240can include one or more photosensors to identify a light intensity of an ambient environment. The intensity, some instances, is mapped to one or more bands of light intensity, which range from dark-to-light categories. It will be appreciated that electronic device200can alternatively or additionally include one or more additional types of sensors, such as a barometer that can be used to detect altitude data.

In some instances, one or more environmental sensors214can be at least partly controlled and/or accessible to motion co-processor205. Motion co-processor205can be configured to always (so long as electronic device200is powered on) receive power from power subsystem212, such that it is always on to receive and process sensor data from one or more environmental sensors214. For example, one or more environmental sensors214can receive and affect an instruction from motion co-processor205to begin collecting measurements and/or reporting measured data. In a particular instance, motion co-processor205can subscribe to receive data from one or more sensors (e.g., upon determining that a current time is within a predefined time from an alarm time). The sensor(s) can then transmit data (e.g., in a streaming fashion or in accordance with a transmission schedule) in a communication channel, such that it can be assessed (e.g., at motion co-processor205) to determine whether a wakefulness condition is satisfied. In some instances, motion co-processor pulls data from the sensor(s). For example, motion co-processor205maybe configured to detect a quantity of time blocks (e.g., of specified duration) across which a minimum, median or mean sensor reading is above a predefined threshold. As another example, motion co-processor205may be configured to detect a moving average (or moving median) of sensor measurements.

Motion co-processor205can be implemented as one or more integrated circuits, e.g., one or more single-core or multi-core microprocessors or microcontrollers, examples of which are known in the art. Motion co-processor205can be configured to be independent from primary processing subsystem202. In operation, motion co-processor205can control at least some of the operation of electronic device200. In various embodiments, motion co-processor205can execute a variety of programs (e.g., relating to capture and/or process of sensor data and/or motion data) in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in motion co-processor205and/or in storage media such as storage subsystem204.

Through suitable programming, motion co-processor205can provide various functionality for electronic device200. For example, motion co-processor205can execute code to facilitate semi-automated disablement of an alarm. The facilitation can include, for example, collecting data from one or more sensors and determining whether a wakefulness condition is satisfied based on the collected data.

User interface206can include any combination of input and output devices. In some instances, a user can operate input devices of user interface206to invoke the functionality of electronic device200and can view, hear, and/or otherwise experience output from electronic device200via output devices of user interface206. Examples of input devices include microphone248, touch sensor252, and camera250. Examples of output devices include display254, speakers256, and haptic output generator258.

Microphone248can include any device that converts sound waves into electronic signals. In some embodiments, microphone248can be sufficiently sensitive to provide a representation of specific words spoken by a user; in other embodiments, microphone248can be usable to provide indications of general ambient sound levels without necessarily providing a high-quality electronic representation of specific sounds.

Camera250can include, e.g., a compact digital camera that includes an image sensor such as a CMOS sensor and optical components (e.g. lenses) arranged to focus an image onto the image sensor, along with control logic operable to use the imaging components to capture and store still and/or video images. Images can be stored, e.g., in storage subsystem204and/or transmitted by electronic device200to other devices for storage. Depending on implementation, the optical components can provide fixed focal distance or variable focal distance; in the latter case, autofocus can be provided. In some embodiments, camera227can be disposed along an edge of a face member of a device, e.g., the top edge, and oriented to allow a user to capture images of nearby objects in the environment such as a bar code or QR code. In other embodiments, camera250can be disposed on the front surface of a device face member, e.g., to capture images of the user. Zero, one, or more cameras can be provided, depending on implementation.

Touch sensor252can include, e.g., a capacitive sensor array with the ability to localize contacts to a particular point or region on the surface of the sensor and in some instances, the ability to distinguish multiple simultaneous contacts. In some embodiments, touch sensor252can be overlaid over display254to provide a touchscreen interface, and processing subsystem202can translate touch events (including taps and/or other gestures made with one or more contacts) into specific user inputs depending on what is currently displayed on display254.

Display254can be implemented using compact display technologies, e.g., LCD (liquid crystal display), LED (light-emitting diode), OLED (organic light-emitting diode), or the like. In some embodiments, display254can incorporate a flexible display element or curved-glass display element, allowing electronic device200to conform to a desired shape. One or more speakers256can be provided using small-form-factor speaker technologies, including any technology capable of converting electronic signals into audible sound waves. In some embodiments, speakers256can be used to produce tones (e.g., beeping or ringing) and can but need not be capable of reproducing sounds such as speech or music with any particular degree of fidelity. Haptic output generator258can be, e.g., a device that converts electronic signals into vibrations; in some embodiments, the vibrations can be strong enough to be felt by a user wearing electronic device200but not so strong as to produce distinct sounds.

In some embodiments, user interface206can provide output to and/or receive input from an auxiliary device such as a headset. For example, audio jack260can connect via an audio cable (e.g., a standard 2.5-mm or 2.5-mm audio cable) to an auxiliary device. Audio jack260can include input and/or output paths. Accordingly, audio jack260can provide audio to the auxiliary device and/or receive audio from the auxiliary device. In some embodiments, a wireless connection interface can be used to communicate with an auxiliary device.

One or more output devices can be used to present a query as to whether to disable an alarm. For example, upon determining that a wakefulness condition is satisfied, speakers256can emit a tone, haptic output generator258can output a vibration, and display254can present text and/or input options (e.g., “Disable 7:30 am alarm?” with a “Yes” and “No” virtual option). One or more input devices can be configured to receive input that facilitates initial setting of an alarm, enablement of an alarm and/or responding to a disablement query.

It will be appreciated that electronic device200is illustrative and that variations and modifications are possible. For example, transceiver subsystem208can include a different type of antenna209and/or can include one or more frequency-tuning components (e.g., capacitors). As another example, environmental sensors214can include one or more other types of sensors (e.g., a temperature monitor). As yet another example, storage subsystem204can include code to perform calling and/or email functions.

FIG. 3is an example schematic diagram of a wearable electronic device300according to an embodiment of the present invention. One or more components of wearable electronic device300can parallel or complement similarly numbered components of electronic device200. Wearable electronic device300can also include other components (not explicitly shown).

Wearable electronic device300can include (for example) a necklace, headband, clip, belt, bracelet, watch, pair of glasses, armband, or ear piece. In some embodiments, wearable electronic device300can accept a variety of bands, straps, or other retention mechanisms (collectively, “bands”). These bands can be removably connected to the electronic device by a lug that is accepted in a recess or other aperture within the device and locks thereto. The lug can be part of the band or can be separable (and/or separate) from the band. Generally, the lug can lock into the electronic device's recess and thereby maintain connection between the band and device. The user can release a locking mechanism to permit the lug to slide or otherwise move out of the recess. In some embodiments, the recess can be formed in the band and the lug can be affixed or incorporated into the device.

Wearable electronic device300can include one or more components not included in the embodiment of electronic device200as depicted inFIG. 2. For example, wearable electronic device300can include one or more biometric sensors, such as a heart rate monitor342, temperature sensor344and blood oxygen sensor346. One or more of the biometric sensors (e.g., temperature sensor344and/or blood oxygen sensor346) can be included in a band of wearable electronic device (e.g., to reduce an influence of heat produced by a main portion of a device and/or to increase an area over which measurements can be collected).

Heart rate monitor342can be configured to emit one or more lights and to include one or more photodiodes to collect reflected portions of the light. Troughs in a time series of an intensity of the collected light can be indicative of a heart beat. Thus, a set of times of heart beats can be collected and used to identify a heart rate.

Storage subsystem304can include a biometric monitor327that can access and process data from the biometric sensors. In some instances, biometric monitor327is configured to transform raw biometric-related measurements to physiologically relevant indicators. For example, a time series of light intensities collected at heart rate monitor342can be transformed into a heart rate. The biometric data (e.g., a heart rate, body temperature and/or blood oxygen level) can be used in evaluation of one or more wakefulness conditions to determine whether to infer that a user is awake.

Further, biometric data can be used by state detector324to identify whether wearable electronic device300is in a “worn” state indicating that it is being worn by a user. For example, it can be inferred that wearable electronic device300is being worn when a heart rate and/or blood oxygen level is detectable and/or when a biometric variable (e.g., heart rate, blood oxygen level and/or temperature) is within a physiological range.

It will be appreciated that wearable electronic device300is illustrative and that variations and modifications are possible. For example, in the depicted instance, wearable electronic device300lacks a motion co-processor, as included in the embodiment of electronic device200depicted inFIG. 2. However, it will be appreciated that, in some instances, wearable electronic device300can include a motion co-processor.

FIG. 4shows a flowchart of a process400for disabling an alarm in accordance with some embodiments of the invention. Part of all of process400can be performed, for example, at electronic device200and/or wearable electronic device300.

Process400begins at block405where alarm data is accessed. The alarm data can correspond to an enabled alarm, indicating an alarm that is configured to trigger an output stimulus (e.g., audio and/or haptic stimulus) at one or more devices (e.g., at the device(s) performing all or part of process400) at a preset alarm time. The alarm data can identify the preset alarm time. The preset alarm time can include a time as identified by a user via input when enabling or setting the alarm.

At block410, activity-indicative data is collected. The activity-indicative data can include one or more measurements collected by a sensor of an electronic device performing all or part of process400. The activity-indicative data can include one or more inputs received at an interface of the electronic device. The one or more inputs can correspond to an interaction with an application installed on the electronic device (which, in some instances, can include an operating system). The one or more inputs can alternatively or additionally correspond to other device interactions (e.g., providing a mechanical input to the device, pressing a button on the device and/or unplugging the device). Thus, the activity-indicative data can include data detected using one or more environmental sensors, input components and/or software modules. For example, one or more environmental sensors (e.g., an accelerometer, gyroscope, magnetometer, barometric sensor and/or GPS receiver) can collect data indicative of (for example) an acceleration, velocity, orientation, angular velocity, angular acceleration, altitude, location and/or position of the device. In some instances, the sensor data can be transformed into other types of movement data, such as a timing and/or count of steps. Other types of sensor data can include an ambient light level and/or indication as to whether the device is proximate to another object. The one or more inputs can be indicative of (for example) a type, duration and/or effect on input received at the device. For example, the one or more inputs can include a passcode or biometric input that was received and effective to unlock the device. As another example, the or more inputs can correspond with time stamps that indicate that input has been received substantially continuously over a particular (measured) time period. Other types of data can also be collected, such as whether the device is plugged in and/or whether a recent change in a power source was detected. As another example, data from a sensor (e.g., accelerometer, gyroscope, magnetometer, barometric sensor and/or GPS receiver) can be collected across a period of time to determine (for example) a change in a variable (e.g., a change in a location, change in altitude or change in orientation) or a duration of an above-threshold sensor measurement (e.g., a time during which a total acceleration or total velocity or horizontal acceleration or horizontal velocity exceeds an acceleration or velocity threshold).

At block415, one or more wakefulness conditions is accessed. One, more or all of the one or more wakefulness conditions can be (for example) predefined or defined at least in part based on a learning algorithm and past sensor and/or input data. The one or more wakefulness conditions can include one or more thresholds which can apply to (for example) measurements, changes in measurements, and/or one or more movement metrics (e.g., a number of steps and/or a duration that it is inferred that a user was in a particular pose) derived from one or more measurements and/or inputs.

For example, a wakefulness condition can identify a threshold number of steps within a movement epoch, such that the wakefulness condition is satisfied upon detecting at least the threshold number of steps within the movement epoch. The wakefulness condition can indicate that a movement epoch is to be defined (for example) as a time period during which a moving average of a velocity of a device is above another threshold or as a time period of predetermined length (e.g., such that a device can potentially repeatedly determine a number of steps detected over a last time interval of the predetermined length). As another example, a wakefulness condition can be configured to be satisfied upon detecting a particular type of orientation change (e.g., transitioning from a first orientation that is within a first range of a horizontal orientation to a second orientation that is within a second range of a vertical orientation). As yet other examples, a wakefulness condition can be configured to be satisfied upon detecting that a power source for a device has changed (e.g., that a device has been disconnected from an AC power source), that a device has been unlocked, that a device has changed to a state indicating that it is being worn by a user and/or that an ambient light intensity has increased by at least a threshold amount within a defined time period.

At block420, it is determined whether any of the one or more wakefulness conditions are satisfied based on the activity-indicative data. When none of the one or more wakefulness conditions are satisfied, process400returns to block410. When at least one of the one or more wakefulness conditions are satisfied, process400continues to block425, where a disablement query is displayed that includes an option to disable the alarm. The disablement query can identify the alarm (e.g., via the alarm time). The option can include, for example, displayed text and an associated selection option (e.g., toggle button, virtual button, indication that a mechanical input corresponds to selection of the option, etc.). In some instances, the disablement query further includes another option to decline disabling the alarm. For example, a presentation can include two virtual buttons corresponding to “Turn off alarm” and “Keep alarm” text. As another example, a presentation can include a slider or toggle feature, where moving a marker to one side corresponds to an instruction to disable the alarm and moving the marker to the other side corresponds to an instruction to maintain the alarm. In some instances, at least part of or all of the presentation of the disablement query is accompanied by or preceded by an audio and/or haptic stimulus.

At block430, it is determined whether the option to disable the alarm was selected. Selecting the option may include, for example, toggling a toggle switch, pressing a virtual button, swiping a virtual object in a particular direction, etc. Selection of the option can correspond to generating an instruction to disable the alarm. In some instances, the determination can include whether the option was selected within a predefined time period from a time at which the query was presented.

When a disablement instruction was not received in response to the query (e.g., when no response was received or a response was received indicating that the alarm is not to be disabled), process400can return to block410to collect additional activity-indicative data for continued evaluation. In some instances, a pause for specified time is implemented prior to a return to block410. In some instances, condition evaluation can cease in response to an express negative response to the query. When a selection of the option to disable the alarm is received, process400proceeds to block435where the alarm is disabled. Disabling the alarm can have an effect of not causing an audio and/or haptic stimulus to be presented at the alarm time.

It will be appreciated that variations of process400are contemplated. For example, process400may further including receiving (e.g., as a pushed transmission or in response to a request) other data from another electronic device associated with the user, and a condition may be evaluated based on at least part of the received data and at least part of the locally collected data. As another example, multiple conditions may be accessed and evaluated, and each may be associated with a different wakefulness confidence. To illustrate, detecting that input has been received to unlock a device (thereby satisfying a first condition) may be associated with a higher wakefulness confidence than detecting that a device has moved at least a threshold distance (thereby satisfying a second condition). The confidence can be used to (for example) identify a type of disablement query to be presented, determine whether to present a disablement query (e.g., where satisfaction of wakefulness conditions associated with high confidence can trigger automatic alarm disablement), a monitoring period, etc.

In some instances, multiple alarms may initially be enabled. In such instances, when it is determined that a wakefulness condition is satisfied, one or more disablement queries may be presented that includes one or more options to disable specific alarms and/or all of the alarms. For example, a disablement query may include “Disable alarms?”, followed by an identification of a 7:30 am alarm, 8:00 am alarm, 8:15 am alarm, and all alarms—each being visually associated with a disablement option.

In some instances, alarms enabled on a device can be associated with one or more classifications. The one or more classifications can include a wake-alarm classification that indicates that the alarm is being used to wake a user up. The one or more classifications can include one or more other classifications that indicates that the alarm is being used for another purpose (e.g., as a task reminder). A classification can be determined based on (for example) which application was used to enable (or set) the alarm, a classification input that indicates that the alarm is a wake-alarm classification, and/or based on other data (e.g., such that an alarm is assigned a wake-alarm classification when biometric data indicates that a user is asleep a predefined time period before the preset alarm time). Evaluation of wakefulness conditions, presentations of disablement queries and/or disabling of alarms may be selectively performed for alarms that are assigned a wake-alarm classification.

FIG. 5shows a flowchart of a process500for facilitating disabling an alarm in accordance with some embodiments of the invention. Part of all of process500can be performed, for example, at electronic device200and/or wearable electronic device300.

Process500begins at block505where alarm data is accessed. The alarm data can correspond to an enabled alarm, indicating an alarm that is configured to trigger an output stimulus (e.g., audio and/or haptic stimulus) at one or more devices (e.g., at the device(s) performing all or part of process400) at a particular alarm time. The alarm data can identify the particular alarm time.

At block510, it is determined whether the alarm time is less than a threshold time away relative to a current time. For example, block510can be affirmatively determined when the threshold time is set to two hours, the alarm time is set to 6 am, and a current time is 4 am. The threshold time can be a predefined time. In some instances, it may further or alternatively be determined whether a current time is more than another predefined threshold time from a user-designated bedtime (e.g., as stored at the device) and/or a time at which it was inferred that the user went to bed (e.g., based on detecting that a device has been plugged in, that a device has been taken off from being worn, that movement has not been detected for at least a threshold time period within a predefined time range, etc.).

When it is determined that the alarm time is not less than the threshold time away relative to a current time, process500can return to block505. In some instances, a pause of a predefined duration can be effected before returning to block505. When it is determined that the alarm time is less than the threshold time away relative to a current time, process500proceeds to block515, where an alarm controller subscribes to receive updates to activity-indicative data. The activity-indicative data can include data collected by one or more sensors and/or inputs received via an interface. The activity-indicative data can be indicative of and/or can correspond to movement data and/or interaction data. The movement data can characterize a movement or motion of the device. The movement data can include, for example, accelerometer data, gyroscope data, magnetometer data, barometric data and/or variables derived therefrom (e.g., step counts and/or pose positions). The interaction data can be indicative of and/or can correspond to an interaction with an application executing on the device. As one example, the alarm controller can subscribe to receive sensor measurement updates from a movement controller. Such updates can be sent (for example) in a streaming fashion, periodically, at routine intervals, as requested, upon detecting an input (e.g., generally, of a specific type or associated with a particular app or module), etc.

At block520, updated (e.g., recent) activity-indicative data is received. At block525, each of one or more wakefulness conditions is accessed (e.g., from a data store). The one or more wakefulness conditions can include (for example) predefined, learned, static and/or dynamic conditions. At block530, it is determined whether any of the one or more wakefulness conditions is satisfied based on the updated activity-indicative data. When it is determined that none of the one or more wakefulness conditions is satisfied, process500returns to block520to receive newly updated activity-indicative data.

When it is determined that at least one of the one or more wakefulness conditions is satisfied, process500proceeds to block535where it is determined whether a display of the device is asleep. When it is determined that the display is asleep, process500proceeds to block540where the display is powered on. When it is determined that the display is not asleep, process500proceeds to block545. At block545, a disablement query is presented that includes an option to disable the alarm.

It will be appreciated that block545in process500can parallel block425in process400and that process500can further proceed as in process400to respond to an instruction (or lack thereof) received in response to the query.

Process500can be effected such that updates to activity-indicative data are received at block520even when a device is asleep (e.g., via use of a motion co-processor). This type of background processing can facilitate efficient and unobtrusive yet continuously monitoring to facilitate negating presentation of unnecessary alarm stimuli.

FIG. 6shows a flow of a process600for evaluating a wakefulness condition in accordance with some embodiments of the invention. Part of all of process600can be performed, for example, at electronic device200and/or wearable electronic device300. In some instances, some or all actions of process600can be performed as part of the determination performed at block420in process400and/or as part of the determination performed at block530in process500.

One or more sensors602collect sensor data. Sensors602can include one or more movement-, location-, position-, and/or orientation-detection sensors, such as an accelerometer604, a gyroscope606and/or one or more meters608(e.g., a magnetometer, such as a compass). A meter608may further or alternatively include an ammeter to measure current. Sensors602can further include one or more light sensors610, which can be used to detect ambient light. In some instances, a light sensor610includes a sensor to detect infrared light and/or intensity of light in response to emitting the light. Light sensor610may (for example) be part of a heart-rate detector.

The electronic device can further include one or more user-interaction detectors612configured to detect a user interaction with the device. A fingerprint scanner614can detect a finger on a fingerprint sensor and/or can detect that fingerprint data received at the fingerprint sensor corresponds to a particular fingerprint signature. A touch screen616can include (for example) resistive and/or capacitive elements to detect pressure and/or voltage changes. Thus, it can be determined whether a user is touching a screen and a part of the screen that is being touched. An app-usage detector618can track which (if any) app(s) are being used.

Data collected by one or more sensors602and/or one or more user-interaction detectors612can be used to determine or infer activity- and/or state-related information. For example, a pedometer622may use data from (for example) accelerometer604and/or gyroscope606to infer when a user has taken a step (e.g., and count steps). An orientation detector624can use data from (for example) accelerometer604and/or gyroscope606to infer an orientation of the device (e.g., with respect to one or more axes). A pose detector626can infer a pose of a user (e.g., laying down, sitting or standing) using data from (for example) accelerometer604, gyroscope606and/or meter608(e.g., a magnetometer). A movement detector628can infer a magnitude, direction and/or duration of movement using data from (for example) accelerometer604. Charging-state detector630can use data from (for example) meter608(e.g., an ammeter) to determine whether the device is plugged into an AC power source. A wear-state detector632can use data from (for example) light sensor610to infer whether the device is being worn by a user (e.g., based on whether a heart rate can be detected using collected light intensities).

A lock-state detector634can use data from (for example) fingerprint scanner614and/or touch screen616to determine whether the device has been or is to be unlocked (e.g., in response to detected fingerprint data or passcode data that matches an unlocking signature). An activity-session detector634can use data from (for example) touch screen616and/or app-usage detector618to infer (for example) whether a user is interacting with the device (e.g., generally, across all apps and/or across one or more specific apps) and/or a time interval over which a user has been interacting with the device.

At block636, it can be determined whether a difference between a time at which an alarm on the device is set and a current time is less than (or less than or equal to) a predefined threshold (e.g., 30 minutes). If not, data can continued to be collected and the detectors can continue to detect and/or infer activity-related information. If so, one or more potential-disablement conditions638a-638hcan be evaluated. For example, at block638ait can be determined whether a number of steps (e.g., within a movement epoch and/or time period) exceeds a predefined threshold. At block638b, it can be determined whether inferred device-orientation data indicates that a device transitioned from a flat or horizontal orientation to an upright or vertical orientation. At block638c, it can be determined whether inferred pose data indicates that a user has been standing for at least a predefined threshold amount of time. At block638d, it can be determined whether at least a predefined threshold amount of movement was detected (e.g., corresponding to a velocity statistic, displacement statistic, etc.). At block638e, it can be determined whether charging-state data indicates that the device has transitioned from a charging state to a non-charging state (i.e., whether the device has been unplugged). At block638f, it can be determined whether the device has transitioned from a state indicating that it was not being worn by a user to a state indicating that it was being worn by a user. At block638g, it can be determined whether the device has transitioned from a locked state to an unlocked state. At block638h, it can be determined whether activity data indicates that the user has been interacting with the device for at least a predefined amount of time.

A wake/sleep detector640can infer whether a user is awake or not based on evaluation of one or more of conditions638a-638h. A determination that the user is not awake may correspond to the user being asleep or the user being only temporarily awake during a night's sleep. In some instances, if any of conditions638a-638his satisfied, it can be inferred that the user is awake. In some instances, at least a predefined number of conditions638a-638hare to be satisfied in order to infer that the user is awake. In some instances, some conditions are paired (e.g., such that detecting only that condition638cis satisfied is to trigger an awake inference, while for condition638f, at least one other condition is to also be satisfied to support an awake inference). It will be appreciated that conditions638a-hare exemplary. One or more other conditions may be assessed in addition to and/or instead of the depicted condition, and the condition set need not include each of conditions638a-h. If it is determined that a user is awake, a disablement query can then be presented. If it is determined that a user is not awake, a disablement query is not presented (e.g., not immediately presented).

Specific details are given in the above description to provide a thorough understanding of the embodiments. However, it is understood that the embodiments can be practiced without these specific details. For example, circuits can be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques can be shown without unnecessary detail in order to avoid obscuring the embodiments.

Implementation of the techniques, blocks, steps and means described above can be done in various ways. For example, these techniques, blocks, steps and means can be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units can be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described above, and/or a combination thereof.

Furthermore, embodiments can be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and/or any combination thereof. When implemented in software, firmware, middleware, scripting language, and/or microcode, the program code or code segments to perform the necessary tasks can be stored in a machine readable medium such as a storage medium. A code segment or machine-executable instruction can represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a script, a class, or any combination of instructions, data structures, and/or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, and/or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, ticket passing, network transmission, etc.