U.S. patent application number 11/469058 was filed with the patent office on 2007-01-11 for notification platform architecture.
This patent application is currently assigned to MICROSOFT CORPORATION. Invention is credited to Eric J. Horvitz, David O. Hovel, Andrew W. Jacobs, Carl M. Kadie.
Application Number | 20070011314 11/469058 |
Document ID | / |
Family ID | 34062209 |
Filed Date | 2007-01-11 |
United States Patent
Application |
20070011314 |
Kind Code |
A1 |
Horvitz; Eric J. ; et
al. |
January 11, 2007 |
NOTIFICATION PLATFORM ARCHITECTURE
Abstract
An architecture for a notification platform is disclosed. In one
embodiment, the architecture includes a user mechanism, one or more
notification sources and sinks, and a notification manager. The
user mechanism stores information regarding notification parameters
of a user, such as the user's default notification preferences, and
may also contain, access, and/or infer contextual information. Each
notification source generates notifications intended for the user,
while each notification sink can provide the notifications to the
user. Notification sources and sinks provide information via
standardized notification schema. The notification manager is
designed to appropriately convey the notifications generated by the
sources to the sinks, based on information provided by the user
mechanism, and by the sources and sinks. As disclosed, the
architecture is applicable to entities other users as well.
Inventors: |
Horvitz; Eric J.; (Kirkland,
WA) ; Hovel; David O.; (Bellevue, WA) ;
Jacobs; Andrew W.; (Seattle, WA) ; Kadie; Carl
M.; (Bellevue, WA) |
Correspondence
Address: |
AMIN. TUROCY & CALVIN, LLP
24TH FLOOR, NATIONAL CITY CENTER
1900 EAST NINTH STREET
CLEVELAND
OH
44114
US
|
Assignee: |
MICROSOFT CORPORATION
One Microsoft Way
Redmond
WA
|
Family ID: |
34062209 |
Appl. No.: |
11/469058 |
Filed: |
August 31, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09596635 |
Jun 19, 2000 |
6847924 |
|
|
11469058 |
Aug 31, 2006 |
|
|
|
60189801 |
Mar 16, 2000 |
|
|
|
Current U.S.
Class: |
709/224 |
Current CPC
Class: |
G06Q 10/107 20130101;
G06F 17/18 20130101 |
Class at
Publication: |
709/224 |
International
Class: |
G06F 15/173 20060101
G06F015/173 |
Claims
1. A computerized system comprising: a mechanism designed to access
and store information regarding context information and
notification parameters, the notification parameters including at
least one of: an automatically inferred time criticality parameter
indicating time-dependent decay of the value of information
contained in a notification, an automatically inferred novelty
parameter that indicates whether a notification is new to a user,
and an automatically inferred fidelity parameter that indicates a
loss of value of a notification due to truncation and/or
summarization of the information; at least one notification source,
each source designed to generate notifications; at least one
notification sink, each sink designed to receive the notifications;
and, a notification manager designed to convey the notifications
generated by the at least one notification source to the at least
one notification sink based on the information stored in the
mechanism.
2. The system of claim 1, wherein the context information and
notification parameters are for an entity.
3. The system of claim 2, wherein the entity comprises one of a
user, an agent, a process, a server, a computer, a machine, a
company, an organization; a business, a computer program, a
service, and a thread.
4. The system of claim 1, wherein the notifications generated by
the at least one notification source are intended for an
entity.
5. The system of claim 1, wherein the notifications received by the
at least one sink are to be provided to an entity.
6. The system of claim 1, wherein the mechanism comprises a
notification parameters store storing default notification
preferences for an entity as a profile.
7. The system of claim 1, wherein the mechanism comprises a user
mechanism.
8. The system of claim 7, wherein the user mechanism comprises a
user context mechanism designed to determine a current context of
the user, based on at least one context source.
9. The system of claim 8, wherein the at least one context source
comprises one or more of: visual information of the user, desktop
information of the user, personal-information manager (PIM)
information of the user, current time and day, mobile device usage
of the user, and location of the user.
10. The system of claim 8, wherein the context mechanism is more
specifically designed to determine the current context based on the
at least one context source by utilizing one or more of: a
statistical model, a profile, direct access of user location and
activity, and real-time user specification of user state.
11. The system of claim 1, wherein the at least one notification
source comprises at least one of: a pull-type notification source;
and a push-type notification source.
12. The system of claim 1, wherein each notification source has
parameters associated with it representing at least one of: a
message class of a current notification generated by the
notification source indicating a type of communication of the
current notification; a relevance of the current notification
indicating a likelihood of the relevance of information contained
in the current notification; and an importance of a current
notification generated by the notification source indicating value
of information contained in the current notification.
13. The system of claim 1, wherein each notification sink has
parameters associated with it representing at least one of a device
class of the notification sink a type of device that the
notification sink is; a transmission reliability of the
notification sink indicating a likelihood that an entity will
receive information contained within a notification conveyed to the
notification sink; a cost of communication of the notification sink
indicating a communication cost incurred by the entity when
receiving information contained within a notification conveyed to
the notification sink; and, a cost of disruption of the
notification sink indicating a disruption cost incurred by the
entity when receiving information contained within a notification
conveyed to the notification sink.
14. A computerized system comprising: a user mechanism designed to
store information regarding notification parameters, and
comprising: a user notification parameters store designed to store
default notification preferences for a user and notification
parameters including at least one of: an automatically inferred
time criticality parameter indicating time-dependent decay of the
value of information contained in a notification, an automatically
inferred novelty parameter that indicates whether a user already
knows the information in a notification, and an automatically
inferred fidelity parameter that indicates a loss of value of a
notification due to truncation of the information; a user context
mechanism designed to determine a current context of the user,
based on at least one context source; at least one notification
source, each source designed to generate notifications intended for
the user; at least one notification sink, each sink designed to
provide the notifications to the user; and, a notification manager
designed to convey the notifications generated by the at least one
notification source to the at least one notification sink based on
the information stored in the user mechanism by performing a
decision-theoretic analysis.
15. The system of claim 14, wherein the user context mechanism is
more specifically designed to determine the current context based
on the at least one context source by utilizing one or more of: a
statistical model, a user profile, direct access of user location
and activity, and real-tune user specification of user state.
16. The system of claim 14, wherein each notification source has
parameters associated with it representing at least one of: an
importance of a current notification generated by the notification
source indicating value of information contained in the current
notification to the user; a message class of a current notification
generated by the notification source indicating a type of
communication of the current notification; a relevance of the
current notification indicating a likelihood of the relevance of
information contained in the current notification to the user.
17. The system of claim 14, wherein the at least one notification
source comprises at least one of a pull-type notification source,
and a push-type notification source.
18. The system of claim 14, wherein each notification sink has
parameters associated with it representing at least one of: a
device class of the notification sink indicating a type of device
that the notification is; a transmission reliability of the
notification sink indicating a likelihood that the user will
receive information contained within a notification conveyed to the
notification sink; a cost of communication of the notification sink
indicating a communication cost incurred by the user when receiving
information contained within a notification conveyed to the
notification sink; and, a cost of disruption of the notification
sink indicating a disruption cost incurred by the user when
receiving information contained within a notification conveyed to
the 10 notification sink.
19. A computer-implemented method comprising: generating one or
more notifications intended for a user by one or more notification
sources; receiving the one or more notifications by a notification
manager; generating contextual information by a user mechanism, the
mechanism also storing information regarding notification
parameters of the user, the notification parameters including at
least one of: an automatically inferred time criticality parameter
indicating time-dependent value of information contained in a
notification, an automatically inferred novelty parameter that
indicates whether a user is already aware of the contents a
notification, and an automatically inferred fidelity parameter that
indicates a loss of value of a notification due to summarization of
the information; receiving the contextual information by the
notification manager; determining which of the notifications to
convey to which of one or more notification sinks by the
notification manager, based on at least one or more of the
contextual information and the information regarding the
notification parameters of the user; and, conveying the which of
the notifications to the which of the one or more notification
sinks by the notification manager.
20. The method of claim 19, wherein generating the contextual
information comprises generating the contextual information by a
user context mechanism of the user mechanism.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This is a continuation application of U.S. patent
application Ser. No. 09/596,365 filed on Jun. 17, 2000, entitled
"Notification Platform Architecture", which claims the benefit of
U.S. Provisional Patent Application Ser. No. 60/189,801, filed Mar.
16, 2000, and entitled "Attentional Systems and Interfaces". The
entireties of these applications are incorporated herein by
reference.
FIELD OF THE INVENTION
[0002] This invention relates generally to unified receipt and
notification of alerts generated by varied devices and applications
for conveyance to a user, and more particularly to an architecture
for such unified context sensing and analysis, alert receipt, and
notification.
BACKGROUND OF THE INVENTION
[0003] Many computer users today receive information from a number
of different sources, and utilize a number of different devices
order to access this information. For example, a user may receive
e-mail and instant messages over a computer, pages over a pager,
voice-mail over a phone, such as a cellular ("cell") or landline
phone, news information over the computer, etc. This makes it
difficult for the user to receive all his or her different
information wherever the user happens to be.
[0004] For example, a user may be away from his or her computer,
but receive an important e-mail. The user may have access only to a
cell phone or a pager, however. As another example, the user may be
working on the computer, and have turned off the ringer and
voice-mail indicator on the phone. When an important voice-mail is
left, the user has no way of receiving this information on the
computer.
[0005] Moreover, many of the alerts may not be important to the
user--for example, an e-mail from the user's manager or co-worker
should receive higher priority than the latest sports scores. More
generally, the value of the information contained in an alert
should be balanced with the costs associated with the disruption of
the user by an alert. Both the costs and value may be context
sensitive. Beyond notifications about communications, users are
alerted with increasing numbers of services, error messages, and
computerized offers for assistance.
[0006] The prior art, however, does not provide for alerts
following the user, for the prioritization of the alerts, nor for
considering the potentially context-sensitive value and costs
associated with notifications. For these and other reasons,
therefore, there is a need for the present invention.
SUMMARY OF THE INVENTION
[0007] This invention relates to the architecture for a
notification platform. In one embodiment, the architecture includes
a user mechanism, one or more notification sources and sinks, and a
notification manager. The user mechanism is designed to both store
user profile information regarding notification parameters of a
user, such as the user's default notification preferences, and to
provide a user context identification and updating service. Each
notification source is designed to generate notifications intended
for the user, while each notification sink is designed to provide
the notifications to the user. The notification manager is designed
to convey the notifications generated by the sources to the sinks,
based on information stored by the user mechanism and on
information provided or inferred about the urgencies of the
notifications. For example, the notification manager can access or
infer the context of the user (e.g., the user's current location
and focus of attention). This can be done based on a consideration
of multiple sources of information. Such sources of information can
include the user's context profile, the user's online calendar, the
time of day, events about the world, organization, system, and/or
the user's activity. The notification can then determine through an
analysis of the context and the urgency of the information which of
the notifications should be conveyed to the user, via which of the
sinks, and in which manner or modality provided by the sinks.
[0008] Embodiments of the invention provide for advantages. A user
may, for example, receive e-mail alerts on a cell phone, or
voice-mail on a desktop computer, as is determined appropriate by
the notification manager. Thus, notifications from notification
sources are passed to the notification manager, which determines
whether the user should be notified. If the manager determines that
the user should be notified, then the manager also determines how
the user should be notified. This can be based on the information
stored in the user profile, including such information as the
user's preferences and current context, and notifies the
appropriate notification sinks. The sinks can include, for example,
a desktop computer, a cell phone, a pager, etc.
[0009] Furthermore, the methods and architecture of the
notification platform generalize to any notification, including
those associated with the potential provision of a service by a
software component in a desktop or mobile setting. Such
notifications include: [0010] alerts about services such as those
that seek to automatically provide assistance or tips to a user
working with a software application and/or automatically perform
scheduling by examining e-mail at the focus of a user's attention;
[0011] alerts that notify the user to upcoming appointments or
engagements; [0012] alerts that relay important changes in the
location, proximity, or attentional status of friends and
colleagues; and, [0013] alerts that issue background queries based
on text being composed or reviewed by users and present the results
of such background searches to the user.
[0014] The invention includes computer-implemented methods,
machine-readable media, computerized systems, and computers of
varying scopes. Other aspects, embodiments and advantages of the
invention, beyond those described here, will become apparent by
reading the detailed description and with reference to the
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1 is a diagram of an example computerized device in
conjunction with which embodiments of the invention can be
practiced;
[0016] FIG. 2 is a diagram of a notification architecture according
to an embodiment of the invention;
[0017] FIG. 3 is a diagram illustrating the user mechanism of the
architecture of FIG. 2 in more detail, in accordance with an
embodiment of the invention;
[0018] FIG. 4 is a diagram of a graph showing an example decay of
the utility of information contained within a notification over
time, according to an embodiment of the invention; and,
[0019] FIG. 5 is a flowchart of a method according to an embodiment
of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0020] In the following detailed description of exemplary
embodiments of the invention, reference is made to the accompanying
drawings, which form a part hereof, and in which is shown by way of
illustration specific exemplary embodiments in which the invention
may be practiced. These embodiments are described in sufficient
detail to enable those skilled in the art to practice the
invention, and it is to be understood that other embodiments may be
utilized and that logical, mechanical, electrical, and other
changes may be made without departing from the spirit or scope of
the present invention. The following detailed description is,
therefore, not to be taken in a limiting sense, and the scope of
the present invention is defined only by the appended claims.
Example Computerized Device
[0021] Referring to FIG. 1, a diagram of an example computerized
device 100 in conjunction with which embodiments of the invention
may be practiced is shown. The example computerized device can be,
for example, a desktop computer, a laptop computer, a personal
digital assistant (PDA), a cell phone, etc.; the invention is not
so limited. The description of FIG. 1 is intended to provide a
brief, general description of a suitable computerized device in
conjunction with which the invention may be implemented. Those
skilled in the art will appreciate that the invention may be
practiced with other computer system configurations, including
hand-held devices, multiprocessor systems, microprocessor-based or
programmable consumer electronics, network PC's, minicomputers,
mainframe computers, and the like. The invention may also be
practiced in distributed computing environments where tasks are
performed by remote processing devices that are linked through a
communications network.
[0022] The device 100 includes one or more of the following
components: processor(s) 102, memory 104, storage 106, a
communications component 108, input device(s) 110, a display 112,
and output device(s) 114. It is noted, that for a particular
instantiation of the device 100, one or more of these components
may not be present. For example, a PDA may not have any output
device(s) 114, while a cell phone may not have storage 106, etc.
Thus, the description of the device 100 is to be used as an
overview as to the types of components that typically reside within
such a device 100, and is not meant as a limiting or exhaustive
description of such computerized devices.
[0023] The processor(s) 102 may include a single central-processing
unit (CPU), or a plurality of processing units, commonly referred
to as a parallel processing environment. The memory 104 may include
read only memory (ROM) 24 and/or random access memory (RAM) 25. The
storage 106 may be any type of storage, such as fixed-media storage
devices such as hard disk drives, flash or other non-volatile
memory, as well as removable-media storage devices, such as tape
drives, optical drives like CD-ROM's, floppy disk drives, etc. The
storage and their associated computer-readable media provide
non-volatile storage of computer-readable instructions, data
structures, program modules, and other data. It should be
appreciated by those skilled in the art that any type of
computer-readable media which can store data that is accessible by
a computer, such as magnetic cassettes, flash memory cards, digital
video disks, Bernoulli cartridges, random access memories (RAMs),
read only memories (ROMs), and the like, may be used.
[0024] Because the device 100 may operate in a network environment,
such as the Internet, intranets, extranets, local-area networks
(LAN's), wide-area networks (WAN's), etc., a communications
component 108 can be present in or attached to the device 100. Such
a component 108 may be one or more of a network card, such as an
Ethernet card, an analog modem, a cable modem, a digital subscriber
loop (DSL) modem, an Integrated Services Digital Network (ISDN)
adapter, etc.; the invention is not so limited. Furthermore, the
input device(s) 110 are the mechanisms by which a user indicates
input to the device 100. Such device(s) 110 include keyboards,
pointing devices, microphones, joysticks, game pads, satellite
dishes, scanners, etc. The display 112 is how the device 100
typically shows output to the user, and can include, for example,
cathode-ray tube (CRT) display devices, flat-panel display (FPD)
display devices, etc. In addition, the device 100 may indicate
output to the user via other output device(s) 114, such as
speakers, printers, etc.
Architecture
[0025] In this section of the detailed description, a notification
architecture according to an embodiment of the invention is
described, in conjunction with the diagram of FIG. 2. The
architecture 200 of FIG. 2 includes a user mechanism 202, a
notification manager 204 (also referred to as an event broker), a
number of notification sources 206a, 206b, . . . , 206n, and a
number of notification sinks 208a, 208b, . . . , 208m. The sources
are also referred to as event publishers, while the sinks are also
referred to as event subscribers. There can be any number of sinks
and sources. In general, the notification manager 204 conveys
notifications, which are also referred to as events or alerts, from
the sources 206 to the sinks 208, based on information stored in
the user mechanism 202. Each of the components of the architecture
200 of FIG. 2 is now described in turn
[0026] The user mechanism 202 stores information regarding
variables and parameters of a user that influence notification
decision-making. For example, the parameters may include contextual
information, such as the user's typical locations and attentional
focus or activities per the time of day and the day of the week,
and additional parameters conditioned on such parameters, such as
the devices users tend to have in different locations. Such
parameters may also be functions of observations made autonomously
via one or more sensors. For example, profiles may be selected or
modified based on information about a user's location as might be
provided by a global positioning system (GPS) subsystem, on
information about the type of device being used and/or the pattern
of usage of the device, the last time a device of a particular type
was accessed by the user, etc. Furthermore, as is described in more
detail later in the application, automated inference may also be
employed, to dynamically infer parameters such as location and
attention. The profile parameters may be stored as a user profile
that can be edited by the user. Beyond relying on sets of
predefined profiles or dynamic inference, the notification
architecture can also allow users to specify in real-time his or
her state, such as the user not being available except for
important notifications for the next x hours, or until a given
time.
[0027] The parameters can also include default notification
preference parameters regarding a user's preference as to being
disturbed by notifications of different kinds in different
settings, which can be used as the basis from which to make
notification decisions by the notification manager 204, and to the
basis upon which a particular user can make changes. The parameters
may include default parameters as to how the user wishes to be
notified in different situations, such as by cell phone, by pager,
etc. The parameters can include such assessments as the costs of
disruption associated with being alerted by different modes in
different settings. That is, in one embodiment, the parameters can
include contextual parameters indicating the likelihoods that the
user is in different locations, the likelihoods that different
devices are available, and the likelihoods of his or her
attentional status at a given time, as well as notification
parameters indicating how the user desires to be notified at a
given time.
[0028] The information stored by the user mechanism 202 is in one
embodiment inclusive of contextual information determined by the
mechanism 202. The contextual information is determined by the
mechanism 202 by discerning the user's location and attentional
status based on one or more contextual information sources, as is
described in more detail in a later section of the detailed
description. The mechanism 202, for example, may be able to
determine with precision the actual location of the user via a
global positioning system (GPS) that is a part of a user's car,
cell phone, etc. The mechanism 202 may also use a statistical model
to determine the likelihood that the user is in a given state of
attention by considering background assessments and/or observations
gathered through considering such information as the type of day,
the time of day, the data in the user's calendar, and observations
about the user's activity. This is described in more detailed in
the cofiled, copending and coassigned patent application entitled
"Contextual Models and Methods for Inferring Attention and
Location." [attorney docket no. 1018.101US4] The given state of
attention can include whether the user is open to receiving
notification, busy and not open to receiving notification, etc. The
type of day can include weekdays, weekends, holidays, etc.
[0029] Each of the sources 206a, 206b, . . . , 206n is able to
generate notifications intended for the user. For example, the
sources 206 may include communications, such as Internet and
network-based communications, local desktop computer-based
communications, and telephony communications, as well as software
services, such as intelligent help, background queries, automated
scheduling, etc. A notification source is defined generally herein
as that which generates events, which can also be referred to as
notifications and alerts, intended to alert a user, or a proxy for
the user, about information, services, or a system or world event.
A notification source can also be referred to as an event
source.
[0030] For example, e-mail may be generated as notifications by an
e-mail notification source such that it is prioritized, where the
host application program generating the notification assigns the
e-mail with a relative priority corresponding to the likely
importance or urgency of the e-mail to the user. The e-mail may
also be sent without regard to their relative importance to the
user. Desktop-centric notifications can include an automated dialog
with the goal of alerting a user to a potentially valuable service
that he or she may wish to execute (e.g., scheduling from a
message), information that the user may wish to review (e.g.,
derived from a background query), or errors and other alerts
generated by a desktop computer. Internet-related services can
include notifications including information that the user has
subscribed to, such as headlines of current news every so often,
stock quotes, etc.
[0031] Other notifications can include background queries (e.g.,
while the user is working, text that the user is currently working
on may be reviewed, such that background queries regarding the text
are formulated and issued to search engines), scheduling tasks from
a scheduling or other program, etc. Notification sources 206 can
themselves be push-type or pull-type sources. Push-type sources are
those that automatically generate and send information without a
corresponding request, such as headline news and other
Internet-related services that send information automatically once
subscribed to. Pull-type sources are those that send information in
response to a request, such as e-mail being received after a mail
server is polled. Still other notification sources include the
following: [0032] e-mail desktop applications such as calendar
systems; [0033] computer systems (e.g., that may alert the user
with messages that information about alerts about system activity
or problems); [0034] Internet-related services, appointment
information, scheduling queries; [0035] changes in documents or
numbers of certain kinds of documents in one or more shared
folders; [0036] availability of new documents in response to
standing or persistent queries for information; and, [0037]
information sources for information about people and their
presence, their change in location, their proximity (e.g., let me
know when I am traveling if another employee of Microsoft is within
10 miles of me"), or their availability (e.g., let me know when
Steve is available for a conversation and is near a high-speed link
that can support full video teleconferencing").
[0038] Each of the notification sinks 208a, 208b, . . . , 208n is
able to provide the notifications to the user. For example, such
notification sinks 208 can include computers, such as desktop
and/or laptop computers, handheld computers, cell phones, landline
phones, pagers, automotive-based computers, etc. It is noted that
some of the sinks 208 can convey notifications more richly than
other of the sinks 208. For example, a desktop computer typically
has speakers and a relatively large color display attached to it,
as well as having a high bandwidth for receiving information when
attached to a local network or to the Internet. Therefore,
notifications can be conveyed by the desktop computer to the user
in a relatively rich manner. Conversely, most cell phones have a
small display that is black and white, and receive information at
relatively low bandwidth. Correspondingly, the information
associated with notifications conveyed by the cell phone usually
must be shorter and geared towards the phone's known limitations.
Thus, the content of a notification may differ depending on whether
it is to be sent to a cell phone or a desktop computer. A
notification sink can in one embodiment refer to that which
subscribes, via an event subscription service, to events or
notifications.
[0039] The notification manager 204 accesses the information stored
by the user mechanism 202, and makes a decision as to which of the
notifications it receives from the sources 206 to convey to which
of the sinks 208 based on this information. Furthermore, the
manager 204 is able to determine how the notification is to be
conveyed, depending on which of the sinks 208 it has selected to
send the information to. For example, it may determine that the
notification should be summarized before being provided to a given
of the sinks 208. The manager 204 is in one embodiment a computer
program executed by a processor of a computer from a
machine-readable medium such as a memory thereof.
[0040] The invention is not limited to how the manager 204 makes
its decisions as to which of the notifications to convey to which
of the notification sinks, and in what manner the notifications are
conveyed. In one embodiment, a decision-theoretic analysis can be
made. For example, the notification manager can be designed to
infer important uncertainties about variables including a user's
location, attention, device availability, and amount of time until
the user will access the information if there were no alert. The
notification manager can then make notification decisions about
whether to alert a user to a notification, and if so, the nature of
the summarization and the best device or devices to employ for
relaying the notification. Such a particular embodiment is
described in the cofiled, copending and coassigned case entitled
"Decision-Theoretic Principles and Policies for Notification."
[attorney docket no. 1018.101US3] In general, the manager 204
determines the net expected value of a notification. In doing so,
it can consider the following: [0041] the fidelity and transmission
reliability of each available notification sink; [0042] the
attentional cost of disturbing the user; [0043] the novelty of the
information to the user; [0044] the time until the user will review
the information on his or her own; [0045] the potentially
context-sensitive value of the information; and, [0046] the
increasing and/or decreasing value over time of the information
contained within the notification.
[0047] The inferences made about uncertainties thus may be
generated as expected likelihoods of values such as the cost of
disruption to the user with the use of a particular mode of a
particular device given some attentional state of the user, etc.
The notification manager 204 makes decisions as to one or more of
the following: [0048] what the user is currently attending to and
doing (based on, for example, contextual information); [0049] where
the user currently is; [0050] how important the information is;
[0051] what is the cost of deferring the notification; [0052] how
distracting would a notification be; [0053] what is the likelihood
of getting through to the user; and, what is the fidelity loss
associated with the use of a specific mode of a given notification
sink. Therefore, ultimately, the notification manager 204 performs
an analysis, such as a decision-theoretic analysis, of pending and
active notifications, evaluates context-dependent variables
provided by information sinks and sources, and infers key
uncertainties, such as the time until a user is likely to review
provided information and the user's location and current
attentional state.
[0054] As used herein, inference refers generally to the process of
reasoning about or inferring states of the system, environment, or
user from a set of observations as captured via events and/or data.
Inference can be used to identify a specific context or action, or
can be employed to generate a probability distribution over states.
The inference can be probabilistic--that is, the computation of a
probability distribution over states of interest based on a
consideration of data and events. Inference can also refer to
techniques used for composing higher-level events from a set of
events and/or data. Such inference results in the construction of
new events or actions from a set of observed events and/or stored
event data, whether or not the events are correlated in close
temporal proximity, and whether the events and data come from one
or several event and data sources.
[0055] Furthermore, in one embodiment, the notification manager 204
accesses information stored in a user profile by the user mechanism
202 in lieu of or to support a personalized decision-theoretic
analysis. For example, the user profile may indicate that at a
given time, the user prefers to be notified via a pager, and only
if the notification has a predetermined importance level. Such
information can be used as a baseline from which to start a
decision-theoretic analysis, or can be the only manner by which the
manager 204 determines how and whether to notify the user.
[0056] In one embodiment of the invention, the notification
platform architecture is constructed as a layer that resides over
an eventing or messaging infrastructure. However, the invention is
not limited to any particular eventing infrastructure. Such
eventing and messaging systems and protocols include: [0057]
HyperText Transport Protocol (HTTP), or HTTP extensions as known
within the art; [0058] Simple Object Access Protocol (SOAP), as
known within the art; Windows Management Instrumentation (WMI), as
known within the art; [0059] Jini, as known within the art; and,
[0060] any type of communications protocols, such as those based on
packet-switching protocols, etc. Furthermore, in one embodiment,
the architecture is constructed as a layer that resides over a
flexible distributed computational infrastructure, as can be
appreciated by those of ordinary skill within the art. Thus, the
notification platform architecture can utilize an underlying
infrastructure as a manner by which sources send notifications,
alerts and events, as a manner by which sinks receive
notifications, alerts and events, etc. The invention is not so
limited, however.
[0061] In the following sections of the detailed description, the
user mechanism 202, the notification sources 206, and the
notification sinks 208 are each described in more detail, according
to varying embodiments of the invention. Thereafter, a method of
the manner by which the architecture operates according to an
embodiment of the invention is presented.
User Mechanism
[0062] In this section of the detailed description, the user
mechanism of the notification architecture described in the
previous section of the detailed description is described in more
detail, in conjunction with FIG. 3, which is a diagram 300 showing
the user mechanism 202 of FIG. 2 in more detail. The user mechanism
202 as shown in FIG. 3 includes a user notification preferences
store 302, a user context module 304 that includes a user context
profile store 305, and a whiteboard 307. The user mechanism 202 is
in one embodiment implemented as one or more computer programs
executable by a processor of a computer from a machine-readable
medium thereof, such as a memory.
[0063] The store 302 stores notification parameters for a user,
such as the default notification preferences for the user, as a
user profile, which can then be edited and modified by the user.
The store 302 can be considered as that which stores information on
parameters that influence how a user is to be notified. The user
context module 304 determines a user's current context, based on
the context information sources 306 as published to the whiteboard
307; the user context profile store 305 stores the context
parameters for a user, such as the default context settings for the
user, which can be edited and modified by the user. That is, the
user context module 304 provides a best guess about current context
information by accessing information from the store 305 and/or
updating the prior set of beliefs in the store 305 with live
sensing, via one or more context sources 306. The store 365 can be
considered as that which stores a priori where a user is, and what
the user is doing. The module 304 is in one embodiment implemented
as a computer program executable by a processor of a computer from
a machine-readable medium thereof, such as a memory.
[0064] The user context profile store 305 is a pre-assessed or
predefined user profile that captures such information as a
deterministic or probabilistic profile. The profile can be of
typical locations, activities, device availabilities, and costs and
values of different classes of notification as a function of such
observations as time of day, type of day, and user interactions
with one or more devices. The type of day can include weekdays,
weekends, holidays, etc. The user context module 304 can then
actively determine or infer key aspects of the context of the user,
such as the user's current or future location and attentional
state. Furthermore, the actual states of context can be accessed
directly from the sources 306 via the whiteboard 307, or, can be
inferred from a variety of such observations through inferential
methods such as Bayesian reasoning as known within the art.
[0065] The context information sources 306 provide information to
the module 304 via the whiteboard 307 regarding the user's
attentional state and location, from which the module 304 can make
a determination as to the user's current context (that is, the
user's current attentional state and location). Furthermore, the
invention is not limited to a particular number or type of context
sources 306, nor the type of information inferred or accessed by
the user context module. However, in one embodiment, the context
sources 306 include multiple desktop information and events, such
as mouse information, keyboard information, application information
(e.g., which application is currently receiving the focus of the
user), ambient sound and utterance information, text information in
the windows on the desktop, etc. The whiteboard 307 is in one
embodiment a common storage area, to which the context information
sources 306 can publish information, and from which multiple
components, including sources and the module 304 can access this
information; it is not necessary for implementation of the
invention, however. An event, also referred to as a notification or
alert, can in one embodiment generally include information about an
observation about one or more states of the world. Such states can
include the status of system components, the activity of a user, or
a measurement about the environment. Furthermore, events can be
generated by an active polling of a measuring device or source of
events, by the receipt of information that is sent on a change, or
per a constant or varying event heartbeat.
[0066] Other types of context sources 306 include
personal-information manager (PIM) information of the user, which
usually can provide scheduling information regarding the schedule
of the user, etc. The current time of day, as well as the user's
location--for example, determined by a global positioning system
(GPS), or a user's use of a cell phone, PDA, or a laptop that can
be locationally determined--are also types of context sources 306.
Furthermore, real-time mobile device usage is a type of context
source 306. For example, a mobile device such as a cell phone may
be able to determine if it is currently being used by the user, as
well as its orientation and tilt (indicating information regarding
its usage as well), and acceleration and speed (indicating
information as to whether the user is moving or not).
Notification Sources
[0067] In this section of the detailed description, the
notification sources 206 of the architecture 200 of FIG. 2 are
described in more detail. The notification sources generally
generate notifications that are conveyed to the notification
manager, which determines when notifications should occur, and, if
so, which of the notifications should be conveyed to which of the
notification sinks and in what order, as has also been already
described.
[0068] In one embodiment, each notification source has identified
with it one or more of the following parameters within a standard
description of key attributes and relationships, referred to herein
as a notification source schema or source schema. It is noted that
schema are provided for sources, for sinks, and for
context-information sources. Such schemas provide declarative
information about different component and provide a mechanism for
the sources, the notification manager, the sinks, and the user
mechanism (including the context mechanism described in the
previous section of the detailed description) to share semantic
information with one another. Thus, different schemas provide
information about the nature, urgency, and device signaling
modalities associated with notification. That is, schema can be
defined generally as a collection of classes and relationships
among classes that defines the structure of notifications and
events, containing information including event or notification
class, source, target, event or notification semantics, ontological
content information, observational reliability, and any
quality-of-service attributes.
[0069] The parameters for each notification source schema include
one or more of: message class; relevance; importance; time
criticality; novelty; content attributes; and fidelity tradeoffs,
and source information summary information. The message class for a
notification generated by a notification source indicates the type
of communication of the notification, such as e-mail, instant
message, numerical financial update, desktop service, etc. The
relevance for a notification generated by a notification sources
indicates a likelihood that the information contained within the
notification is relevant, for one or more specified contexts. In
one embodiment, the relevance is a logical flag, indicating whether
the source is relevant for a given context or not. The novelty of
the notification indicates the likelihood that the user already
knows the information contained within the notification. That is,
the novelty is whether the information is new to the user, over
time (indicating if the user knows the information now, and when,
if ever, the user will learn the information in the future without
being alerted to it).
[0070] Fidelity tradeoffs associated with the notification indicate
the loss of value of the information within the notification that
can result from different forms of specified allowed truncation,
summarization, etc. Such truncation and/or summarization may be
required for the notification to be conveyed to certain types of
notification sinks that may have bandwidth or other limitations
preventing them from receiving the full notification as originally
generated. Fidelity in general refers to the nature and/or degree
of completeness of the original content associated with a
notification. For example, a long e-mail message may be truncated,
or otherwise summarized to the maximum of 100 characters allowed by
a cell phone, incurring a loss of fidelity. Likewise, an original
message containing text and graphics content suffers a loss in
fidelity when transmitted via a device that only has text
capabilities. In addition, a device may only be able to show a
portion of the full resolution available from the source. Fidelity
tradeoffs refer to a set of fidelity preferences of a source stated
either in terms of orderings (e.g., rendering importance in order
of graphics first, then sound) and/or costs functions that indicate
how the total value of the content of the notification diminishes
with changes in fidelity. For example, a fidelity tradeoff might
describe how the full value associated with the transmission of a
complete e-mail message changes with increasingly greater amounts
of truncation. Content attributes contain a summary of the nature
of the content, representing such information as whether the core
message includes text, graphics, and audio components. The content
itself is the actual graphics, text, and/or audio that make up the
message content of the notification.
[0071] The importance of a notification refers to the value of the
information contained in the notification to the user, assuming the
information is relevant in the current context. In one embodiment,
it is expressed as a dollar value of the information's worth to the
user. Time criticality indicates the time-dependent change in the
value of the information contained in the notification--that is,
how the value of the information changes over time. In most but not
all cases, the value of the information of a notification decays
with time. This is particularly shown in the diagram 400 of FIG. 4.
The graph 402 shows the utility of a notification mapped over time.
At the point 404 within the graph, representing the initial time,
the importance of the notification is indicated, while the curve
406 indicates the decay of the utility over time.
[0072] Default attributes and schema templates for different
notification sources or source types may be made available in
notification source profiles stored in the user notification
preferences store, such as the store 302 of FIG. 3 as described in
the previous section. Such default templates can be directed to
overrule values provided by notification sources or to provide
attributes when they are missing from schema provided by sources.
Source summary information allows a source to post general
summaries of the status of information and potential notifications
available from a source. For example, source summary information
from a messaging source might include information about the total
number of unread messages that are at least some priority, the
status of attempts by people to communicate with a user, etc.
Notification Sinks
[0073] In this section of the detailed description, the
notification sinks 208 of the architecture 200 of FIG. 2 are
described in more detail. The notification sinks are devices, etc.,
by which the user can be notified of information contained in
notifications. The choice as to which sink or sinks are to be used
to convey a particular notification is determined by the
notification manager.
[0074] In one embodiment, each notification sink has identified
with it one or more of the following parameters within a schema:
device class; modes of signaling (alerting); and, for each mode,
fidelity/rendering capabilities, transmission reliability, actual
cost of communication, and attentional cost of disruption. For
devices that allow for the parameterized control of alerting
attributes, the schema for the devices can additionally include a
description of the alerting attributes and parameters for
controlling the attributes, and functions by which other attributes
(e.g., transmission reliability, cost of distribution, etc.) change
with the different settings of the alerting attributes. The schema
for notification sinks provides for the manner by which the
notification devices communicate semantic information about their
nature and capabilities with the notification manager and other
components of the system. Default attributes and schema templates
for different device types can be made available in device profiles
stored in the user notification preferences store, such as the
store 302 of FIG. 3 as described in the previous section. Such
default templates can be directed to overrule values provided by
devices or to provide attributes when they are missing from schema
provided by devices.
[0075] Each of the schema parameters is now described in term. The
class of the device refers to the type of the device: a cell phone,
a desktop computer, a laptop computer, etc. The class can also be
more general, such as a mobile device, a stationery device, etc.
The modes of signaling refer to the different ways in which a given
device can alert the user about a notification. Devices may have
one or more notification modes. For example, a cell phone can only
vibrate, only ring with some volume, or it can both vibrate and
ring. Furthermore, a desktop display for an alerting system can in
one embodiment be decomposed into several discrete modes (e.g., a
small notification window in the upper right hand of the display
vs. a small thumbnail at the top of the screen--with or without an
audio herald), as described in the cofiled, copending and
coassigned application entitled "Display and Human-Computer
Interaction for a Notification Platform." [attorney docket no.
1018.101US2] Beyond being limited to a set of predefined behaviors,
a device can allow for modes with alerting attributes that are
functions of parameters, as part of its definition. Such continuous
alerting parameters for a mode represent such controls as the
volume at which an alert is played at the desktop, rings on a cell
phone, the size of an alerting window, etc.
[0076] The transmission reliability for a mode of a notification
sink indicates the likelihood that the user will receive the
communicated alert about a notification, which is conveyed to the
user via the sink with that mode. As transmission reliability may
be dependent on the device availability and context of the user,
the transmission reliability of different modes of a device can be
conditioned on such contextual attributes as the location and
attention of a user. Transmission reliability for each of one or
more unique contextual states, defined by the cross product of such
attributes as unique locations and unique attentional states,
defined as disjunctions created as abstractions of such attributes
(e.g., for any location away from the home, and any time period
after 8 am and before noon), can also be specified. For example,
depending on where the user currently is, information transmitted
to a cell phone may not always reach the user, particularly if the
user is in a region with intermittent coverage, or where the user
would not tend to have a cell phone in this location (e.g., family
holiday). Contexts can also influence transmission reliability
because of the ambient noise or other masking or distracting
properties of the context.
[0077] The actual cost of communication indicates the actual cost
of communicating the information to the user when contained within
a notification that is conveyed to the sink. For example, this cost
can include the fees associated with a cell phone transmission. The
cost of disruption includes the attentional costs associated with
the disruption associated with the alert employed by the particular
mode of a device, in a particular context. Attentional costs are
typically sensitive to the specific focus of attention of the user.
The fidelity/rendering capability is a description of the text,
graphics, and audio/tactile capabilities of a device, also given a
mode. For example, a cell phone's text limit may be 100 characters
for any single message, and the phone may have no graphics
abilities.
Methods
[0078] In this section of the detailed description, methods
according to varying embodiments of the invention are shown. The
methods can in some embodiments be computer-implemented. A
computer-implemented method is desirably realized at least in part
as one or more programs running on a computer--that is, as a
program executed from a computer-readable medium such as a memory
by a processor of a computer. The programs are desirably storable
on a machine-readable medium such as a floppy disk or a CD-ROM, for
distribution and installation and execution on another computer.
The program or programs can be a part of a computer system or a
computer, such as that described in conjunction with FIG. 1 in a
previous section of the detailed description. The invention is not
so limited, however.
[0079] Referring to FIG. 5, a flowchart of a method 500 is shown.
In one embodiment, the method 500 can be executed by the
notification architecture 200 of FIG. 2, which has been already
described. In 502, one or more notification sources generate
notifications, which are received by a notification manager. In
504, the user mechanism generates context information regarding the
user, which in 506 is received by the notification manager. That
is, in one embodiment, in 504, the user mechanism accesses a user
contextual information profile that indicates the user's current
attentional status and location, and/or assesses real-time
information regarding the user's current attentional status and
location from one or more contextual information sources, as has
been described in the previous sections of the detailed
description.
[0080] In 508, the notification manager determines which of the
notifications to convey to which of the notification sinks, based
in part on the context information received from the user
mechanism. The notification also makes it determination based on
information regarding notification parameters of the user as stored
by the user mechanism, in one embodiment. That is, in one
embodiment, in 508, the manager performs a decision-theoretic
analysis as to whether a user should be alerted for a given
notification, and how the user should be notified. Notification
parameters regarding the user can be utilized to personalize the
analysis by filling in missing values or by overwriting parameters
provided in the schema of sources or sinks. Notification
preferences can also provide policies that are employed in lieu of
the decision-theoretic analysis, as has been described in the
previous sections of the detailed description. Based on this
determination, the notification manager conveys the notifications
to the sinks in 510.
Application of the Invention to Entities Other than Users
[0081] Embodiments of the invention have been described herein thus
far as applicable to users. However, the invention itself is not so
limited. That is, the invention is applicable to any type of
entity, including users. Other types of entities include agents,
processes, computer programs, threads, services, servers,
computers, machines, companies, organizations, businesses, etc. The
agent, for example, may be a software agent, which can be generally
defined as a computer program that performs a background task for a
user and reports to the user when the task is done or some expected
event has taken place. Still other types of entities are
encompassed under the invention, as can be appreciated by those of
ordinary skill within the art.
[0082] Thus, where embodiments of the invention have been
particularly described in relation to a user, the invention itself
is applicable to any type of entity. For example, the user
mechanism of a system according to an embodiment of the invention
can be generalized as a mechanism, applicable to any type of
entity. As another example, notification sinks can generate
notifications, alerts and events regarding and for entities other
than users. Similarly, notification sinks can receive
notifications, alerts and events regarding and for entities other
than users.
CONCLUSION
[0083] It is noted that, although specific embodiments have been
illustrated and described herein, it will be appreciated by those
of ordinary skill in the art that any arrangement that is
calculated to achieve the same purpose may be substituted for the
specific embodiments shown. This application is intended to cover
any adaptations or variations of the present invention. Therefore,
it is manifestly intended that this invention be limited only by
the claims and equivalents thereof.
* * * * *