U.S. patent application number 13/196528 was filed with the patent office on 2012-08-02 for web based client/server notification engine.
This patent application is currently assigned to MICROSOFT CORPORATION. Invention is credited to Ozan Ozhan, Russell L. Simpson, James R. Van Eaton.
Application Number | 20120198053 13/196528 |
Document ID | / |
Family ID | 38429689 |
Filed Date | 2012-08-02 |
United States Patent
Application |
20120198053 |
Kind Code |
A1 |
Ozhan; Ozan ; et
al. |
August 2, 2012 |
Web Based Client/Server Notification Engine
Abstract
Various technologies and techniques improve the updating of
client content in a client/server arrangement. A client
notification engine of a user interface subscribes to receive
notifications from a central server side notification engine. The
client notification engine polls the server side notification
engine at a specified interval. The server side notification engine
receives and aggregates notifications about and/or from one or more
sources and aggregates them into a collection of relevant
notifications. These notifications are sent to the client where the
different subscriptions originated and are then used by the user
interface in the client to update part of the content being
displayed as appropriate.
Inventors: |
Ozhan; Ozan; (Sammamish,
WA) ; Van Eaton; James R.; (Woodinville, WA) ;
Simpson; Russell L.; (Kirkland, WA) |
Assignee: |
MICROSOFT CORPORATION
Redmond
WA
|
Family ID: |
38429689 |
Appl. No.: |
13/196528 |
Filed: |
August 2, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11338039 |
Jan 24, 2006 |
8015152 |
|
|
13196528 |
|
|
|
|
Current U.S.
Class: |
709/224 |
Current CPC
Class: |
G06Q 10/107 20130101;
H04L 51/04 20130101; Y10S 707/966 20130101; H04L 51/24
20130101 |
Class at
Publication: |
709/224 |
International
Class: |
G06F 15/173 20060101
G06F015/173 |
Claims
1. A method for improving client-side content updates comprising:
sending a registration from a computing system to a central
notification engine to register for update notifications, the
registration including information identifying a plurality of
folders to monitor for changes; after sending the registration,
sending a request from the computing system to the central
notification engine for update notifications associated with the
plurality of folders identified by the registration; if the central
notification engine has notifications to report, receiving a
notification response from the central notification engine, the
notification response including an aggregation of updates from a
first data store and a second data store; if the central
notification engine has no notifications to report, receiving a
notification response from the central notification engine after a
polling interval expires, the notification response indicating that
no updates have occurred.
2. The method of claim 1, wherein the updates include two or more
of the following: email, calendar, contacts, notes, or tasks.
3. The method of claim 1, wherein the request comprises a polling
request.
4. The method of claim 1, wherein the computing system includes a
client-side notification engine.
5. The method of claim 1, further comprising, if the notification
response includes the aggregation of updates, updating a user
interface in response to receiving the notification response.
6. The method of claim 1, wherein, if the central notification
engine has notifications to report, the notification response
includes a list of updated folders, the list identifying folders
that have updated contents.
7. The method of claim 1, wherein if the central notification
engine has no notifications to report, the notification is an empty
response message.
8. The method of claim 1, wherein the notification response is
represented in XML.
9. The method of claim 1, further comprising generating a visible
indication of the notification in a status bar on a display.
10. The method of claim 1, wherein if the central notification
engine has notifications to report, the notification response is
received after the polling interval expires.
11. The method of claim 1, wherein the aggregation of updates
includes a number of items in at least one of the plurality of
folders identified by the registration.
12. A method executed at a central notification engine for updating
content at a computing system, the method comprising: receiving a
registration from a computing system at a central notification
engine, the registration including information identifying a
plurality of folders to monitor for changes; after receiving the
registration, receiving a request from the computing system at the
central notification engine for update notifications associated
with the plurality of folders identified by the registration; if
the central notification engine has notifications to report,
transmitting a notification response from the central notification
engine, the notification response including an aggregation of
updates from a first data store and a second data store; if the
central notification engine has no notifications to report,
transmitting a notification response from the central notification
engine after a polling interval expires, the notification response
indicating that no updates have occurred.
13. The method of claim 12, wherein the notifications are selected
from the group consisting of an email message, a fax message, a
voice mail message, and a reminder message.
14. The method of claim 12, further comprising generating the
notification response at the central notification engine, the
notification response including information from at least one of a
condition advisor and an item count advisor.
15. The method of claim 14, further comprising checking at least
the condition advisor and the item count advisor to determine
whether there are notifications to report.
16. The method of claim 14, wherein the condition advisor and item
count advisor are associated with at least one of the plurality of
folders identified by the registration.
17. The method of claim 12, wherein if the central notification
engine has no notifications to report, the notification is an empty
response message transmitted to the computing system.
18. The method of claim 12, wherein if the central notification
engine has notifications to report, the notification response is
transmitted after the polling interval expires.
19. The method of claim 12, wherein the aggregation of updates
includes a number of items in at least one of the plurality of
folders identified by the registration.
20. The method of claim 12, wherein the first data store and the
second data store comprise first and second folders from among the
plurality of folders identified in the request.
Description
CROSS-REFERENCES TO RELATED APPLICATIONS
[0001] This application is a continuation of application Ser. No.
11/338,039, filed Jan. 24, 2006, which is incorporated herein by
reference.
BACKGROUND
[0002] In today's world of technology, it has become easier than
ever before to communicate with people using one or more of a
variety of communication methods, such as email, telephone, fax,
instant messaging, and so on. Communication and personal organizer
programs typically have the ability to display messages received
from one or more of these various sources. Some communication
programs operate in a web browser, such as MICROSOFT.RTM. Office
OUTLOOK.RTM. Web Access (OWA), Yahoo Mail, AOL Mail, and others.
With such disconnected applications, the server is not contacted
until something is needed, such as when the user performs an action
that requires the page to be updated or changed. When new
communication messages are received on the server, the client is
not updated with the new content until the user selects an option
to perform a manual refresh of the page's contents, or until the
user otherwise takes some action causing the client to request that
the server provide such updated information.
SUMMARY
[0003] Various technologies and techniques are disclosed that
improve the updating of client content in a client/server
arrangement. A client notification engine of a user interface, such
as a communication management or email application, subscribes to
receive notifications from a server side notification engine. The
client polls the server side notification engine at specified
intervals. The server side notification engine receives and
aggregates notifications about and/or from one or more sources and
aggregates them into a collection of relevant notifications at a
specified interval. These notifications are sent to the client
where the different subscriptions originated and are then used by
the user interface in the client to update part of the content
being displayed as appropriate. In one implementation, a status bar
is updated to indicate that new communications have been received,
such as a new email, a new fax, and/or a new voice mail.
Alternatively or additionally, a folder list is updated to display
updated totals, such as the number of unread messages in each
folder or the number of total items in each folder. Alternatively
or additionally, the contents of the folder that the user is
currently viewing are updated if they changed.
[0004] This Summary was provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used as an aid in determining the scope of
the claimed subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 is a diagrammatic view of parts of a system of one
implementation.
[0006] FIG. 2 is a diagrammatic view of additional parts of the
system of FIG. 1 of one implementation.
[0007] FIG. 3 is a high level process flow diagram for one
implementation of the system of FIG. 1.
[0008] FIG. 4 is a logical diagram for one implementation of the
system of FIG. 1 illustrating the communications between the client
side notification engine and the front end server notification
engine for subscribing to and managing notifications.
[0009] FIG. 5 is a process flow diagram for one implementation of
the system of FIG. 1 illustrating the stages involved in
registering for notifications, collecting notification responses,
and processing the response received.
[0010] FIG. 6 is a simulated screen for one implementation of the
system for FIG. 1 which illustrates allowing a user to specify
messaging notification options.
[0011] FIG. 7 is a simulated screen for one implementation of the
system for FIG. 1 which illustrates allowing a user to specify
reminder notification options.
[0012] FIG. 8 is a simulated screen for one implementation of the
system for FIG. 1 which illustrates an email application with
unread totals that were updated based on the subscription process
of FIGS. 4 and 5.
[0013] FIG. 9 is a simulated screen for one implementation of the
system for FIG. 1 which illustrates an email application with a
status bar that was updated based on the subscription process of
FIGS. 4 and 5.
[0014] FIG. 10 is a simulated screen for one implementation of the
system for FIG. 1 which illustrates the new email message that was
received when the user selects the New Mail option on the status
bar of the simulated screen of FIG. 9.
[0015] FIG. 11 is a simulated screen for one implementation of the
system for FIG. 1 which illustrates the new voice mail message that
was received when the user selects the New Voice Mail option on the
status bar of the simulated screen of FIG. 9.
[0016] FIG. 12 is a simulated screen for one implementation of the
system for FIG. 1 which illustrates the new fax message that was
received when the user selects the New Fax option on the status bar
of the simulated screen of FIG. 9.
[0017] FIG. 13 is a simulated screen for one implementation of the
system for FIG. 1 which illustrates the new calendar reminder that
was received when the user selects the Reminders option on the
status bar of the simulated screen of FIG. 9.
DETAILED DESCRIPTION
[0018] For the purposes of promoting an understanding of the
principles of the invention, reference will now be made to the
embodiments illustrated in the drawings and specific language will
be used to describe the same. It will nevertheless be understood
that no limitation of the scope is thereby intended. Any
alterations and further modifications in the described embodiments,
and any further applications of the principles as described herein
are contemplated as would normally occur to one skilled in the
art.
[0019] The system may be described in the general context as a
system that improves the updating of client content in a
client/server arrangement. A client notification engine of a user
interface subscribes to receive notifications from a server side
notification engine. The client notification engine polls the
server side notification engine at a specified interval. The server
side notification engine receives and aggregates notifications
about and/or from one or more sources and/or data stores and
aggregates them into a collection of relevant notifications based
on the context of the user. These notifications are sent to the
client where the different subscriptions originated and are then
used by the user interface in the client to update part of the
content being displayed as appropriate. A status bar or other area
is updated in the user interface to indicate that new
communications have been received, such as a new email, a new fax,
and/or a new voice mail. Alternatively or additionally, a folder
list is updated to display updated totals, such as the number of
unread messages in each folder or the number of total items in each
folder. Alternatively or additionally, the contents of the folder
that the user is currently viewing are updated if they changed.
[0020] The term folder as used herein is referring to any
collection of messages, however they are stored and/or are
represented in a graphical user interface. One of ordinary skill in
the art will appreciate that some operating systems do not use the
term folder when referring to a collection of messages, and that
such scenarios are still covered by the examples illustrated herein
that use the term folder.
[0021] In one implementation, the system is a web-based
communication application such as MICROSOFT.RTM. Office
OUTLOOK.RTM. Web Access (OWA), Yahoo Mail, or AOL Mail. In another
implementation, the system is any type of communication
application, web-based or not, that is not required to maintain a
constant connection to one or more data stores, such as
MICROSOFT.RTM. Office OUTLOOK.RTM. and/or other email clients that
support POP3 and/or other disconnected message protocols. In yet
another implementation, the system is not a communication
application, but serves other purposes, such as project scheduling,
travel planning, or others.
[0022] As shown in FIG. 1, an exemplary computer system to use for
implementing one or more parts of the system includes one or more
computing devices, such as computing devices 100, 130, and/or 150.
In its most basic configuration, computing devices 100, 130, and/or
150 typically include at least one processing unit (102, 132, and
152, respectively) and memory (104, 134, and 154, respectively).
Depending on the exact configuration and type of computing device,
memory (104, 134, or 154) may be volatile (such as RAM),
non-volatile (such as ROM, flash memory, etc.) or some combination
of the two. This most basic configuration is illustrated in FIG. 1
by lines 106, 136, and 156.
[0023] Additionally, devices 100, 130, and/or 150 may also have
additional features/functionality. For example, devices 100, 130,
and/or 150 may also include additional storage (removable and/or
non-removable) including, but not limited to, magnetic or optical
disks or tape. Such additional storage is illustrated in FIG. 1 by
removable storage (108, 138, and 158, respectively) and
non-removable storage (110, 140, and 160, respectively). Computer
storage media includes volatile and nonvolatile, removable and
non-removable media implemented in any method or technology for
storage of information such as computer readable instructions, data
structures, program modules or other data. Memory (104, 134, and
154), removable storage (108, 138, and 158), and non-removable
storage (110, 140, and 160) are all examples of computer storage
media. Computer storage media includes, but is not limited to, RAM,
ROM, EEPROM, flash memory or other memory technology, CD-ROM,
digital versatile disks (DVD) or other optical storage, magnetic
cassettes, magnetic tape, magnetic disk storage or other magnetic
storage devices, or any other medium which can be used to store the
desired information and which can accessed by device 100, 130,
and/or 150. Any such computer storage media may be part of device
100, 130, and/or 150.
[0024] Computing devices 100, 130, and/or 150 include one or more
communication connections that allow computing devices 100, 130,
and/or 150 to communicate with each other and/or one or more other
computing devices over network 116. Communications connection(s)
114, 144, and 164 are examples of communication media.
Communication media typically embodies computer readable
instructions, data structures, program modules or other data in a
modulated data signal such as a carrier wave or other transport
mechanism and includes any information delivery media. The term
"modulated data signal" means a signal that has one or more of its
characteristics set or changed in such a manner as to encode
information in the signal. By way of example, and not limitation,
communication media includes wired media such as a wired network or
direct-wired connection, and wireless media such as acoustic, RF,
infrared and other wireless media. The term computer readable media
as used herein includes both storage media and communication
media.
[0025] In one implementation, computing device 100 is a client
computer that communicates with front end server computer 130 using
communication connection 114 and 144 over network 116. In such an
implementation, user interface 118 of client computing device 100
communicates with notification engine 148 on server computing
device 130 to subscribe to notifications and receive updated
information. Front end server computer 130 communicates with back
end server computing device 150 by network 116 using communication
connections 144 and 164.
[0026] In one implementation, user interface 118 of client
computing device 100 is a browser-based user interface, such as
MICROSOFT.RTM. Office OUTLOOK.RTM. Web Access (OWA), server
computing device 130 is a web server, and back end server computing
device 150 hosts a data store for a communication program, such as
MICROSOFT.RTM. Exchange. In another implementation, user interface
118 of client computing device 100 is a user interface included in
an executable program located on client computing device 100, such
as MICROSOFT.RTM. Office OUTLOOK.RTM., MICROSOFT.RTM. Project, or
Lotus Notes. It will be appreciated that front end server computer
130 and back end server computing device 150 can be the same
computer in alternate embodiments. Furthermore, it will be
appreciated that additional back end server computing device 150
could also be used, such as where multiple data stores are accessed
by front end server computing device 130.
[0027] Computing devices 100, 130, and 150 may also have input
device(s) (112, 142, and 162, respectively) such as keyboard,
mouse, pen, voice input device, touch input device, etc. Output
device(s) (111, 141, and 161, respectively) such as a display,
speakers, printer, etc. may also be included. These devices are
well known in the art and need not be discussed at length here.
[0028] Turning now to FIG. 2 with continued reference to FIG. 1, a
diagrammatic view of additional parts of system of FIG. 1 of one
implementation are illustrated. The same reference numerals are
used on FIG. 2 for those items that are the same as on FIG. 1.
Notification engine 119 of user interface 118 on client computing
device 100 communicates with central notification engine 148 of
front end server computing device 130 to subscribe to
notifications. In one implementation, central notification engine
148 has a notification manager class that contains methods for
creating one or more event queues, deleting an event queue,
flushing and/or disposing of an event queue, creating a condition
advisor, deleting a condition advisor, flushing and/or disposing of
a condition advisor, creating a folder count advisor, deleting a
folder count advisor, flushing and/or disposing of a folder count
advisor, and/or other methods for performing other operations.
[0029] Central notification engine 148 has an event queue object
180, a condition advisor object 182, and a count advisor object 184
that are operable to communicate with one or more data stores 168
on one or more back end server computing devices 150 to obtain
updated information at specified data gathering intervals. A few
non-limiting examples of such data stores include one or more
message stores or products such as MICROSOFT.RTM. Exchange, a POP3
or IMAP email data store, a fax data store, and/or another file or
database. The updated information is then aggregated by central
notification engine 148 and returned to notification engine 119 on
client computing device 100 for further processing by user
interface 118. In one implementation, only relevant information is
returned, such as those specific to the context in which the user
is working. As one non-limiting example, if the user is currently
viewing his or her calendar, then detailed information about the
calendar would be returned, but detailed information about the
contents of the inbox would not be returned. In other
implementations, more information is returned.
[0030] Turning now to FIG. 3 with continued reference to FIGS. 1
and 2, a high level process flow for one implementation is
presented. In one form, the process of FIG. 3 is at least partially
implemented in the operating logic of computing device 100, 130,
and/or 150. The process begins at start point 200 with the user
logging into an email or other application (stage 202). Client
computing device 100 retrieves notification settings for the
particular user (stage 204). If notifications are not enabled for
the particular user (decision point 206), then the process ends at
end point 214. If notifications are enabled for the particular user
(decision point 206), then notification engine 119 of client
computing device 100 communicates with central notification engine
148 on front end server computing device 130 to register for
notifications (stage 208).
[0031] A few non-limiting examples of notifications include email
messages, calendar reminders, task reminders, folder content
changes, folder count totals, etc. Notification engine 119 polls
for and receives notifications that were aggregated by central
notification service about what, if anything changed, updated
totals (such as unread item counts), and/or some details about the
changed and/or new content (stage 210).
[0032] In one implementation, the details about the changes and
status of the various data that are received by the client are
included in one or more text files, such as XML. In another
implementation, the details are received in a scripting language
format, such as JavaScript or VBScript, where the script is
executed and/or consumed by the notification engine on the client.
In yet another implementation, the details are received in another
file type or format for interpretation, execution, and/or display
on the client. User interface 118 interprets the information
received from the central notification engine and updates the user
interface display appropriately (stage 212). In one implementation,
folder unread counts are updated to indicate the number of unread
messages contained in that folder. Alternatively or additionally, a
status or indicator bar in the user interface is updated to display
whether there are new reminders and/or new messages, such as new
email, fax, voice messages, and/or reminders. Alternatively or
additionally, a custom-defined rule can be defined by the user for
display in the status bar, such as to notify the user of any
messages received from the boss. Alternatively or additionally, a
folder the user is currently viewing is updated with any new
content relevant to the particular display. Alternatively or
additionally, other content can also be stored locally for quick
retrieval once the user changes context where the information would
be needed. The process then ends at end point 214.
[0033] Turning now to FIG. 4 with continued reference to FIGS. 1
and 2, a logical diagram describing the process for subscribing to
and managing notifications in one implementation are illustrated.
In one form, the process of FIG. 4 is at least partially
implemented in the operating logic of computing device 100, 130,
and/or 150. Client computing device 100 registers for one or more
notifications, such as reminder notifications (stage 240), folder
tree unread count notifications (stage 242), folder content change
notifications (stage 244), and/or other notifications (stage 246)
with client side notification engine 248 (119 on FIG. 2). Client
side notification engine 248 registers for notifications with front
end server notification engine 256 (148 on FIG. 2) and polls
regularly (stage 252). Front end server notification engine 256
manages event queues 258, condition advisors 260, folder count
advisor 262, and/or other information tracking objects 264.
[0034] Front end server notification engine 256 registers for
notifications (stage 266) with one or more data stores 168 on back
end server computing device(s) 268 (150 on FIG. 2). Back end server
computing device 268 updates front end server notification engine
256 with notifications periodically (stage 270). In other words,
the event queue(s), content advisors, and item count advisors are
updated accordingly. In one implementation, front end server
notification engine 256 combines the responses for all notification
requests (stage 254) and returns only the necessary ones (such as
the relevant ones) to the client side notification engine 248. The
client side notification engine 248 distributes notifications to
user interface components and performs the necessary actions (stage
250), such as to update the display.
[0035] Turning now to FIG. 5 with continued reference to FIGS. 1
and 2, the stages involved in registering for notifications,
collecting notification responses, and processing the response
received in one implementation are illustrated. In one form, the
process of FIG. 5 is at least partially implemented in the
operating logic of computing device 100, 130, and/or 150. The
process begins at start point 300 with the user logging in to the
application (stage 302). Client side notification engine 248 of
user interface 118 registers for notifications with the central
notification engine 148. In one implementation, central
notification engine 148 creates folder modified condition advisors
for all folders, event queues for new notifications, such as in the
Inbox, and/or folder item count advisors for some or all of the
folders (stage 304). If the session has not timed out or otherwise
ended (decision point 306), then the client notification engine 119
checks to determine whether the polling interval time has passed
(decision 308). The client notification engine 119 waits until the
polling interval passes by (decision point 308) to poll the central
notification engine 148 for notifications (stage 310). If there are
notifications to report (decision point 312), then the central
notification engine 148 generates a response based on the
information in the event queue(s), condition advisors, and folder
unread count advisor(s) and sends them to the client side
notification engine 248 for further processing by the user
interface 118 (stage 316). User interface 118 interprets and/or
otherwise executes the response, and updates the appropriate user
interface views (stage 318).
[0036] If there are no notifications to report (decision point
312), then the central notification engine 148 generates an empty
or blank response and sends it to the client side notification
engine 248 (stage 314). The process then repeats for each polling
interval (decision point 308) or until the user session times out
or the user closes the application (decision point 306). If the
session times out or the user otherwise ends the session or
application (decision point 306), such as by closing the browser or
program, then the event queue, condition advisors, and folder
unread count advisor objects are destroyed (stage 320) to free up
system resources. The process then ends at end point 322.
[0037] FIG. 6 is a simulated screen 340 for one implementation of
the system for FIG. 1 which illustrates allowing a user to specify
messaging notification options. The user can select whether to
enable or disable options that display a notification message when
new mail arrives 342, display a notification message when a new
voice mail arrives 344, display a notification when new voice
message arrives 346, and/or to play a sound when new message
arrives 348. In one implementation, if any one or more of these
options are enabled (decision point 206 on FIG. 3), then user
interface 118 of client computing device 100 registers for
messaging event notifications with central notification engine 148
on front end server computing device 130.
[0038] FIG. 7 is a simulated screen 350 for one implementation of
the system for FIG. 1 which illustrates allowing a user to specify
reminder notification options. The user can select whether to
enable or disable options that show reminder alerts for calendar
items 352, show reminder alerts for task items 354, plays a sound
when a reminder is due 356, and/or to set the default reminder time
frame 358. In one implementation, if any one or more of options
352, 354, or 356 are enabled (decision point 206 on FIG. 3), then
user interface 118 of client computing device 100 registers for
reminder event notifications with central notification engine 148
on front end server computing device 130.
[0039] After messaging and/or reminder notifications are registered
with central notification engine 148, user interface 118 then waits
for the polling time to pass by (decision point 308), polls for and
receives aggregated notifications from the central notification
engine 148 (stage 310) and processes the response to update the
user interface accordingly (stage 318).
[0040] Non-limiting examples of how the user interface 118 can be
updated based on the aggregated notifications are shown in
simulated screens 8-13. FIG. 8 is a simulated screen 360 for one
implementation of the system for FIG. 1 which illustrates an email
application with unread totals that were updated based on the event
subscription process of FIGS. 3-5. Simulated screen 360 is a
browser-based communication/personal organizer application that has
various folders, such as Inbox 364, one or more user defined
folder(s), Deleted Items 366, Calendar 368, and/or other folders,
for displaying information to the user and allowing the user to
manage his or her information and/or schedule. Upon receiving
aggregated notifications from central notification engine (stage
210), folder counts are updated, such as "(7)" for Inbox 364,
and/or others shown on screen 360. In one implementation, the
totals represent the total number of unread items in the folder. In
another implementation, the total represents the total number of
items in the folder. Alternatively or additionally, the user
interface can be updated automatically to display new content that
is relevant to the context that the user is working in. For
example, since the user has the Inbox folder 364 selected, new
messages can be displayed in message area 369 based upon a sort
order setting specified by the user or by a system default
setting.
[0041] As shown in FIG. 9, in one implementation, a status bar is
updated based on the aggregated notifications received from central
notification engine (stage 210). For example, status bar 377 on
simulated screen 370 includes four notification messages: New Email
375, New Voice Mail 371, New Fax 372, and New Reminder 373 that
represent the type of new messages and/or reminders (e.g. calendar
and/or task reminders) that have been received by the user. Other
variations are also possible that include some or additional
message and/or reminder notifications than these. In one
implementation, a Help option 374 is displayed in the status
bar.
[0042] Turning now to FIG. 10, in one implementation, when the user
selects the New Email notification message 382 (or a particular
notification) in the status bar of screen 380, a snippet of the
message 384 is shown near the status bar area to give the user a
preview of the message. In one implementation, the New Email
notification message 382 (or selected notification) then disappears
after the user selects it from the status bar area. In another
implementation, the New Email notification message 382 (or selected
notification) is displayed until the user accesses the message in
the Inbox folder and causes the status of the message to change to
"read".
[0043] Instead of or in addition to showing a snippet of the
message 384 when the user selects New Email notification message
382, the snippet 384 can be displayed for a specified period of
time (such as 5 seconds) when the screen is first updated. In
another implementation, when the user selects New Email
notification message 382, contents 386 of inbox folder are updated
to include the new message(s). In yet another implementation,
contents 386 of inbox folder are updated automatically when the
aggregated notifications are received from the central notification
engine 148. Other variations are also possible that include
combinations of these, fewer, and/or additional variations.
[0044] Similarly to FIG. 10, FIGS. 11-13 are simulated screens
(390, 400, and 410, respectively) for one implementation of the
system for FIG. 1 which illustrate what happens in the status bar
area when the user selects the other options. For example,
simulated screen 390 of FIG. 11 illustrates what happens in the
status bar area when the user selects the New Voice Mail
notification message 392. A snippet of the voice mail message 394
appears near the status bar and includes details such as the
caller's phone number and the length of the message. Simulated
screen 400 of FIG. 12 illustrates an example of what happens in the
status bar area when the user selects the New Fax notification
message 402. A snippet of the message 404 appears near the status
bar and includes details such as the sender's fax number and/or the
number of pages received. Alternatively or additionally, simulated
screen 410 of FIG. 13 illustrates an example of what happens in the
status bar area when the user selects the New Reminders
notification message 412. A snippet of the reminder message 414
appears near the status bar and additional details about the
appointment and/or task. In one implementation, calendar and task
reminders are grouped together in the same reminder area. In
another implementation, calendar reminders have a separate
notification message on the status bar from task reminders.
[0045] With respect to simulated screens 9-13, numerous other
variations are also possible for determining when and where to
display the respective snippet, if at all. In some implementations,
part or all of the details related to the message and/or reminder
are displayed and/or audibly rendered to the user in some
fashion.
[0046] The examples in FIGS. 7-13 are for purposes of illustration
only, and are not limiting in nature. For example, other variations
are also possible, such as using the technologies and techniques
discussed herein for receiving updated content from a server in
applications other than communications programs, such as from a
project planning application, such as MICROSOFT.RTM. Project. Other
examples can include any type of application that does not maintain
a constant connection with the server while a user is accessing the
application.
[0047] Although the subject matter has been described in language
specific to structural features and/or methodological acts, it is
to be understood that the subject matter defined in the appended
claims is not necessarily limited to the specific features or acts
described above. Rather, the specific features and acts described
above are disclosed as example forms of implementing the claims.
All equivalents, changes, and modifications that come within the
spirit of the implementations as described herein and/or by the
following claims are desired to be protected.
[0048] For example, a person of ordinary skill in the computer
software art will recognize that the client and/or server
arrangements, user interface screen content, and/or data layouts as
described in the examples discussed herein could be organized
differently on one or more computers to include fewer or additional
options or features than as portrayed in the examples.
* * * * *