Handheld computing device with external notification system

[0002] This is a divisional of U.S. patent application Ser. No. 08/854,102, filed May 8, 1997, which is now U.S. Pat. No. 6,209,011.

[0003] This invention relates to portable handheld computing devices, such as handheld personal computers (H/PCs). More particularly, this invention relates to an external notification system for handheld computing devices.

[0004] Small, handheld computing devices have been steadily growing in popularity in recent years. The devices go by different names, including palmtops, pocket computers, personal digital assistants, personal organizers, and the like. This disclosure is primarily directed to a class of computing devices referred to as handheld personal computers, or “H/PCs”, although aspects of this invention can be implemented other types of handheld computing devices.

[0005] H/PCs are small, pocket-sized devices having an LCD (liquid crystal display) with a touch-sensitive screen, a stylus to enter data through the screen, and an input device such as a keypad or miniature QWERTY keyboard. H/PCs have a microprocessor, memory, and are capable of running an operating system and one or more applications on the operating system. Microsoft Corporation recently released the Windows® CE operating system for use on H/PCs, which is a scaled-down version of its popular Windows® operating systems manufactured for personal computers.

[0006] One of the most desirable characteristics of H/PCs is their portability. The compact, portable H/PCs provide a user with real computer-like applications—such as email, PIM (personal information management), Internet browser, spreadsheet, word processing. A traveling user can receive email messages, schedule meetings or appointments, and browse the Internet from the H/PC.

[0007] Some handheld computing devices can notify a user of a scheduled event, if they are turned on. The device plays an alarm sound, or pops-up a dialog box, to alert the user of the event. However, many handheld computing devices have no means of notifying a user when they are turned off, which is normally the case to conserve power. While some handheld computing devices might be configured to wake up and sound an alarm, such devices typically time out the alarm after a short period. As a result, the user can miss the alarm because it terminates before being noticed. In addition, audio alarms may, on occasions, be too faint for the surrounding environment (e.g., an alarm might be overpowered by noise in an airplane flight) or not sufficiently strong to command a user's attention when the user is not immediately next to the device.

[0008] It would be advantageous to develop a notification system for handheld computing devices, such as H/PCs, that notifies a user when an event occurs regardless of whether the device is on or off, open or closed, pocketed, or docked, and which remains active until the user acknowledges it. It would also be advantageous to develop a notification system that provides a lasting external notification to the user, rather than a short-run alarm or a pop-up box that is not externally visible.

[0009] This invention concerns a portable handheld computing device having a notification system that alerts a user of an event regardless of whether the device is on or off, open or closed, pocketed, or docked. The notification system has a notification mechanism that is activated upon occurrence of the event and remains active until the user acknowledges the activated mechanism.

[0010] According to an aspect of this invention, the notification mechanism is a light emitting diode (LED) that is (by user option) turned on by the notification system when an event occurs. The LED remains activated until the user takes action to handle the event.

[0011] According to another aspect of this invention, the LED is mounted externally on the handheld computing device. More particularly, the handheld device has a casing with a lid and a base. The LED is mounted on the lid's upper surface and wraps around to one of the end surfaces of the lid. In this manner, the LED is visible to the user when the lid is closed onto the base (i.e., the device is off) or when the lid is open (i.e., the device is on).

[0012] According to another aspect of this invention, the notification mechanism also has a deactivation button mounted externally of the handheld computing device. The user depresses the deactivation button to deactivate the LED (as well as any other external signals that may be used). In one implementation, the LED and deactivation button are integrated as a single component mounted on the device lid.

[0013] According to yet another aspect of this invention, a notification program runs on the handheld computing device and is callable by an application to help schedule events. The notification program sets timers with the system clock, which is always on even when the handheld computer is turned off. When a timer expires, the system clock sends an interrupt to the notification program to wake up the notification program so that it can turn on the LED. The LED is coupled to power so that it can remain on and the notification program can go back asleep. The LED continues emitting light until the user notices and presses the deactivation button.

[0014] According to another aspect, the notification program places a taskbar annunciator in the taskbar of an operating graphical user interface window when an event is realized. After depressing the deactivation button in recognition of the LED, the user can actuate the taskbar annunciator with a stylus or other means and jump directly to the source of the event. For instance, actuating the taskbar annunciator might open a window that describes an appointment, which is the root of the event.

[0015] According to another aspect, the notification program supports a graphical user interface that enables a user to set notification options specifying how external notification is to operate. For instance, the user might prefer a flashing light in combination with an alarm. The user can set these options through the user interface. The options are saved in a structure that is accessed when a user notification is set.

[0016] According to still another aspect, the notification program is called by the applications on the handheld computing device through an application program interface (API). The API defines a time parameter that specifies when the user notification should occur and a type parameter that references the structure containing the user-defined notification options.

[0017] The same reference numbers are used throughout the drawings to reference like components and features.

[0018] FIG. 1 is a perspective view of a handheld computing device in an open position.

[0019] FIG. 2A provides an end elevation view of the handheld computing device in a closed position.

[0020] FIG. 2B provides a front elevation view of the handheld computing device in a closed position.

[0021] FIG. 2C provides a side elevation view of the handheld computing device in a closed position.

[0022] FIG. 3 is a block diagram of the handheld computing device.

[0023] FIG. 4 is a block diagram of the hardware/software architecture of a notification system implemented in the handheld computing device.

[0024] FIG. 5 is a diagrammatic illustration of a graphical user interface window embodied as an “options” dialog box.

[0025] FIG. 6 is a diagrammatic illustration of a screen image presented on a display of the handheld computing device.

[0026] FIG. 7 is a diagrammatic illustration of a graphical user interface window embodied as a “notification” dialog box.

[0027] FIGS. 1 and 2 show a handheld computing device 20. As used herein, is “handheld computing device” means a small general computing device having a processing unit that is capable of running one or more application programs, a display, and an input mechanism that is typically something other than a full-size keyboard. The input mechanism might be a keypad, a touch-sensitive screen, a track ball, a touch-sensitive pad, a miniaturized QWERTY keyboard, or the like.

[0028] The handheld computing device 20 of FIGS. 1 and 2A-2C is embodied as a handheld personal computer (H/PC). The terms “handheld computing device” and “handheld personal computer” (or H/PC) are used interchangeably throughout this disclosure. However, in other implementations, the handheld computing device may be implemented as a personal digital assistant (PDA), a personal organizer, a palmtop computer, a computerized notepad, or the like.

[0029] Handheld computing device 20 has a casing 22 with a cover or lid 24 and a base 26. The lid 24 is hingedly connected to the base 26 to pivot between an open position (FIG. 1) and a closed position (FIGS. 2A-2C). The handheld computing device 20 has an LCD (liquid crystal display) 28 with a touch-sensitive screen mounted in lid 24. The device is equipped with a stylus 30 to enter data through the touchscreen display 28 and a miniature QWERTY keyboard 32, which are both mounted in base 26. The handheld computing device 20 can also be implemented with a wireless transceiver (not shown) such as an IR (infrared) transceiver and/or an RF (radio frequency) transceiver. Although the illustrated implementation shows a two-member H/PC 20 with a lid 24 and a base 26, other implementations of the H/PC might comprise an integrated body without hinged components, as is the case with computerized notepads (e.g., Newton® from Apple Computers).

[0030] In the above respects, the H/PC 20 is of conventional design and will not be described in detail. Many manufacturers make suitable H/PCs. However, unlike conventional H/PCs, the handheld computing device 20 of this invention is further implemented with an external notification system.

[0031] In general, the external notification system is designed to alert a user of an event regardless of whether the handheld computing device is presently on or off, or whether the device is presently running a program. The notification system has a notification mechanism that is activated upon occurrence of the event to alert the user. The notification mechanism remains active until the user acknowledges it, even if the handheld computing device is otherwise turned off. The notification mechanism is an external, sensory perceptible mechanism that attracts the user's attention when the device is on or off and regardless of whether the lid is open or closed. The notification mechanism can be implemented in a variety of ways, including a light, an audio generator, a vibration device, or other forms of sensory perceptible mechanisms. In addition, these mechanisms may be used in combination, or with other forms of sensory perceptible notices, such as a visual dialog box on the display.

[0032] In the preferred implementation, the external notification mechanism includes an externally mounted LED (light emitting diode) 40. When activated as a result of an event, the LED is illuminated or made to flash. The LED 40 remains activated until the user acknowledges it.

[0033] More particularly, the LED 40 is mounted on the external surface of the H/PC 20 in a location that the user can view the light from different angles and sides of the H/PC. In addition, the LED 40 is positioned to be seen when the lid 24 is open or closed. As shown in FIGS. 2A-2C, the H/PC casing 22 has an upper surface 42 on lid 24, a lower surface 44 on base 26, a front side surface 46 (on both lid 24 and base 26), an opposing back side surface 48 (on both lid 24 and base 26), and opposing end surfaces 50 and 52 (on both lid 24 and base 26). The end surfaces 50 and 52 are dimensionally shorter than the elongated side surfaces 46 and 48.

[0034] The LED 40 is positioned on the upper surface 42 and wraps around an upper corner to extend onto the end surface 50. The LED is raised on the end surface 50 to be visible from the front. The LED may or may not be raised on the upper surface 42. In this manner, the LED 40 can be viewed when the case 22 is closed, either from above by viewing the LED portion on the upper surface 42 (for instance when the H/PC is sitting on a desk), or from the side by viewing the LED portion on the end surface 50 (for instance when the H/PC is slid upright into a shirt pocket, purse, or briefcase). Additionally, the LED 40 can be viewed when the case 22 is open (FIG. 1) by viewing the raised LED portion on the end surface 50. As an alternative to raising the LED on the end surface , the LED 40 may be configured to wrap around to the inner surface of the lid 24 to be viewable when the case 22 is open. The LED itself might be configured in the illustrated shape, or alternatively a normally shaped LED is configured to emit light into light-transmissive tubing that conforms to the illustrated shape.

[0035] As shown in the end view of FIG. 2A, the H/PC 20 also has a deactivation mechanism to deactivate the LED 40 and any other external notification mechanism. In the illustrated implementation, the deactivation mechanism is a deactivation button 54 that is externally mounted on the end 50 to enable a user to quickly locate and deactivate the external notification mechanisms, regardless of whether the lid is open or closed. In a preferred embodiment, the deactivation button 54 and LED 40 are integrated as a single component. The LED 40 can be constructed to project slightly above the face of the deactivation button 54 to act as a bumper to reduce the likelihood of accidental actuation. In other arrangements, is the button may be located separately from the LED.

[0036] FIG. 3 shows functional components of the handheld computing device 20. It has a processor 60, a memory 62, a display 28, and a keyboard 32. The memory 62 generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, PCMCIA cards, etc.). An operating system 64 is resident in the memory 62 and executes on the processor 60. The H/PC 20 preferably runs the Windows® CE operating system from Microsoft Corporation. This operating system is a derivative of Windows® brand operating systems, such as Windows® 95, that is especially designed for handheld computing devices. However, the handheld computing device may be implemented with other operating systems.

[0037] One or more application programs 66 are loaded into memory 62 and run on the operating system 64. Examples of applications include email programs, scheduling programs, PIM (personal information management) programs, word processing programs, spreadsheet programs, Internet browser programs, and so forth. The H/PC 20 also has a notification manager 68 loaded in memory 62, which executes on the processor 60. The notification manager 68 handles notification requests from the applications 66, as is described below in more detail with reference to FIG. 4.

[0038] The H/PC 20 has a power supply 70, which is implemented as one or more batteries. The power supply 70 might farther include an external power source that overrides or recharges the built-in batteries, such as an AC adapter or a powered docking cradle.

[0039] The H/PC 20 is also shown with three types of external notification mechanisms: an LED 40, a vibration device 72, and an audio generator 74. These devices are directly coupled to the power supply 70 so that when activated, they remain on for a duration dictated by the notification mechanism even though the H/PC processor and other components might shut down to conserve battery power. The LED 40 preferably remains on indefinitely until the user takes action. The current versions of the vibration device 72 and audio generator 74 use too much power for today's H/PC batteries, and so they are configured to turn off when the rest of the system does or at some finite duration after activation.

[0040] FIG. 4 shows the software and hardware architecture of a notification system 80 for the H/PC 20. The notification system 80 has a notification manager 68, which is callable by the applications 66 through a user notification application program interface (API). The API creates a new user notification or modifies an existing one. It is given as:

[0041] PegSetUserNotification(hNotification, *AppName, *Time, *UserNotification)

[0042] The API has four parameters, three of which are pointers. The “hNotification” parameter specifies whether the call relates to creating a new user notification or to modifying an existing notification. The parameter is either zero, when a new notification is to be added, or contains an identity of the notification to be modified.

[0043] The “AppName” pointer points to a null-terminated string that specifies the name of the application 66 that owns the notification. The system uses the application's primary icon as the taskbar annunciator that is set by the notification system to notify the user and enable immediate-click access to the application responsible for the notification. The use of a taskbar annunciator is described below with reference to FIG. 6. The “Time” pointer points to the system time structure that specifies a time when the notification should occur. The “UserNotification” pointer points to a Peg_User_Notification structure that describes the events that are to occur when the notification time is reached.

[0044] More particularly, the Peg_User_Notification structure is a user configurable structure that holds notifications options preferred by the user. The application passes the user's preferences to the system when scheduling an event by specifying the address of the structure. Each application passes in a structure that applies only to it, so notifications for different applications can be differentiated. Similarly, an application can pass in different structures for different events, so individual notifications can be differentiated.

[0045] The Peg_User_Notification structure contains information used to initialize a dialog box user interface that is presented to the user when setting notification options. FIG. 5 shows an example dialog box 100, which is supported by the notification system 80. In this example, the dialog box 100 includes an option 102 as to whether to sound an alarm and a drop-down menu 104 that lists various available alarm sounds, such as “Beep”. The drop-down menu 104 might contain identities of other “.wav” files containing different alarm sounds the user might prefer. A repeat option 106 is also provided so that the user can elect to have the alarm repeated.

[0046] The dialog box 100 also has an option 108 that allows a user to enable or disable a dialog box that can be displayed describing the notification when it goes off. An option 110 allows the user to elect whether to have the LED 40 flash, or not, during notification.

[0047] It is noted that the dialog box 100 is provided for example purposes, and other options may be included. For instance, the dialog box 100 might include an option to enable/disable the vibration device 72, or to combine the external notification mechanisms so the LED 40, vibration device 72, and alarm 74 all go off at different times in a continuous cycle.

[0048] Once the user fills in the dialog box 100, the options are stored in the Peg_User_Notification structure. This structure is provided below:

[0049] UserNotificationType {

[0050] DWORD ActionFlags;

[0051] TCHAR *DialogTitle;

[0052] TCHAR *DialogText;

[0053] TCHAR *Sound

[0054] DWORD MaxSound;

[0055] DWORD Reserved;

[0056] }

[0057] The “ActionFlags” parameter specifies the actions to take when a notification event occurs. This parameter is a combination of bit flags, as set forth in the following table.

[0058] The “DialogTitle” pointer specifies the title of the user notification dialog box. If this parameter is null, no dialog is displayed. The “DialogText” pointer specifies the text of the user notification dialog box. If this parameter is null, no dialog is displayed. The “Sound” pointer references a buffer that contains the unqualified name of a sound file to play. The “MaxSound” parameter specifies the maximum length of the string that can be copied into the sound buffer. The “Reserved” parameter is reserved for future use and is presently set to zero.

[0059] With reference again to FIG. 4, the notification manager 68 passes a command to an alarm manager 82 to set an alarm for a notification event. The alarm manager 82 generates a set alarm command that is output to the real-time clock 84 to tell the clock to set an alarm at the scheduled time of the notification event. When the clock reaches the event time, it notifies an interrupt manager 86 through an interrupt. The interrupt manager 86 informs the notification manager 68 that the time of the event has arrived. The notification manager 68 then sends out activation commands to an LED driver 88 to turn on LED 40. A button device driver 90 is also provided to handle interrupts generated when the notification button 54 is depressed to disable the LED 40.

[0060] To explain the architecture in the context of an example situation, suppose the user starts a calendar application 66 and schedules an event notification for 8:00 AM. The user clicks on an “options” button to bring up the dialog box 100 (FIG. 5) to ensure that the LED and alarm are both enabled. The user then closes the dialog box 100 and saves the clock settings. The calendar application 66 calls the notification manager 68 using the PegSetUserNotification API, which includes a pointer to the structure containing information specifying how the LED and alarm are to behave.

[0061] The notification manager 68 stores the scheduled notification and examines it in light of any other scheduled user notifications to determine which notification is associated with the next chronological event to occur. Suppose that the calendar notification is next to occur. The notification manager 68 then calls the alarm manager 82, which in turn sets a hardware alarm for 8:00 AM in real-time clock 84. The user can then exit the application 66 and turn off the device.

[0062] At 8:00 AM, the real-time clock 84 sends an interrupt to interrupt manager 86. The interrupt manager 86 identifies the interrupt as clock-related, and routes the interrupt to the alarm manager 82. Upon receiving the interrupt, the alarm manager 82 pulses the event that the notification manager 68 has been waiting on. The notification manager 68 determines that the event is associated with the 8:00 AM calendar alarm and checks the user options to decide how the user wishes to be notified. Assuming that the user wants the light to flash and an alarm to sound, the notification manager 68 calls the LED device driver 88 to start flashing the LED 40 and concurrently plays the selected alarm. The notification manager 68 also creates a taskbar annunciator.

[0063] Suppose that the use is not present at 8:00 AM. The handheld computing device 20 times out and turns off. Due to the direct coupling to power, however, the LED 40 remains flashing. The flash rate is selected to minimize power usage, without compromising usability. As one example, the LED flashes once every two seconds for {fraction (1/16)}^thof a second. The alarm preferably times out with the computing device 20 to conserve power, but it can be configured to repeat until the user acknowledges the notice.

[0064] When the user returns, he/she sees the flashing LED 40 and presses the deactivation button 54. Depressing button 54 generates an interrupt that is routed by interrupt manager 86 to keyboard device driver 90. The keyboard driver 90 instructs the LED driver 88 to turn off the LED 40. It is noted that the clock 84 and deactivation button 54 work the same if the H/PC 20 is already on. They still generate interrupts, only the interrupts do not wake up the device.

[0065] The deactivation button 54 is preferably implemented to turn off only the external notification mechanisms (i.e., LED and alarm) because these mechanisms can be annoying and consume a significant quantity of power. The taskbar annunciator and optional dialog box remain intact and are not disabled by the deactivation button 54. As a result, the user can open the H/PC and glean more information concerning the notice from the taskbar annunciator and dialog box.

[0066] When the user opens the H/PC, the notification system 80 optionally causes a taskbar annunciator for the calendar application to be displayed. FIG. 6 shows an example screen image 120 showing the task bar 122 with a “Start” softkey 124 and a time/date area 126. A taskbar annunciator 128 for the calendar application is displayed in the time/date area 126. The annunciator 128 is the icon for the calendar application, thereby immediately informing the user that the source of the notification is the calendar application. The user can then click on the taskbar annunciator 128 using the stylus to start the calendar application, as represented by the calendar softkey 130.

[0067] The notification system 80 can optionally display a dialog box that explains the notification to the user; this is faster than starting the originating application, and provides a more noticable notification if the H/PC is being used when the notification event occurs. FIG. 7 shows an example dialog box 140, which contains a message that informs the user of the 8:00 AM alarm. The user is also presented with the option of accepting the alarm or rescheduling it for an additional five-minute period. It is noted that tapping the taskbar annunciator 128 or a softkey in the dialog box 140 deactivates the LED 40 and alarm, in the same manner as pressing the deactivation button 54. Touching any annunciator or acknowledging any dialog box turns off the external signals, since this tells the notification system that the user is aware of the notifications.

[0068] The notification system 80 can handle an arbitrary number of notifications from multiple applications. The notification manager 68 handles the scheduled events in temporal order. In some situations, the flashing LED might represent multiple notifications. Since a single flag bit controls the LED, the user presses the deactivation button 54 once to turn off the LED 40. The user can then open the device and examine the various annunciators to learn which applications are responsible for the notifications.

[0069] A full set of user notification APIs is attached to this disclosure as Appendix A.

[0070] Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention.