U.S. patent application number 11/539125 was filed with the patent office on 2007-11-29 for publication of customized presence information.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Ankur Chavda, Sira P. Rao, Setty Venkateshaiah.
Application Number | 20070276909 11/539125 |
Document ID | / |
Family ID | 38723603 |
Filed Date | 2007-11-29 |
United States Patent
Application |
20070276909 |
Kind Code |
A1 |
Chavda; Ankur ; et
al. |
November 29, 2007 |
PUBLICATION OF CUSTOMIZED PRESENCE INFORMATION
Abstract
A presence aggregation system provides a presence aggregation
server that allows for the defining and inclusion of custom
presence states that are distinct from a set of default presence
states that are provided by the presence aggregation system. When
one or more custom presence states are defined and included in the
presence aggregation system, a publisher at an endpoint is able to
publish any of the defined custom presence states or default
presence states as an indication of the publisher's presence. When
a publication is made, the presence aggregation server may generate
an aggregated availability of the publisher across all of the
publisher's endpoints, and publish the aggregated availability to
each of the publisher's endpoints. The presence aggregation server
may also provide the publisher's aggregated availability to the
subscribers of the publisher's availability information.
Inventors: |
Chavda; Ankur; (Seattle,
WA) ; Venkateshaiah; Setty; (Bellevue, WA) ;
Rao; Sira P.; (Bellevue, WA) |
Correspondence
Address: |
PERKINS COIE LLP/MSFT
P. O. BOX 1247
SEATTLE
WA
98111-1247
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
38723603 |
Appl. No.: |
11/539125 |
Filed: |
October 5, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11419947 |
May 23, 2006 |
|
|
|
11539125 |
|
|
|
|
Current U.S.
Class: |
709/204 |
Current CPC
Class: |
H04L 51/043 20130101;
H04L 67/24 20130101; G06Q 10/10 20130101; H04L 67/22 20130101; H04L
29/08684 20130101 |
Class at
Publication: |
709/204 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A computer-implemented method for publishing custom presence
states, the method comprising: providing a set of default presence
states for publication, wherein each of the default presence states
indicates a presence; receiving a publication of a custom presence
state for a publisher, wherein the custom presence state indicates
a presence for the publisher; and wherein the custom presence state
is not one of the default presence states provided in the set of
default presence states; and publishing the custom presence state
to at least one subscriber.
2. The method of claim 1, wherein the custom presence state is
received as a user state publication.
3. The method of claim 1, wherein the custom presence state is
received as a generic state publication.
4. The method of claim 1, wherein the publisher is a human
user.
5. The method of claim 1, wherein the publisher is an
application.
6. The method of claim 1, wherein the custom presence state is
published to at least one subscriber upon determining that the
custom presence state is the publisher's aggregated
availability.
7. The method of claim 1, wherein the custom presence state is
published to at least one subscriber upon determining that the
custom presence state is the publisher's current activity.
8. The method of claim 1, wherein the custom presence state
comprises at least one localized custom string and a corresponding
locale identifier that identifies a locale.
9. The method of claim 8 further comprising, upon determining that
an endpoint of the subscriber to which the custom presence state is
published supports the locale identified by the locale identifier,
displaying the localized custom string corresponding to the locale
identifier on the subscriber endpoint.
10. A system for publishing custom presence states, the system
comprising: a component that receives from an endpoint a custom
presence state publication for a publisher, the custom presence
state publication comprising at least one localized custom string
and a corresponding locale identifier that identifies a locale; and
a component that publishes the custom presence state of the
publisher.
11. The system of claim 10, wherein the custom presence state is
indicated on the endpoint via a user interface displayed on the
endpoint.
12. The system of claim 10, wherein the custom presence state is
indicated on the endpoint via an API of an application executing on
the endpoint.
13. The system of claim 10, wherein the component publishes the
custom presence state of the publisher by sending an indication of
the custom presence state to at least one endpoint of a subscriber
of the publisher's presence information.
14. The system of claim 13 further comprising a component on the
subscriber's endpoint that, upon a determination that the
subscriber endpoint supports the locale identified by the locale
identifier, displays the localized custom string corresponding to
the supported locale identifier on the subscriber endpoint.
15. The system of claim 10, wherein the component publishes the
custom presence state of the publisher upon a determination that
the custom presence state indicates an aggregated availability of
the publisher.
16. The system of claim 10, wherein the component publishes the
custom presence state of the publisher upon a determination that
the custom presence state indicates a current activity of the
publisher.
17. A computer-readable media encoded with computer executable
instructions for publishing custom presence states, by a method
comprising: receiving at least one definition specifying a custom
presence state, the definition comprising at least one localized
custom string and a corresponding locale identifier for the custom
presence state, such that any one of the defined custom presence
states may be published by a publisher as an indication of
presence.
18. The computer-readable media of claim 17, wherein the definition
of the custom presence state is specified by a human user.
19. The computer-readable media of claim 17, wherein the definition
of the custom presence state is specified by an application
program.
20. The computer-readable media of claim 17 including: receiving a
publication of the defined custom presence state for a publisher;
and publishing the custom presence state to at least one
subscriber.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a Continuation-In-Part (CIP) of U.S.
patent application Ser. No. 11/419,947, entitled "User Presence
Aggregation at a Server," which was filed on May 23, 2006, and
identified by attorney docket number 418268300US2, which is related
to U.S. patent application Ser. No. 11/392,472, entitled
"Aggregating User Presence Across Multiple Endpoints," which was
filed on Mar. 28, 2006, and identified by attorney docket number
418268300US, and U.S. patent application Ser. No. 11/392,991,
entitled "User Interface For User Presence Aggregated Across
Multiple Endpoints," which was filed on Mar. 28, 2006, and
identified by attorney docket number 418268300US1, the disclosures
of which are incorporated by reference herein in their
entireties.
BACKGROUND
[0002] Users of computing devices (e.g., laptops, cellular phones,
and personal digital assistants) often need to communicate in real
time. A common form of real-time communications is provided by
instant messaging services. An instant messaging service allows
participants at endpoints to send messages and have them received
within a second or two by the other participants in a conversation.
The receiving participants can then send responsive messages to the
other participants in a similar manner. To be effective, a
real-time conversation relies on the participants' becoming aware
of, reviewing, and responding to received messages very quickly.
This quick response is in contrast to conventional electronic mail
systems in which the recipients of electronic mail messages respond
to messages at their convenience.
[0003] When an initiating participant wants to start a real-time
conversation, that participant needs to know whether the intended
participants are available to respond in real time to a message. If
not, then communications via conventional electronic mail, voice
mail, or some other mechanism may be more appropriate. For example,
if the computers of the intended participants are currently powered
off, then a real-time conversation may not be possible. Moreover,
if their computers are currently powered on, but the intended
participants are away from their computers, a real-time
conversation is also not possible. The initiating participant would
like to know the availability of the intended participants so that
an appropriate decision on the form of communication can be
made.
[0004] Presence servers are increasingly being used to provide this
availability information. The availability status of an entity such
as a computer system or a user associated with that computer system
is referred to as "presence information." Presence information
identifies the current "presence state" of the user. Users make
their presence information available to a presence server so that
other users can decide how best to communicate with them. For
example, the presence information may indicate whether a user is
logged on ("online") with an instant messaging server or is logged
off ("offline"). Presence information may also provide more
detailed information about the availability of the user. For
example, even though a user is online, that user may be away from
their computer in a meeting. In such a case, the presence state may
indicate "online" and "in a meeting."
[0005] In an instant messaging context, a publishing user
("publisher") may provide their presence information to a presence
server that then provides the presence information to subscribing
users ("subscribers"). Thus, a presence server may use a
subscriber/publisher model to provide the presence information for
the users of the presence service. Whenever the presence
information of a user changes, the presence server is notified of
the change by that user's computer system and in turn notifies the
subscribing users of the change. A subscribing user can then decide
whether to initiate an instant messaging conversation based on the
presence information of the intended participants. For example, if
the presence information indicates that a publishing user is
currently in a conference telephone call, then the subscribing user
may decide to send an instant message, rather than place a
telephone call, to the publishing user. If the subscribing user,
however, needs to call and speak with the publishing user, the
subscribing user needs to monitor the presence information of the
publishing user to know when the call can be placed. When the
subscribing user notices that the publishing user's presence
information indicates that the telephone conference has been
concluded, the subscribing user can then place the telephone call.
RFC 2778 is a specification relating to presence information in
instant messaging systems. RFC 3856 is a specification relating to
presence information using the Session Initiation Protocol
("SIP").
[0006] Although the usefulness of the published presence
information depends on the types of presence states a publisher can
publish, current presence systems restrict the publisher to a
limited number of presence states. For example, current presence
systems typically support the publication of a limited number of
presence states which are typically hard-coded into the presence
systems during the development of the presence systems.
Unfortunately, the limited number of presence states typically
supported by current presence systems do not allow a publisher to
meaningfully describe his or her presence state in many
instances.
SUMMARY
[0007] A method and system for publishing custom presence states by
publishers is provided. A presence aggregation system provides a
presence aggregation server that allows for the defining and
inclusion of custom presence states that are distinct from a set of
default presence states that are provided by the presence
aggregation system. When one or more custom presence states are
defined and included in the presence aggregation system, a
publisher at an endpoint is able to publish any of the defined
custom presence states or default presence states as an indication
of the publisher's presence. When a publication is made, the
presence aggregation server may generate an aggregated availability
of the publisher across all of the publisher's endpoints, and
publish the aggregated availability to each of the publisher's
endpoints. The presence aggregation server may also provide the
publisher's aggregated availability to the subscribers of the
publisher's availability information.
[0008] This Summary is 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
[0009] FIG. 1 is a block diagram that illustrates components of a
presence aggregation system, according to some embodiments.
[0010] FIG. 2 is a data structure diagram that illustrates example
logical data structures of the presence aggregation system,
according to some embodiments.
[0011] FIG. 3 is a flow diagram that illustrates the processing of
the presence aggregation system, according to some embodiments.
[0012] FIG. 4 is a flow diagram that illustrates the processing of
the aggregation module in determining an aggregated machine state,
according to some embodiments.
[0013] FIG. 5 is a flow diagram that illustrates the processing of
the aggregation module in determining an aggregated availability,
according to some embodiments.
[0014] FIG. 6 is a flow diagram that illustrates the processing of
the aggregation module in determining a current activity, according
to some embodiments.
[0015] FIG. 7 is a block diagram that illustrates the publication
of a custom state, according to some embodiments.
[0016] FIG. 8 is a block diagram that illustrates the publication
of a custom state, according to some other embodiments.
[0017] FIG. 9 is a display diagram showing a sample user interface
displaying a drop-down menu containing a list of selectable custom
presence states, according to some embodiments.
[0018] FIG. 10 is a display diagram showing a sample pop-up window
containing a list of selectable custom activities, according to
some embodiments.
[0019] FIG. 11 is an example data listing that illustrates multiple
custom state definitions, according to some embodiments.
[0020] FIG. 12 is a flow diagram that illustrates the processing of
an endpoint in displaying a view of a current activity, according
to some embodiments.
DETAILED DESCRIPTION
[0021] A method and system for aggregating user presence across
multiple endpoints at a server is provided. In some embodiments, a
presence aggregation system provides a presence aggregation server
that allows for the publication of presence states of a publisher
from any of the publisher's multiple endpoints. A presence state
includes an availability value and an activity. An activity may
specify an activity token and/or a custom string. For example, a
user may publish a state that includes an availability value that
indicates that the user (e.g., publisher) is online. As another
example, a machine may specify that it is active by publishing a
state that includes availability value that indicates that the
machine is online. When any one of the publisher's endpoints
publishes a presence state on the presence aggregation server, the
presence aggregation server generates an aggregated presence state
(also interchangeably referred to herein as an "aggregated state")
of the publisher (i.e., the availability of the publisher
aggregated across all of the publisher's endpoints) and publishes
the generated aggregated state to each of the publisher's
endpoints. The presence aggregation server may also provide the
publisher's aggregated state to the subscribers of the publisher's
aggregated state information. In some embodiments, the presence
aggregation server may generate an aggregated state of a publisher
when a presence state publication for the publisher expires. For
example, a presence state publication may expire when an endpoint
becomes offline. In some embodiments, the presence aggregation
server may generate an aggregated state of a publisher based on
specified triggers. For example, an endpoint may publish a presence
state that indicates that the publisher is going to be busy at 2:00
P.M. In this instance, the presence aggregation server may generate
an aggregated state for the publisher at the indicated time.
[0022] The presence state publication focuses on the publisher. By
focusing on the publisher, the presence aggregation system provides
a "person-centric" presence model in that the publisher is able to
specify his or her presence for the desired modes of communication.
The person-centric presence model simplifies the communication
process by allowing a person to think in terms of "I want to talk
to this person" instead of "I need to call the person's cell
phone." For example, the publisher is able to indicate that
communication by phone or an in-person meeting at the publisher's
office is more convenient for the publisher than sending an instant
message. A subscriber receiving the aggregated state of a publisher
is able to use this information to make decisions on how to best
communicate with the publisher. If the aggregated state of the
publisher indicates that the publisher is currently away, the
subscriber can send an instant message but will not be upset if a
reply is not received. In this manner, the presence aggregation
system allows a publisher to more accurately indicate their
availability to communicate across all the publisher's endpoints,
and the subscribers of the publisher's aggregated state to obtain a
better indication of the availability and willingness of the
publisher to communicate.
[0023] Throughout the description, the following terms will
generally have the following meanings:
[0024] The term "activity" refers to a descriptor for what a user
is doing at a moment in time. For example, a calendaring
application can publish calendar type states that contain
in-a-meeting event information.
[0025] The term "aggregated availability" refers to the
availability associated with a user (e.g., publisher) across all of
the user's endpoints.
[0026] The term "aggregated presence" refers to a combined presence
of a user across all of the user's endpoints. Aggregated presence
can include information beyond aggregated presence states. For
example, aggregated presence can also include a machine's idle
time, indication of location, etc.
[0027] The term "availability" refers to a user's willingness and
ability to communicate. As such, a person's availability is a
representation of how "available" the person is and/or whether the
person can be interrupted. Availability is designated by a
numerical value. The higher the number, the less
reachable/available the person.
[0028] The term "callee" or "publisher" refers to a user that is
the target of the presence-based communication (e.g., real-time
communication). The callee or publisher is the person that
publishes the presence information.
[0029] The term "caller" or "subscriber" refers to the user that is
viewing the published aggregated availability information. The
caller or subscriber is the user that initiates the presence-based
communication to the publisher or callee.
[0030] The term "endpoint" refers to a single logon session of the
user. Endpoints are typically synonymous with devices.
[0031] The term "presence" refers to information that is useful for
determining a user's availability.
[0032] The term "state" refers to blocks of information that
represent factors that influence a person's willingness and
availability to communicate.
[0033] In some embodiments, the presence aggregation server
provides containers for publishing presence information. The
presence aggregation server provides each publisher a "status"
container, and only the publisher has permissions to view the
contents of his or her status container. Each status container
contains a collection of zero, one or more presence state
publications for its respective publisher. The presence aggregation
server monitors the status containers for a change in the state of
a publisher (e.g., a presence state publication that changes the
publisher's state). Upon detecting a change in the publisher's
state, the presence aggregation server generates an aggregated
state (i.e., an aggregated availability and/or a current activity)
of the publisher and publishes an indication of the aggregated
state in the publisher's status container, thus notifying each of
the publisher's endpoints of the published aggregated state. The
presence aggregation server may also determine the publisher's
computing device (also referred to herein as a "machine") that is
the most active, and publish this information to the publisher's
status container, thus notifying each of the publisher's endpoints
of the publisher's most active machine. Each of the publisher's
endpoints can then use this information to, by way of example,
determine whether or not to "auto-accept" a request to communicate.
The publisher's computing device is a device used by the publisher
to create an endpoint.
[0034] The presence aggregation server allows each publisher to
define a collection of one or more containers, to specify an access
control list (ACL) for each container, and to specify the
publications that are to be included in each container. The ACL
specifies the entities, also referred to as "members," who are
allowed to subscribe to receive the publications made to each
container. For example, the publisher may specify members of a
container by specifying membership types of individual entities
(e.g., Joe Smith), a group of entities (e.g., Project A Marketing
Team), entities with a common characteristic (e.g., within domain
acme.com), and so on. The presence aggregation server allows
entities to subscribe to receive a publisher's publications,
including the subscriber's aggregated state and other published
presence information. If the subscribing entity is a member of a
container as determined by the container's ACL, then the presence
aggregation server adds that entity as a subscriber of that
container. The presence aggregation server then notifies the
subscribers of the container of the publications made to that
container. The publication may be the publisher's aggregated state
as well as other presence information. For example, when the
presence aggregation server generates an aggregated state of the
publisher, the presence aggregation server can publish an
indication of the aggregated state in each of the publisher's
containers, thus notifying the subscribers of the publisher's
aggregated state. The presence aggregation server may allow a
publisher to publish presence information directly to the
publisher's containers. For example, a publisher may define a
container that is to be made available to subscribers who are
coworkers and may define another container that is to be made
available to all other subscribers. In this example, the publisher
may want to publish more detailed presence information in the
container that is available to coworkers. For example, in addition
to the aggregated state, a publisher may also want to inform the
coworkers that the publisher is "in a meeting with John," while not
providing this additional piece of information to the others.
[0035] In some embodiments, a presence state publication may be of
a type "user," "machine," "phone," "calendar," "conference," or
"generic," as shown in Table 1 below.
TABLE-US-00001 TABLE 1 State Type Description User A preset state a
publisher can manually set Machine A state of the endpoint machine
(endpoint device) Phone The state of a publisher's phone Calendar
Events in a publisher's schedule (e.g., Outlook schedule)
Conference Triggered when a publisher is in a multiparty
conversation or if the publisher is presenting in a collaborative
session Generic All other states
[0036] A user state is manually provided or specified by a
publisher and, as such, provides an indication of the publisher's
intent. For example, the presence aggregation system's client
application executing on the publisher's machine, and which the
publisher may have used to create an endpoint, may provide a user
interface through which the publisher can access a list of user
states, such as those listed in Table 2 below.
TABLE-US-00002 TABLE 2 User State Availability Value Description
Online 3500 Publisher is reachable Busy 6500 Publisher is busy Do
Not Disturb 9500 Publisher should not be interrupted Be Right Back
12500 Publisher is not currently reachable Away 15500 Publisher is
not at their desk Appear Offline 18500 Publisher wants to be
offline
[0037] As shown by the example user states in Table 2, a publisher
may indicate his or her intent to communicate as "Online," "Busy,"
"Do Not Disturb," "Be Right Back," "Away," and "Appear Offline."
Each user state has a corresponding availability value that is a
number that represents the availability of the subscriber as
indicated by the user state from more available to less available,
where the larger availability value corresponds to the less
available state. For example, from amongst the six user states
listed in Table 2, "Online" is the most available user state and
"Appear Offline" is the least available user state. The publisher
can specify a user state by selecting one of the user states from
the displayed list. When a publisher selects one of the user states
from the displayed list, the client application determines the
availability value that corresponds to the specified user state,
and publishes the availability value as the publisher's user state
in the publisher's status container on the presence aggregation
server. For example, if the publisher manually specifies a user
state of "Online," the specified user state will be published in
the publisher's status container as a user state availability value
of 3500 (e.g., user state; avail=3500). When a user state is
published, the presence aggregation server stamps the publication
with a publication time.
[0038] A machine state provides an indication of whether the
publisher is reachable on the machine. In some embodiments, each
endpoint publishes a machine state. For example, the client
application may monitor the publisher's machine for events such as
keyboard activity or inactivity, mouse or pointing device activity
or inactivity, activation of screen saver or machine lock, and
other events that provide an indication of the use of the machine.
When such an event is detected, the client application determines
the availability value that corresponds to the machine state, and
publishes the availability value as the publisher's machine state
in the publisher's status container on the presence aggregation
server. A list of example machine states and corresponding
availability values and optional activity tokens is provided in
Table 3 below.
TABLE-US-00003 TABLE 3 Machine Availability Activity State Value
Token Description Active 3500 NULL Publisher is actively using the
device and is reachable Inactive 3750 Inactive Publisher has not
used the device but is still likely to be reachable Unknown 3750
Inactive The device cannot determine if the publisher is reachable
Away 15500 NULL Publisher is probably not at the device and is not
reachable Off 18500 NULL Publisher is not logged on and definitely
not reachable
[0039] As shown in Table 3, an endpoint may indicate the machine
state as "Active," "Inactive," "Unknown," "Away," and "Off."
Similar to the user states listed in Table 2, the machine states
listed in Table 3 are ranked according to their indication of
availability from more available to less available, where the
larger availability value corresponds to the less available state.
Moreover, from Tables 2 and 3, it can be seen that the machine
state of "Away" indicates a less available state that a user state
of "Do Not Disturb." For example, the client application can
determine that it is being currently used and, from this, determine
a machine state of "Active." In this example, the client
application can publish a machine state in the publisher's status
container on the presence aggregation server as a machine state
availability value of 3500 (e.g., machine state; avail=3500;
activity token=NULL). The activity token, when present, is a text
string that represents the particular machine state. The activity
token is typically provided by the publisher (e.g., the client
application that published the machine state). In another example,
the client application can monitor hardware activity to determine a
machine state. When a machine state is published, the presence
aggregation server stamps the publication with a publication
time.
[0040] A phone state indicates the state of a publisher's phone.
For example, the client application may detect that the publisher
is currently engaged in a voice over Internet (VoIP) call and
publish a phone state. A list of example phone state availability
values and corresponding optional activity tokens and custom
strings is provided in Table 4 below.
TABLE-US-00004 TABLE 4 Availability Activity Value Token Custom
String Description 6500 In a call In a 1 on 1 User is speaking with
one conversation person 6750 In a In a multiparty User is speaking
with more conference conversation than one person
[0041] Similar to the user states listed in Table 2 and the machine
states listed in Table 3, the phone states listed in Table 4 are
ranked according to their indication of availability from more
available to less available, where the larger availability value
corresponds to the less available state. The activity token, when
present, is a text string that represents the particular phone
state. The custom string, when present, is a text string that
further describes the particular phone state. For example, the
custom string may describe the phone state in a specific language,
such as Japanese. A client application may include both an activity
token and a custom string to allow older clients (e.g., older
versions of the client application) that do not support
translations of the token to display a detailed text description of
the presence state. The activity token and the custom string are
typically provided by the publisher (e.g., the client application
that published the phone state). For example, the client
application can determine that the publisher is currently
conducting a one-on-one conversation. In this example, the client
application can publish a phone state in the publisher's status
container on the presence aggregation server as a phone state
availability value of 6500 (e.g., phone state; avail=6500; activity
token="In a call"; custom string="In a 1 on 1 conversation"). When
a phone state is published, the presence aggregation server stamps
the publication with a publication time.
[0042] A calendar state indicates the state of a publisher's
calendar. For example, the client application can interact with a
calendaring application to determine that the publisher is free, in
a meeting, out of the office, etc., and publish this information as
a calendar state. A list of example calendar state availability
values and corresponding optional activity tokens and custom
strings is provided in Table 5 below.
TABLE-US-00005 TABLE 5 Availability Activity Custom Value Token
String Description 3500 NULL Free Publisher has no meeting 3500
NULL Tentative Publisher has a meeting they have not accepted 6500
In a meeting In a Publisher has accepted a meeting meeting 3500 Out
of Office Out of the Publisher is not in the office Office
[0043] Similar to the user states listed in Table 2, the machine
states listed in Table 3, and the phone states listed in Table 4,
the calendar states in Table 5 are ranked according to their
indication of availability from more available to less available,
where the larger availability value corresponds to the less
available state. The activity token, when present, is a text string
that represents the particular calendar state. The custom string,
when present, is a text string that further describes the
particular calendar state. For example, the custom string may
provide additional details regarding the particular calendar state
that is not provided by the activity token. The activity token and
the custom string are typically provided by the publisher (e.g.,
the client application that published the calendar state). For
example, the client application can determine that the publisher
has no meetings. In this example, the client application can
publish a calendar state in the publisher's status container on the
presence aggregation server as a calendar state availability value
of 3500 (e.g., calendar state; avail=3500; activity token="NULL";
custom string="Free"). When a calendar state is published, the
presence aggregation server stamps the publication with a
publication time.
[0044] A conference state indicates the state of a publisher's
conferencing activities. For example, the client application may
detect that the publisher is currently participating in a
conference and publish a conference state. A list of example
conference state availability values and corresponding optional
activity tokens and custom strings is provided in Table 6
below.
TABLE-US-00006 TABLE 6 Availability Activity Custom Value Token
String Description 9500 NULL Presenting Participant in full screen
mode 6900 Urgent- Urgent Publisher is presenting (Do-
Interruptions- interruptions Not-Disturb) but certain Only only
subscribers should see a "Busy" availability 6750 In a multiparty
In ae Publisher is speaking with conference conferenc more than one
person in the same conversation in a mode other than Instant
Messaging
[0045] Similar to the user states listed in Table 2, the machine
states listed in Table 3, the phone states listed in Table 4, and
the calendar states listed in Table 5, the conference states listed
in Table 6 are ranked according to their indication of availability
from more available to less available, where the larger
availability value corresponds to the less available state. The
activity token, when present, is a text string that represents the
particular conference state. The custom string, when present, is a
text string that further describes the particular conference state.
For example, the custom string may describe the conference state in
a specific language, such as Japanese, or provide additional
details regarding the particular conference state that is not
provided by the activity token. The activity token and the custom
string are typically provided by the publisher (e.g., the client
application that published the conference state). By way of
example, the client application may detect that a conferencing
application, such as MICROSOFT's POWERPOINT, executing on the
publisher's machine is in "full screen" mode. From this, the client
application may determine that the publisher is currently
presenting in a conference. In this example, the client application
can publish a conference state in the publisher's status container
on the presence aggregation server as a conference state
availability value of 9500 (e.g., conference state; avail=9500;
activity token="NULL"; custom string="Presenting"). When a
conference state is published, the presence aggregation server
stamps the publication with a publication time.
[0046] Generic states include the events that are not published as
either a user state, a device state, a phone state, a calendar
state, or a conference state. For example, the client application
executing on the user's machine may detect an event that is not a
user state, a device state, a phone state, a calendar state, or a
conference state. In this instance, the client application can
publish the event as a generic state in the publisher's status
container on the presence aggregation server. In addition to
indicating that the publication is a generic state publication and
providing an availability value, the client application may also
provide an activity token and/or a custom string that represents
and/or additionally describes the published generic state. When a
generic state is published, the presence aggregation server stamps
the publication with a publication time.
[0047] In some embodiments, the client application may provide an
application program interface (API) which allows events detected by
other applications to be published. For example, applications such
as a calendaring application, a phone application (e.g., VoIP
application), another conferencing application, etc., can detect
events and request that the client application publish the detected
events in the publisher's status container on the presence
aggregation server.
[0048] In some embodiments, a third-party application or device may
directly publish events in the publisher's status container on the
presence aggregation server. For example, a private branch exchange
(PBX) device may be knowledgeable of the presence aggregation
server and may have the necessary privileges (e.g., credentials) to
publish presence information for a publisher in the publisher's
status container on the presence aggregation server. When the PBX
device detects an event, such as the publisher being currently
engaged in a telephone call, the PBX device can publish the
detected event by determining an appropriate availability value
that represents the event. The PBX device can then publish the
availability value as a generic state in the publisher's status
container on the presence aggregation server. The PBX device may
also provide an activity token and/or a custom string that
represents and/or additionally describes the published generic
state.
[0049] In some embodiments, the presence aggregation server
determines an aggregated availability of a publisher by considering
the publisher's presence state publications across all of the
publisher's endpoints, and publishes the determined aggregated
availability. The presence aggregation server monitors the status
containers for changes to the publishers' state. Upon detecting a
change to a publisher's state (e.g., a presence state publication
to the publisher's status container), the presence aggregation
server generates an aggregated availability for the publisher as
the least available state across all of the publisher's endpoints.
The presence aggregation server identifies the most available
machine state from the published machine states, and only uses the
most available machine state to perform the aggregation. To
determine the publisher's aggregated availability, the presence
aggregation server checks the publisher's status container for a
publication of a user state. In the case where there is a user
state publication, the presence aggregation server extracts the
publication time of the user state publication, and sorts the other
presence state publications (the identified most available machine
state publication, phone state publications, calendar state
publications, conference state publications, and generic state
publications) in the status container by publication time, and
eliminates the presence state publications that are older than the
user state publication. From the remaining presence state
publications, the presence aggregation server extracts the
availability value from the least available state, and assigns this
availability value as the publisher's aggregated availability. In
the case where a user state publication is not present in the
status container, the presence aggregation server extracts the
availability value from the least available state from amongst the
most available machine state publication, phone state publications,
calendar state publications, conference state publications, and
generic state publications, and assigns this availability value as
the publisher's aggregated availability. The presence aggregation
server then publishes the generated aggregated availability (e.g.,
a value representing the aggregated availability, an indication of
an icon representing the aggregated availability, a default string
representing the aggregated availability, etc.) in the publisher's
status container, which causes each of the publisher's endpoints to
be notified of the publisher's aggregated availability. The
aggregated availability can then be displayed at each endpoint. The
presence aggregation server may also publish the generated
aggregated availability in one or more of the publisher's other
containers. This causes the publisher's aggregated availability to
be sent to the subscribers who have subscribed to the containers,
thus notifying the subscribers of the publisher's aggregated
availability.
[0050] Table 7 below contains a mapping of availability values to
corresponding aggregated availabilities, default strings, and
descriptions.
TABLE-US-00007 TABLE 7 Aggregated Default Availability Availability
String Value Range Description Online Online 3000 3999 Publisher is
reachable Busy Busy 6000 6999 Publisher is reachable but is engaged
in another task Do Not Do Not Disturb 9000 9999 Publisher is
reachable but Disturb does not want to be interrupted Temporarily
Temporarily 12000 12999 Publisher is temporarily Away Away probably
not reachable Away Away 15000 15999 Publisher is probably not
reachable Offline Offline 18000 18999 Publisher is not
reachable
[0051] As shown in Table 7, a range of availability values maps to
each aggregated availability. For example, the availability values
in the range 3000-3999 map to the aggregated availability "Online."
Mapping a range of availability values to a single aggregated
availability allows for a ranking of availability values within a
class of availabilities. For example, the phone state "In a
multiparty conversation" in Table 4 above and the calendar state
"In a meeting" above in Table 5 above will both map to the same
aggregated availability "Busy." Even though both of these states
result in the same aggregated availability, the phone state "In a
multiparty conversation" is ranked lower (i.e., less available)
than the calendar state "In a meeting" because of its larger
availability number (6750>6500). As such, if the publisher's
aggregated availability is to be chosen from these two states, the
phone state "In a multiparty conversation" will be selected as the
publisher's aggregated availability.
[0052] In some embodiments, the presence aggregation server
determines a current activity that a publisher is engaged in and
publishes this information. The presence aggregation server may
publish a current activity as part of the aggregated state. To
determine the current activity for a publisher, the presence
aggregation server identifies the most available machine state from
the published machine states. The presence aggregation server then
checks the publisher's status container for a publication of a user
state. In the case where there is a user state publication, the
presence aggregation server extracts the publication time of the
user state publication, and sorts the other presence state
publications (the identified most available machine state
publication, phone state publications, calendar state publications,
conference state publications, and generic state publications) in
the status container by publication time, and eliminates the state
publications that are older than the user state publication. From
the remaining presence state publications, the presence aggregation
server removes the presence state publications that do not have a
corresponding activity token or custom string (i.e., the state
publications that do not include an activity). If there are no
remaining presence state publications, the presence aggregation
server publishes an indication that there is no current activity.
If there are remaining presence state publications, the presence
aggregation server selects the activity from the least available of
the remaining presence state publications as the current activity.
The presence aggregation server then publishes the current activity
of the publisher in the publisher's status container. The presence
aggregation server may also publish the current activity in one or
more of the publisher's other containers. In this instance where
the presence aggregation server publishes an indication that there
is no current activity, the endpoint (e.g., an application
executing on the endpoint) may select the default string that
represents the publisher's aggregated availability as the
publisher's current activity.
[0053] In some embodiments, a presence state publication may
include multiple activities. Each activity included in the
publication may have a corresponding indicator that specifies a
condition under which the particular activity is to be considered
valid. For example, a publication may indicate that the publisher's
activity is to be "Out of the Office" if the availability value is
greater than 15000, and that the activity is to be "Online"
otherwise. As another example, a publication may indicate that the
publisher's activity is to be "Out of the Office" between 10 a.m.
and 2 p.m., and that the activity is to be "Free" at the other
times during the day. One skilled in the art will appreciate that
the condition indication for an activity may be specified in other
ways. For example, a condition indicator may include a combination
of availability value ranges and a range of times.
[0054] In some embodiments, the presence aggregation server
determines an aggregated machine state for a publisher and
publishes this information. The presence aggregation server
identifies the publisher's most active machine state as the
publisher's aggregated machine state, and publishes this
information in the publisher's status container. The presence
aggregation server may also identify as the most active machine the
machine from which the most active machine state was published, and
publish an indication of the most active machine in the publisher's
status container. Each of the publisher's endpoints can use this
information in multiple points of presence scenarios, for example,
to automatically respond to a request that have been received by
all of the publisher's endpoints.
Custom Presence Information
[0055] In some embodiments, the presence aggregation system allows
for the publication of custom presence states by publishers. The
custom presence states are distinct from the default presence
states that are provided by the presence aggregation system. For
example, in addition to providing a set of default presence states,
such as the presence states listed above in Tables 2-6, the
presence aggregation system may support the definition and
inclusion of one or more custom presence states into the presence
aggregation system. Once the custom presence states are defined and
included in the presence aggregation system, the presence
aggregation server allows for the publication of any of the defined
custom presence states or default presence states as an indication
of presence for a publisher from, for example, any of the
publisher's multiple endpoints. By way of example, a company that
is using the presence aggregation system may also be using a
customer support application that allows the company's employees to
interact with customers via instant messaging. In this example, it
may be beneficial to the company if an employee can publish his or
her presence status as busy servicing a customer (e.g.,
"Busy--Talking to a Customer") when the employee is interacting
with a customer. Unfortunately, "Busy--Talking to a Customer" may
not be one of the default presence states that are provided by the
presence aggregation system. In this instance, a system
administrator of the company can define a custom presence state for
the presence status "Busy--Talking to a Customer." Once the custom
presence state is defined and included in the presence aggregation
system, an employee can use the presence aggregation system to
publish the custom presence state as the employee's presence status
(e.g., an employee can use the presence aggregation server to
publish a presence status that indicates his or her intent to
communicate as "Busy--Talking to a Customer"). In this manner, the
working set of presence states in the presence aggregation system
can be expanded, and the presence aggregation system can be
tailored to the needs of its users.
[0056] In some embodiments, the presence aggregation system
provides a description schema, such as, by way of example, an
Extensible Markup Language (XML) schema, for defining the custom
presence states. For example, a definition of a custom presence
state may include an identifier that identifies the instance of the
custom presence state, an availability value, and optionally an
activity token, one or more localized custom strings and, for each
localized custom string, a corresponding locale identifier. The
availability value is a number that represents the availability
corresponding to (indicated by) the custom presence state. The
activity token, when present, is a text string that describes the
custom presence state. A localized custom string, when present, is
a text string that further describes the custom presence state, and
which is localized to the region identified by the corresponding
locale identifier. A locale identifier, when present, corresponds
to a specific localized custom string and is a number that
identifies a region of the world. For example, the locale
identifier may be specified as a combination of a language
identifier and a region/culture identifier. The presence
aggregation system may maintain the defined custom presence states
in one or more files, such as XML files.
[0057] In some embodiments, the presence aggregation system may
provide a user interface through which a system administrator, or
other knowledgeable user, can define one or more custom presence
states. The user interface may be provided on the presence
aggregation server or the presence aggregation system's client
application. For example, the system administrator can use the
provided user interface to input the information (e.g.,
availability value, activity token, localized custom string, local
identifier, etc.) that is necessary to define a custom presence
state. Upon receiving the input information, the presence
aggregation system can create the custom presence state in the
system. In some embodiments, the presence aggregation system may
provide a programming interface, such as an API, through which a
program, such as an application program, can pass one or more
custom presence state definitions for inclusion in the presence
aggregation system. For example, an application program may include
in a file, such as an XML file, one or more custom presence state
definitions that conform to the description schema for defining a
custom presence state. The application program may then pass the
custom presence state definitions to the presence aggregation
system through the provided application interface to create the
custom presence states. The programming interface may be provided
on the presence aggregation server or the presence aggregation
system's client application.
[0058] In some embodiments, the presence aggregation system's
client application may provide a user interface through which a
publisher can access a list of the custom presence states that are
defined in the presence aggregation system. The publisher can then
use the user interface to view the list of custom presence states
and select a custom presence state in the list for publishing. When
the publisher selects one of the custom presence states, the
publisher's endpoint can publish the selected custom presence state
as a user state publication on the presence aggregation server. The
user interface may also allow the publisher to edit one or more of
the custom presence states that are defined in the presence
aggregation system. For example, the user interface may include a
selectable command or control to request editing of a custom
presence state definition. When the publisher activates the
selectable command or control, the client application may display a
window that displays a list of the defined custom presence states.
When the publisher selects a custom presence state, the client
application may display a window through which the publisher can
edit the definition of the selected custom presence state. The user
interface may also allow the publisher to specify which of the
defined custom presence states are to be included the list of
custom presence states. This feature allows for the definition of
many custom presence states in the presence aggregation system, and
the ability for the publisher to include in the list of custom
presence states the custom presence states which are applicable to
the publisher. In some embodiments, the user interface may also
allow the publisher to define and include a custom presence state
in the presence aggregation system.
[0059] In some embodiments, the client application may provide an
API which allows applications, such as third-party applications,
and devices, such as a PBX device, to publish custom presence
states. For example, an application may detect a presence status
for a user. Upon detecting the presence status, the application may
generate a custom presence state definition for the detected
presence status and send the generated custom presence state
definition to the client application for publication using the API.
Upon receiving the custom presence state definition, the client
application can publish the defined custom presence state as a
generic state publication on the presence aggregation server. The
API may also allow the application to query the client application
for a list of the defined custom presence states in the presence
aggregation system. The application can then determine if a
previously defined custom presence state adequately represents the
detected presence status and, if so, publish the previously defined
custom presence state using the API. In some embodiments, the
application or device may directly publish custom presence states
as generic state publications on the presence aggregation
server.
[0060] In some embodiments, the presence aggregation server
aggregates a publisher's custom presence state publications (e.g.,
published as either user state publications or generic state
publications) and the publisher's other presence state publications
to determine an aggregated availability and/or a current activity
of the publisher. An availability value specified in a custom
presence state publication may end up being the aggregated
availability of the publisher. Similarly, an activity (i.e.,
activity token and/or localized custom string(s)) that is specified
in a custom presence state publication may end up being the current
activity of the publisher. The presence aggregation server may
publish the aggregated availability and/or the current activity in
one or more of the publisher's containers, which may cause the
publisher's aggregated availability and/or current activity to be
sent to the subscribers who have subscribed to the containers into
which the aggregated availability and/or the current activity is
published. Each of the subscribers' endpoints can then display a
view of the published aggregated availability and/or the current
activity of the publisher.
[0061] In some embodiments, an endpoint can generate a view of a
published current activity by determining whether the current
activity specifies an activity token. If an activity token is
specified, then the endpoint determines whether it understands the
activity token and, if the activity token is understood, then the
endpoint displays the activity token as a view of the current
activity of the publisher. If an activity token is not specified or
the specified activity token is not understood, then the endpoint
determines whether a custom string is specified. For example, a
client application used to create the endpoint may be an older
version of the presence aggregation system's client application or
a third-party client application that does not understand (support)
the specified activity token. For each custom string that is
specified, the endpoint determines whether the custom string can be
rendered on the endpoint. For example, the endpoint can query the
operating system on the endpoint to determine whether the operating
system supports any of the specified locale identifiers. If a
locale identifier is supported by the operating system, the custom
string that is associated with the supported locale identifier can
be rendered on the endpoint. If any one of the specified custom
strings can be rendered, then the endpoint displays the custom
string that can be rendered as a view of the current activity of
the publisher. If a custom string is not specified or none of the
specified custom strings can be rendered, then the endpoint
displays a default string that represents the aggregated
availability of the publisher as a view of the current activity of
the publisher. The specification of localized custom strings allow
for the publication of a presence state in one region and a
rendering of the published presence state in another region in the
language that is appropriate for the rendering region.
[0062] Although the locale identifier is described in conjunction
with a custom presence state publication, any of the other presence
state publications (e.g., machine presence state publication,
calendar presence state publication, etc.) may specify a locale
identifier. For example, a machine state publication may include
one or more localized custom strings that further describe the
machine state that is being published and, for each localized
custom string a corresponding locale identifier. Similarly, a
calendar state publication, conference state publication, and phone
state publication may include one or more localized custom strings
that further describe the presence state that is being published
and, for each localized custom string a corresponding locale
identifier.
[0063] In some embodiments, the presence aggregation system may
provide localized default strings that describe the aggregated
availabilities. For example, for each of the aggregated
availabilities listed in Table 7, the presence aggregation system
may provide one or more localized default strings that describe the
corresponding aggregated availability. The presence aggregation
system may provide each specified localized default string with a
corresponding locale identifier. An endpoint, such as a subscriber
endpoint, is then able to display a view of a localized default
string that represents a publisher's aggregated availability, and
which is appropriate for the region (locale) in which the endpoint
is located.
[0064] FIG. 1 is a block diagram that illustrates components of a
presence aggregation system, according to some embodiments. A
presence aggregation system 102 is coupled to entity devices 104
via a network 106. The entity devices correspond to entities that
may be publishers or subscribers. The presence aggregation system
includes a receive update module 108, an update publication module
110, an add publication module 112, a receive subscription request
module 114, an add subscription module 116, a create container
module 118, a container store 120, an aggregation module 122, and
an expire publications module 124. Some or all of the modules may
be provided on a presence aggregation server or multiple presence
aggregation servers. The container store contains the containers of
the publishers (created by the create container module) and other
data structures used by the presence aggregation system. The
receive update module is invoked when a request to update a
publication is received from a publisher. The receive update module
invokes the update publication module to update the publication and
the add publication module to add a new publication to a container.
The receive subscription request module is invoked when a request
is received from an entity to subscribe to a container of a
publisher. The receive subscription request module invokes the add
subscription module to subscribe the entity to the specified
container or containers. The aggregation module processes the
presence state publications in a publisher's status container to
generate an aggregated state of the publisher. The expire
publications module is periodically invoked by the presence
aggregation system to clean up the expired (stale) publications in
the containers in the container store. Although not shown in FIG.
1, the entity devices include components of the presence
aggregation system to define containers and their ACLs, to send
publication updates, to send subscription requests, to receive
notifications of updates to publications, and to receive
publications from the presence aggregation system.
[0065] The network is typically a communications link that
facilitates the transfer of electronic content between the attached
devices. In some embodiments, the network includes the Internet. It
will be appreciated that the network may be comprised of one or
more other types of networks, such as a local area network, a wide
area network, a point-to-point dial-up connection, a wireless
network, and the like.
[0066] The computing devices on which the presence aggregation
system may be implemented may include a central processing unit,
memory, input devices (e.g., keyboard and pointing devices), output
devices (e.g., display devices), and storage devices (e.g., disk
drives). The memory and storage devices are computer-readable media
that may contain computer executable instructions that implement
the presence information system. As used herein, "computer-readable
media encoded with computer executable instructions" means
computer-readable media comprising computer executable
instructions. In addition, the data structures and message
structures may be stored or transmitted via a data transmission
medium, such as a signal on a communications link. Various
communications links may be used, such as the Internet, a local
area network, a wide area network, a point-to-point dial-up
connection, a cell phone network, and so on.
[0067] Embodiments of the presence aggregation system may be
implemented in various operating environments that include personal
computers, server computers, hand-held or laptop devices,
multiprocessor systems, microprocessor-based systems, programmable
consumer electronics, digital cameras, network PCs, minicomputers,
mainframe computers, distributed computing environments that
include any of the above systems or devices, and so on. The user
devices may be cell phones, personal digital assistants, smart
phones, personal computers, programmable consumer electronics,
digital cameras, and so on.
[0068] The presence aggregation system may be described in the
general context of computer-executable instructions, such as
program modules and components, executed by one or more computers
or other devices. Generally, program modules include routines,
programs, objects, components, data structures, and so on that
perform particular tasks or implement particular abstract data
types. Typically, the functionality of the program modules may be
combined or distributed as desired in various embodiments.
[0069] FIG. 2 is a data structure diagram that illustrates example
logical data structures of the presence aggregation system,
according to some embodiments. The data structure includes a
publisher table 202 that includes an entry for each publisher. Each
entry identifies a publisher and points to the publisher's
container table 204. The publisher's container table contains an
entry for each container of the corresponding publisher. Each entry
identifies the container (e.g., by name) and contains an ACL, a
subscriber list, and a publication list. The ACL specifies the
entities who are allowed to subscribe to the corresponding
container. The subscriber list identifies the subscribers who are
subscribed to the corresponding container. The publication list
contains an entry for each publication of the container. When a
publication is made in a container, the presence aggregation system
uses the subscriber list to identify the subscribers that are to be
notified. When an entity subscribes to a container, the presence
aggregation system uses the ACL to determine whether to grant or
deny the subscription. One skilled in the art will appreciate that
this is only one example of the logical layout of data structures
of the presence aggregation system. The data structures of the
presence aggregation system may be tailored to the
space/computation requirements of the presence aggregation system.
For example, the subscriber list may be provided in a separate
table, such as a subscriber table. Each entry in the subscriber
table may specify a publisher, a subscriber, and a list of
publications (including their versions). The presence can use the
combination of tables to determine what versions of the
publications should be seen by the subscribers.
[0070] FIG. 3 is a flow diagram that illustrates the processing of
the presence aggregation system, according to some embodiments. The
presence aggregation system monitors the status containers for
changes to the states of publishers. When a change in a state of a
publisher is detected, the system, in block 302, determines an
aggregated machine state of the publisher and publishes the
aggregated machine state in the publisher's status container. In
block 304, the system determines an aggregated availability of the
publisher. In block 306, the system determines the current activity
of the publisher. In block 308, the system publishes the aggregated
availability and the current activity as the aggregated state of
the publisher in the publisher's status container and the
publisher's other containers which have been designated as being
appropriate for the publication of the aggregated state. The
publisher can designate the containers that are appropriate for the
publication of the aggregated state.
[0071] One skilled in the art will appreciate that, for this and
other processes and methods disclosed herein, the functions
performed in the processes and methods may be implemented in
differing order. Furthermore, the outlined steps are only
exemplary, and some of the steps may be optional, combined with
fewer steps, or expanded into additional steps without detracting
from the essence of the invention.
[0072] FIG. 4 is a flow diagram that illustrates the processing of
the aggregation module in determining an aggregated machine state,
according to some embodiments. The aggregation module processes the
machine state publications in a publisher's status container and
notifies the publisher's endpoints of the single aggregated machine
state for the publisher's most active machine. In block 402, the
aggregation module selects the most active machine state (i.e., the
machine state publication having the lowest availability value). In
block 404, the aggregation module checks to determine whether there
are multiple most active machine states. If there is more than one
most active machine state, then, in block 404, the aggregation
module selects as the most recently published most active state. In
block 408, the aggregation module returns the most active machine
state. In some embodiments, the aggregation module identifies the
machine that published the most active machine state, and returns
an indication of this machine (i.e., the most active machine). If
two machines (e.g., respective endpoints on the two machines)
published the same machine state that was determined to be the most
active machine state, the aggregation module identifies as the most
active machine the machine that most recently published the most
active machine state. For example, if a Machine A published an
Active machine state at 1:00 PM and a Machine B published an Active
machine state at 1:30 PM, the aggregation module identifies Machine
B as the most active.
[0073] FIG. 5 is a flow diagram that illustrates the processing of
the aggregation module in determining an aggregated availability,
according to some embodiments. In block 502, the aggregation module
determines a valid set of states from which to generate an
aggregated availability. The valid set of states may include the
most active machine state and any user state, phone states,
calendar states, conference states, and generic state publications
in the subscriber's status container. In block 504, the aggregation
module checks to determine if a user state is published. If the
aggregation module determines that a user state publication is
present in the status container, then, in block 506, the
aggregation module removes the states that are older than the user
state from the valid set of states. For example, the aggregation
module identifies the states in the valid set of states that have
publication times that are older than the publication time of the
user state, and removes these older states from the valid set of
states. If, in block 504, the aggregation module determines that a
user state is not published, or subsequent to removing from the
valid set of states the states that are older than the published
user state in block 506, the aggregation module, in block 508,
selects as the aggregated availability the least available state
(e.g., the state having the highest availability value) from the
valid set of states. In block 510, the aggregation module returns
the aggregated availability.
[0074] FIG. 6 is a flow diagram that illustrates the processing of
the aggregation module in determining a current activity, according
to some embodiments. In block 602, the aggregation module
determines a valid set of states from which to determine the
current activity of a publisher. The valid set of states may
include the most active machine state and any user state, phone
states, calendar states, conference states, and generic state
publications in the subscriber's status container. In block 604,
the aggregation module removes from the valid set of states the
states that do not have a corresponding activity token. For
example, some publications may not specify an activity token. In
block 606, the aggregation module checks to determine whether the
valid set of states is empty. If the valid set of states is not
empty, then, in block 608, the aggregation module selects the
activity from the least available state as the current activity. In
block 610, the aggregation module returns the current activity.
Otherwise, if the aggregation module determines that the valid set
of states is empty (block 606), then, in block 612, the aggregation
module returns an indication of no current activity.
[0075] FIG. 7 is a block diagram that illustrates the publication
of a custom presence state, according to some embodiments. This
figure illustrates the publishing of a custom presence state by a
human user. A human User A 702 at an endpoint 704 initiates the
publication of a custom presence state by selecting the desired
custom presence state using a user interface 706, and activating a
control to publish the selected custom presence state. The presence
aggregation system's client application may provide the user
interface on the endpoint. In response, User A's endpoint publishes
the selected custom presence state as a user state publication in,
for example, User A's status container on presence aggregation
server 708. The presence aggregation server may then generate an
aggregated presence state for User A by aggregating User A's
presence state publications, and publishes the aggregated presence
state in, for example, a container that is subscribed to by User B
710. When User's A's aggregated presence state is published into
the container that is subscribed to by User B, the presence
aggregation server sends an indication of User A's presence (the
aggregated presence state) to User B's endpoint 712. User B's
endpoint may then generate and display a view 714 of User A's
presence.
[0076] FIG. 8 is a block diagram that illustrates the publication
of a custom state, according to some other embodiments. This figure
illustrates the publishing of a custom presence state by an
application 802, such as a third-party application using an API 804
that is provided by the presence aggregation system's client
application 806 executing on, for example, a publisher's endpoint.
The application initiates the publication of the custom presence
state for a publisher by generating a custom presence state
definition for a detected presence status of the publisher. The
application then sends the generated custom presence state
definition to the client application via the provided API. Upon
receiving the custom presence state definition, the client
application publishes the defined custom presence state as a
generic state publication in, for example, the publisher's status
container on presence aggregation server 808. The presence
aggregation server may then generate an aggregated presence state
for the publisher by aggregating the publisher's presence state
publications, and publishes the aggregated presence state in, for
example, a container that is subscribed to by User C 810. When the
publisher's aggregated presence state is published into the
container that is subscribed to by User C, the presence aggregation
server sends an indication of the publisher's presence (the
aggregated presence state) to User C's endpoint 812. User C's
endpoint may then generate and display a view 814 of the
publisher's presence.
[0077] FIG. 9 is a display diagram showing a sample user interface
displaying a drop-down menu containing a list of selectable custom
presence states, according to some embodiments. User interface 900
may be displayed by an instance of a client application signed onto
by a user to create an endpoint. The user interface allows the user
to view a list of the custom presence states that are supported by
the presence aggregation system and from which the user can
manually specify a custom presence state for publication. The user
interface allows access to a subwindow or drop-down window 902,
which displays a list of custom presence states 904 that are
available for selection by the user as the user's presence status.
As depicted, "Meeting with a Customer" and "Out to Lunch" are the
custom presence states (i.e., the custom activities that correspond
to the custom presence states) that are available for selection by
the user. The list of custom presence states may be a subset of the
custom presence states that are defined and supported by the
presence aggregation system. Drop-down window 902 also displays
commands 906 and 908. Command 906, depicted in the figure as "Reset
Status," is a command that the user can activate to clear out the
current user states or the customer presence state that is
currently being published. Selecting any one of the displayed user
states or the custom presence state causes the selected state to be
published. Command 908, depicted in the figure as "Edit Custom
Activities," is a command that the user can activate to display,
for example, in a pop-up window a list of custom activities
corresponding to the defined custom presence states that are
supported by the presence aggregation system. Using this pop-up
window, the user can specify the custom presence states that are to
be included in the list of custom presence states. In some
embodiments, the user can also select a custom presence state
displayed in the pop-up window for editing.
[0078] FIG. 10 is a display diagram showing a sample pop-up window
containing a list of selectable custom activities, according to
some embodiments. In particular, pop-up window 1000 is displayed
when command 908 in drop-down window 902 shown in FIG. 9 is
selected, for example, by a user. The pop-up window displays a list
of custom activities 1002, a checkbox 1004 next to each listed
custom activity, and an OK control 1006. The custom activities in
the list of custom activities correspond to the custom presence
states that are supported by the presence aggregation system. As
depicted, "Meeting with a Customer," "Out to Lunch," "Working from
Home," and "At an Offsite" are the custom activities that are
listed and which can be selected for displaying in drop-down window
902 shown in FIG. 9. The checkbox next to each custom activity can
be selected to "choose" the corresponding custom activity. As
depicted, the first two checkboxes corresponding to custom
activities "Meeting with a Customer" and "Out to Lunch" are
selected. When the OK control is activated, the selected or chosen
custom activities are listed in drop-down window 902 shown in FIG.
9. In some embodiments, the presence aggregation server allows a
user to select up to a predetermined number, such as, for example,
four, of custom activities for displaying in drop-down window 902
shown in FIG. 9. In some embodiments, the custom activities
included in the displayed list of custom activities in the pop-up
window may be selected for editing. For example, the user may
select one of the listed custom activities for editing by
positioning the cursor over a listed custom activity and
double-clicking the right mouse button. This may cause another
pop-up window to appear through which the user can view the current
definition of the custom presence state corresponding to the
selected custom activity, and with which the user can edit the
definition of the corresponding custom presence state. In some
embodiments, the pop-up window may provide an "edit definition"
control (not shown) which can be activated to edit the definition
of the custom presence state corresponding to a selected custom
activity.
[0079] FIG. 11 is an example data listing that illustrates multiple
custom state definitions, according to some embodiments. As
depicted, the data listing contains a "<custom states>"
section 1102 that contains a multiple number of custom presence
state definitions 1104. Each custom presence state definition
specifies a custom state ID, an availability, an activity token,
and zero, one, or more custom strings and, for each specified
custom string, a locale identifier (LCID). The custom state ID
specifies a value that identifies the custom presence state that is
being defined. The availability specifies a value that represents
the availability corresponding to the custom presence state that is
being defined. The activity token specifies a text string that
describes the custom presence state that is being defined. Each
custom string specifies a localized text string that further
describes the custom presence state that is being defined. Each
LCID specifies a number that identifies a language and a region
(locale) of the world. For example, LCID of "1033" may identify
"English--United States," LCID of "1031" may identify
"German--Germany," LCID of "2057" may identify "English--United
Kingdom," and LCID of "1036" may identify "French--France." A
custom string corresponding to an LCID of 1036 may be a French text
sting that describes the custom presence state localized to France.
Similarly, a custom string corresponding to an LCID of 1031 may be
a German text sting that describes the custom presence state
localized to Germany, a custom string corresponding to an LCID of
1033 may be an English text sting that describes the custom
presence state localized to the United States, and a custom string
corresponding to an LCID of 2057 may be an English text sting that
describes the custom presence state localized to the United
Kingdom. The activity token and the custom strings and their
corresponding LCIDs are optional and may not be specified in a
custom presence state definition. As depicted, the first custom
presence state definition may be for the custom activity "Meeting
with a Customer," the second custom presence state definition may
be for the custom activity "Out to Lunch," and the last custom
presence state definition may be for the custom activity "At an
Offsite" displayed in pop-up window 1000 in FIG. 10.
[0080] FIG. 12 is a flow diagram that illustrates the processing of
an endpoint in displaying a view of a current activity, according
to some embodiments. By way of example, a subscriber's endpoint may
have received from the presence aggregation server an indication of
a publisher's current activity. In decision block 1202, if the
current activity specifies an activity token, then the endpoint
continues at decision block 1204, else the endpoint continues at
decision block 1208. In decision block 1204, if the activity token
is understood by the endpoint, then the endpoint continues at block
1206, else the endpoint continues at decision block 1208. In block
1206, the endpoint displays the activity token, for example, as a
view of the publisher's presence on the endpoint, and then
completes. In decision block 1208, if any custom strings are
specified, then the endpoint continues at decision block 1210, else
the endpoint continues at block 1214. In decision block 1210, if
any of the specified custom strings can be rendered by the
endpoint, then the endpoint continues at block 1212, else the
endpoint continues at block 1214. For example, the endpoint can use
the LCID corresponding to each specified custom string to determine
if the corresponding custom string can be rendered. In block 1212,
the endpoint displays the custom string that can be rendered, for
example, as a view of the publisher's presence on the endpoint, and
then completes. If multiple specified custom strings can be
rendered, the endpoint may determine the custom string to render
based on a priority scheme such as, by way of example, a ranking or
ordering of the locales. In block 1214, the endpoint displays the
default string that represents the aggregated availability of the
publisher, for example, as a view of the publisher's presence on
the endpoint, and then completes.
[0081] From the foregoing, it will be appreciated that specific
embodiments of the presence aggregation system have been described
herein for purposes of illustration, but that various modifications
may be made without deviating from the spirit and scope of the
invention. For example, one skilled in the art will appreciate that
a publisher may publish presence information directly to one or
more of the publisher's containers. In response to such a
publication, the presence aggregation system can notify the
subscribers who have subscribed to these containers the presence
information published by the publisher. As another example, one
skilled in the art will appreciate that a publication may have a
corresponding expire type that indicates the condition or
conditions under which to expire the publication. For example, the
expire type may indicate that a publication is to be expired after
a duration of time, after the publisher logs off from all of the
publisher's endpoints, when the publisher is no longer using any of
the publisher's machines, etc. Accordingly, 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.
* * * * *