The disclosure relates generally to electronic calendars, and more specifically to scheduling calendar items based on signals from sensors.
Electronic calendars are increasingly used to organize people's lives. Such calendars are accessed from both desktop computers and portable computing devices (e.g., laptop computers, mobile phones, personal digital assistants (PDAs), tablet computers, and wearable computers).
Users of calendar applications may create items in their calendars to denote a commitment of some duration of time to a given activity or engagement with another person. Some of these items cannot accurately be scheduled at a fixed time because they are relative to some other event. For example, a user may want to commit to a morning exercise routine that begins 30 minutes after the user wakes up.
Disclosed implementations address the above deficiencies and other problems associated with scheduling electronic calendar items that are based on the dynamic occurrence of real world events. Disclosed implementations allows a user to schedule items in a calendar that are not at a fixed time but are relative to events detected by sensors (e.g., sensors on a mobile device).
Some implementations include three major components. A first component is a calendar application, which includes a user interface that a user uses to create items that represent time commitments. A second component is a trigger event daemon, which receives event data from sensor-enabled devices, contains business logic to combine these event signals into user-understandable events (e.g., a “wake up” event), and communicates with the calendar's application programming interface (API) to modify calendar items based on the designated triggers. In some implementations, the trigger event daemon is cloud-based. A third component is a set of one or more networked devices equipped with sensors that can publish sensor events. Sensor events include: users entering a designated location; a device being physically moved; or motion being detected in a room of a household. The sensor events/signals are sent to the trigger event daemon.
The following example illustrates some of the disclosed features. First, a user creates a triggered item in a calendar, such as an event titled “Morning Workout.” This item is scheduled to start “10 minutes after I wake up.” The user identifies “waking up” as an event that is detected by an internet-connected device, such as the user's mobile phone. For example, a user may define a WAKE_UP event in a business logic layer within the trigger event daemon to consist of a combination of three signals: a signal from a system clock indicating that the time is between 6:00 AM and 8:00 AM; a signal from a GPS sensor indicating that the user is at a home location; and a signal from an accelerometer on a mobile device indicating that the user just moved the device N times in the last 60 seconds (e.g., N=5). The calendar application configures the trigger event daemon to subscribe to WAKE_UP events. Later, when the WAKE_UP trigger fires (due to this combination of signals being detected by the trigger event daemon) the trigger event daemon uses the calendar application's API to update the actual start time of the Morning Workout item to be at a fixed time (e.g., 10 minutes after WAKE_UP at 7:15 AM, which is 7:25 AM). At the scheduled time (e.g., 7:25), the electronic calendar notifies the user of the scheduled item. In some implementations, the user is notified at a predefined period before the scheduled time (e.g., five minutes beforehand).
In some implementations, the trigger event daemon runs in the background on the user's mobile device. In some instances, after an item is scheduled at a fixed time (or rescheduled), the calendar processes any additional updates to the user's calendar. For example, items that now conflict with the user's morning workout at 7:25 may need to be rescheduled. When a user accesses a calendar from multiple devices, the calendar user interface on each of the user's devices is updated to reflect the new schedule.
Unlike traditional calendaring systems, some disclosed implementations take advantage of floating triggers that can be defined by an arbitrary number of networked devices capable of detecting real-world events such as user body movement, changes in a user's household, a user's presence at a location, and more.
One advantage of the disclosed implementations for creating calendar items is that it takes into account the right context for doing certain things relative to events that are not purely time-based (e.g., waking up in the morning). Disclosed implementations also allow a calendar to react to changes in a user's schedule based on when events actually occur, such as arriving at a location.
In some implementations, the trigger event daemon runs on a server (e.g., a calendar server), and may process events for many different users. The trigger event daemon receives signals from sensors on many different devices. In other implementations, the trigger event daemon is a program that runs locally on a single device or as part of the calendar application.
In accordance with some implementations, a method executes at a computer system with one or more processors and memory. The memory stores one or more programs configured for execution by the one or more processors. The process creates a calendar item scheduled at a time offset from a triggering event. The triggering event includes receiving one or more predefined signals from distinct sensors. In some instances, the triggering event includes receiving a plurality of predefined signals from a plurality of distinct sensors. In some implementations, the sensors include clocks, accelerometers, motion sensors, and/or GPS sensors. In some implementations, the sensors can detect entry by a user into a predefined geographical region or arrival at a predefined location (e.g., using GPS information to identify arrival at an office location). The predefined signals include a first signal from a first sensor that identifies physical motion. In some instances, the first signal indicates repetition of physical motion multiple times within a designated span of time (e.g., moving a mobile phone 4 times within a minute). In some implementations, one or more of the sensors are components of a mobile device associated with a user (e.g., a mobile phone or tablet computer). The process identifies the occurrence of the triggering event based on receiving the one or more predefined signals from the sensors. The process updates the calendar item to specify a scheduled time that is computed as the time offset from the occurrence of the triggering event. The process notifies the user of the calendar item when the scheduled time is reached.
For a better understanding of the aforementioned implementations of the invention as well as additional implementations thereof, reference should be made to the Description of Implementations below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures.
Reference will now be made in detail to implementations, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that the present invention may be practiced without these specific details.
The calendar application 102 includes a user interface, which is not depicted in
As illustrated in
The trigger event daemon 112 can also receive sensor signals 154 from home or network sensors 124. The home sensors 124 may include motion sensors 126 or other sensors in a home security system (e.g., sensors that detect whether doors or windows are open). In some instances, the home sensors include a garage door sensor 128 that indicates whether the garage door is open. Some implementations support sensors 124 on networked home appliances 130, such as refrigerators, coffee makers, or tea kettles. These networked home appliances 130 can provide status information (e.g., is the refrigerator door open or is the coffee done).
Some implementations support other network sensors 124 outside of a home as long as their network connections allow communication with the trigger event daemon 112. For example, some implementations support web cams. In some implementations, the other network sensors 124 includes signals received from third party sources, such as a news feed.
In operation, a user accesses the calendar application 102, and inserts a new calendar item. Rather than scheduling the item at a specific date and time, the item is scheduled at an offset from an unscheduled event. The calendar item and information about the triggering event are sent (158) to the database 104 for storage in the calendar data 106 and event data 108. The calendar application also communicates (150) the triggering event information through the calendar API to (152) the trigger event daemon. The trigger event daemon tracks the definition of each triggering event. In particular, a triggering event includes appropriate sensor signals from one or more of the client device sensors 114 or home sensors 124. Typically, implementations support various combinations of sensor signals. For example, a triggering event may require signal 1 and (signal 2 or signal 3). This is described in more detail below with respect to
When the trigger event daemon detects that it has received all of the sensor signals 154 required for a triggering event, the trigger event daemon 112 sends (152) the trigger event information (e.g., the event ID 502) to the calendar API, which forwards (150) the information to the calendar application 102 and/or to (156) the database 104. In some implementations, the calendar API 110 uses the information from the triggering event to update the calendar item. In particular, the calendar item is now scheduled on a specific date and time rather than as an offset. The specific date and time are computed as the offset from the time of the triggering event.
In some implementations, a single calendar for a user is shared by multiple devices (e.g., a desktop computer, a tablet computer, and a Smart phone). In this case, when the triggering event is detected and updated to the database, the calendar is updated (158) on each of the devices. In some implementations, updating all of the copies of the user's calendar is performed by a synchronization module 324. For example, in some implementations, there is a master copy of a user's calendar data stored in a database 104 on a server 300, and as changes are received from any of the copies, the synchronization module 324 on the server 300 propagates the changes to all of the copies.
A client device 200 typically includes one or more processing units (CPU's) 202 for executing modules, programs, or instructions stored in memory 214 and thereby performing processing operations; one or more network or other communications interfaces 204; memory 214; and one or more communication buses 212 for interconnecting these components. The communication buses 212 may include circuitry (sometimes called a chipset) that interconnects and controls communications between system components. A client device 200 includes a user interface 206 comprising a display device 208 and one or more input devices or mechanisms 210. In some implementations, the input device/mechanism includes a keyboard and a mouse; in some implementations, the input device/mechanism includes a “soft” keyboard, which is displayed as needed on the display device 208, enabling a user to “press keys” that appear on the display 208.
A client device 200 typically includes one or more client device sensors 114. In some implementations, the client device 200 includes an accelerometer 116, which detects motion (acceleration) of the client device 200. An accelerometer 116 is generally able to detect changes in speed as well as changes in direction of movement. The accelerometer 116 quantifies the amount of acceleration and transmits a signal to other components of the client device (e.g., to a trigger event daemon 112 or to a communications module 218). A client device 200 typically includes a clock 118, which is a sensor that provides time information. The some implementations, a local clock 118 on the client device 200 is periodically updated from an external source.
Some client devices include a GPS system 120, which is a sensor that provides location information (e.g., longitude, latitude, and altitude). Note that a GPS system can also be used as a simple motion detector by recognizing when the location changes. Some client devices 200 include other sensors 122 as well, such as a microphone, video sensor, or compass. Each of the client device sensors 114 can detect certain activity and provide electronic signals that quantify or measure the activity in some way.
In some implementations, the memory 214 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices. In some implementations, memory 214 includes non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. In some implementations, the memory 214 includes one or more storage devices remotely located from the CPU(s) 202. The memory 214, or alternately the non-volatile memory device(s) within memory 214, comprises a non-transitory computer readable storage medium. In some implementations, the memory 214, or the computer readable storage medium of memory 214, stores the following programs, modules, and data structures, or a subset thereof:
Each of the above identified executable modules, applications, or sets of procedures may be stored in one or more of the previously mentioned memory devices and corresponds to a set of instructions for performing a function described above. The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise re-arranged in various implementations. In some implementations, the memory 214 may store a subset of the modules and data structures identified above. Furthermore, the memory 214 may store additional modules or data structures not described above.
Although
In some implementations, the memory 314 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices. In some implementations, the memory 314 includes non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. In some implementations, the memory 314 includes one or more storage devices remotely located from the CPU(s) 302. The memory 314, or alternately the non-volatile memory device(s) within memory 314, comprises a non-transitory computer readable storage medium. In some implementations, the memory 314, or the computer readable storage medium of memory 314, stores the following programs, modules, and data structures, or a subset thereof:
Each of the above identified elements in
Although
In other implementations, the client device runs a web-based calendar application 102-B, but the remainder of the functionality is performed by a server 300. In these implementations, when the client device sensors 114 are used, they transmit signals to the server 300 (e.g., using the communications module 218). In some of these implementations, the client device 200 includes a calendar sensor application (not shown in
In some implementations, the components illustrated in
The calendar functionality as described herein may be allocated between the client device 200 and one or more servers 300 in various ways.
In some instances, a calendar item may be scheduled at an offset from some triggering event, in which case the scheduled date/time is initially blank or NULL. In this case, the user defines the triggering event, which is identified by a triggering event ID 502 (and described below with respect to
Each event is defined based on signals from one or more sensors. Each of these is an element 506 of the event. Each event element 506 corresponds to a unique sensor, which is identified by a sensor ID 508. In addition, each event element includes sensor specific parameters 510 that identify what signal values are required.
For example, consider a “wake up” event that has three elements 506. The first element corresponds to the clock sensor, and the parameters 510 are that the time is between 6:00 AM and 7:00 AM. The second element is based on location. The client device 200 has a GPS sensor 120, and the data from the GPS (longitude and latitude) is compared to the user's home location. The parameters 510 for the GPS include both the longitude and latitude of home and a maximum deviation (e.g., at most 50 feet for each dimension). Finally, the third element is based on the accelerometer, which detects motion of the client device 200 after the user wakes up. The parameters 510 may specify the amount of movement, or the number of movements within a specific interval of time.
Once the event is triggered, the corresponding calendar item is updated with a specific time, and the trigger condition is deactivated. This prevents retriggering calendar updates after the initial triggering condition is detected. For example, in the above scenario, the “wake up” event triggers once, but does not trigger repeatedly between 6:00 and 7:00 as the user moves around at home.
In some implementations, each of the event elements must occur in order for the event to trigger. This essentially places an “AND” between each of the elements. Some implementations provide for more complex Boolean expressions with each of the event elements, which may include AND, OR, and parentheses. Some implementations specifically include repetition in the definition of each event element, with the default being 1. For example, a user may specify the number of repetitions of a sensor signal within a designated span of time.
Note that the event data 108 specifies what sensor signals are required in order to constitute an event. Historical data of the sensor signals actually received may be stored in a sensor signal log 224.
A user creates (606) a calendar item scheduled at a time offset from a triggering event. The triggering event includes (608) receiving one or more predefined signals from distinct sensors. As illustrated above in
In some instances, the first signal from the first sensor indicates (612) entry by the user into a predefined geographical region. For example, a GPS sensor 120 may provide signals indicating the location of a user's mobile device (and thereby the location of the user), and the location can be compared to a defined geographical region. A geographical region may be small (e.g., a region representing an office building or a mall), or may be large (e.g., a city). In some instances, the first signal from the first sensor indicates (614) arrival by the user at a predefined location (e.g., arriving at home, arriving at an office, or arriving at a restaurant).
In some instances, the first sensor is (616) an accelerometer and the first signal indicates (616) movement of the accelerometer at least n times within a time span of m seconds. The numbers n and m are positive integers. In some instances, the accelerometer is a component of a mobile device 200 associated with the user. Choosing n greater than 1 can reduce the chance of triggering an accidental incorrect event. For example, the previously described “wake up” event includes movement of a user's client device. If a single movement of the device were enough to trigger a “wake up” event, it could trigger accidentally if a pet knocked the client device off of a nightstand. Similarly, a GPS system 120 on a client device may provide inconsistent readings, even when still, which could incorrectly suggest movement. Requiring multiple movement readings can avoid false positive events.
In some instances, the one or more predefined signals include (620) a plurality of predefined signals from a plurality of distinct sensors. For example, a real world event may be associated with multiple distinct sensor readings instead of a single reading. In some instances, the plurality of distinct sensors includes (622) a second sensor that is a clock, and a second signal from the second sensor (the clock) indicates (622) that a current time is within a predefined span of time. For example, the current time is between 8:00 AM and 9:00 AM local time. In some instances, the second sensor is a clock, and the signal indicates that the current time is at or past a designated time.
The process identifies (624) the occurrence of the triggering event based on receiving the one or more predefined signals from the sensors. In some instances, a sensor pushes data out (e.g., transmitting to the trigger event daemon). In some instances, the trigger event daemon pulls data from a sensor as appropriate. Some sensors are designed for only one mode of operation (i.e., only push or only pull), but other sensors can operate in either mode. For example, a clock sensor may work in a pull mode, with the trigger event daemon checking the clock sensor when the other triggering event elements are satisfied.
When the triggering event is identified, the process 600 updates (626) the calendar item to specify a scheduled time that is computed as the time offset from the occurrence of the triggering event. For example, if the triggering event occurs at 9:18 AM, and the offset is 15 minutes, the calendar item is scheduled for 9:33 AM. In some implementations, the scheduled times can be rounded (e.g., rounded up to the nearest 5 minutes or the nearest 15 minutes).
When the scheduled time is reached (which may be the exact scheduled time or a designated period of time beforehand), the process 600 notifies (628) the user of the calendar item.
The terminology used in the description of the invention herein is for the purpose of describing particular implementations only and is not intended to be limiting of the invention. As used in the description of the invention and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises,” “comprising,” “includes,” and “including,” when used in this specification, specify the presence of stated features, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and/or groups thereof.
The foregoing description, for purpose of explanation, has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The implementations described herein were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various implementations with various modifications as are suited to the particular use contemplated.