U.S. patent application number 12/704271 was filed with the patent office on 2010-06-17 for presence indication configuration methodology.
This patent application is currently assigned to YAHOO! INC.. Invention is credited to Brian Kobashikawa, Mehul Sanghavi, Christopher T. Szeto.
Application Number | 20100153854 12/704271 |
Document ID | / |
Family ID | 42008174 |
Filed Date | 2010-06-17 |
United States Patent
Application |
20100153854 |
Kind Code |
A1 |
Sanghavi; Mehul ; et
al. |
June 17, 2010 |
PRESENCE INDICATION CONFIGURATION METHODOLOGY
Abstract
A presence model is maintained for a messaging system to message
among a plurality of computing device users. A permission is
maintained for providing to a first computing device a presence
indication for a user of a second computing device. Based on an
indication of a user of the first computing device not being in a
messaging list for the user of the second computing device, the
permission is maintained to provide only a basic presence
indication to the first computing device for the user of the second
computing device. From the first computing device, a message is
caused to be sent to the second computing device. Based on the
maintained permission, the basic presence indication for the user
of the second computing device is provided to the first computing
device and a user interface element is provided via which the user
of the first computing device can be added to a messaging list for
the user of the second computing device.
Inventors: |
Sanghavi; Mehul; (Sunnyvale,
CA) ; Kobashikawa; Brian; (San Francisco, CA)
; Szeto; Christopher T.; (San Jose, CA) |
Correspondence
Address: |
Weaver Austin Villeneuve & Sampson - Yahoo!
P.O. BOX 70250
OAKLAND
CA
94612-0250
US
|
Assignee: |
YAHOO! INC.
Sunnyvale
CA
|
Family ID: |
42008174 |
Appl. No.: |
12/704271 |
Filed: |
February 11, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12209859 |
Sep 12, 2008 |
7689650 |
|
|
12704271 |
|
|
|
|
Current U.S.
Class: |
715/751 ;
726/4 |
Current CPC
Class: |
G06Q 10/107
20130101 |
Class at
Publication: |
715/751 ;
726/4 |
International
Class: |
G06F 21/20 20060101
G06F021/20; G06F 15/16 20060101 G06F015/16; G06F 3/048 20060101
G06F003/048 |
Claims
1. A method of maintaining a permission model for a messaging
system to message among a plurality of computing device users via a
communication network, wherein the permission model governs what
level of presence information may be provided to the computing
device users regarding other computing device users, the method
comprising: receiving a request from a first user, of a first
computing device, to subscribe to presence information of a second
user, of a second computing device, and, based thereon, allowing
the first user to receive a basic level of presence information of
the second user; based on receiving the request from the first
user, querying the second user as to whether to allow the first
user to receive an enhanced level of presence information of the
second user; and based on a response to the query, from the second
user, configuring the permission model to govern what level of
presence information of the second user is allowed to be provided
to the first user.
2. A method of maintaining a presence model for a messaging system
to message among a plurality of computing device users via a
communication network, comprising: maintaining a permission for
providing to a first computing device a presence indication for a
user of a second computing device; based on an indication of a user
of the first computing device not being in a messaging list for the
user of the second computing device, maintaining the permission to
provide a basic presence indication to the first computing device
for the user of the second computing device and to not provide to
the first computing device an enhanced presence indication for the
user of the second computing device; from the first computing
device, causing a message to be sent to the second computing device
and, based on the maintained permission, providing the basic
presence indication for the user of the second computing device to
the first computing device; and providing a user interface element
at the second computing device to provide an indication to the
messaging system of whether to add the user of the first computing
device to a messaging list for the user of the second computing
device, so as to maintain the permission to provide the enhanced
presence indication to the first computing device for the user of
the second computing device.
3. The method of claim 2, wherein: the basic presence indication
includes an indication of whether the user of the second computing
device is online to receive messages from the first computing
device.
4. The method of claim 3, wherein: the enhanced presence indication
includes all of the information in the basic presence indication
and, additionally, includes information about the user of the
second computing device beyond merely whether the user of the
second computing device is online to receive messages from the
first computing device.
5. The method of claim 2, further comprising: based on not
receiving an indication to the messaging system of whether to add
the user of the first computing device to a messaging list for the
user of the second computing device, maintaining the permission to
provide the basic presence indication to the first computing device
for the user of the second computing device.
6. The method of claim 2, wherein: the user interface element is
additionally to provide an indication to the messaging system of
whether to add the user of the first computing device to a block
list for the user of the second computing device, so as to maintain
the permission to provide no presence indication to the first
computing device for the user of the second computing device.
7. The method of claim 2, wherein: maintaining the permission
further includes maintaining a global default presence indication
for the second user; and wherein the method further comprises
responding to a global presence indication request made by the user
of the first computing device for the presence indication of the
second user, including determining if the user of the first
computing device is an identified user; if the user of the first
computing device is determined to not be an identified user,
providing the global default permission as the requested global
presence indication; and otherwise, if the user of the first
computing device is in the messaging list associated with the
second user, providing the user of the first computing device with
the enhanced presence indication for the user of the second
computing device as the requested global presence indication.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation and claims priority under
35 U.S.C. 120 to U.S. patent application Ser. No. 12/209,859, filed
Sep. 12, 2008 entitled "PRESENCE INDICATION CONFIGURATION
METHODOLOGY" to Mehul Sanghavi et al. This application is
incorporated in its entirety by reference as if fully set forth
herein.
BACKGROUND
[0002] Presence, in a networked enterprise setting, is a published
indication of a user's availability and/or willingness to
communicate with other users, such as by instant messaging (IM).
The indication may be "basic," including only limited information
about the user ("online" or "offline"), or the indication may be
"extended," including more extensive information about the user,
such as status and/or profile information.
[0003] In accordance with one basic presence model, one user (User
A) cannot see the presence indication for another user (User B)
unless the following condition is met: [0004] User A adds User B to
User A's messenger list; and [0005] Either [0006] User B approves
(authorizes) User A to be on User B's messenger list; or [0007]
User B approves (authorizes) User A to view User B's presence
without User A being added to User B's messenger list. Thus, once
User B approves User A, each user can see the online presence
indication of the other user.
[0008] It can be difficult for a user to leverage existing contact
information to initiate contact with other users. This can be an
impediment to building a critical mass of users with which a
particular user may IM. One proposed solution has included a user
sending mass invitations to other users to add the user to the
other users' messenger lists, but this process can be cumbersome,
redundant and chaotic.
SUMMARY
[0009] In accordance with an aspect, a method is provided to
maintain a presence model for a messaging system to message among a
plurality of computing device users via a communication network. A
permission is maintained for providing to a first computing device
a presence indication for a user of a second computing device.
Based on an indication of a user of the first computing device not
being in a messaging list for the user of the second computing
device, the permission is maintained to provide a basic presence
indication to the first computing device for the user of the second
computing device and to not provide to the first computing device
an enhanced presence indication for the user of the second
computing device.
[0010] From the first computing device, a message is caused to be
sent to the second computing device. Based on the maintained
permission, the basic presence indication for the user of the
second computing device is provided to the first computing device.
Additionally, a user interface element is provided, to provide an
indication to the messaging system of whether to add the user of
the first computing device to a messaging list for the user of the
second computing device, so as to maintain the permission to
provide the enhanced presence indication to the first computing
device for the user of the second computing device.
BRIEF DESCRIPTION OF THE FIGURES
[0011] FIG. 1 is a system diagram illustrating how the provision of
presence indications of users may be configured in accordance with
an aspect.
[0012] FIGS. 2A-2D collectively show a storyboard diagram
illustrating several scenarios with respect to how a presence model
may be configured to selectively present basic and enhanced
presence indications.
[0013] FIG. 3 is a table illustrating an example of states with
respect to whether a particular user is provided with the presence
indication, basic or extended, of another user.
[0014] FIG. 4 is a simplified diagram of a network environment in
which specific embodiments of the present invention may be
implemented.
[0015] FIG. 5 is a flowchart illustrating an example process to,
using the example users of Sara and Aaron, determine whether Sara
and Aaron are added to each other's messaging lists.
[0016] FIG. 6 is a flowchart illustrates an example process to,
still using the example users of Sara and Aaron, determine what
presence indication to present to Aaron for Sara.
[0017] FIG. 7A is an example of a slider user interface, in which a
privacy setting may be set anywhere from "private" to "public",
with other intermediate settings. FIG. 7B is a table illustrating
an example of the continuum of preset privacy settings.
DETAILED DESCRIPTION
[0018] The inventors have realized the desirability of allowing
users more control over how their presence indication may be
presented to other users and, in particular, allowing for finer
grained control with respect to casual and intimate contact. In a
broad aspect, a basic presence indication for a particular user may
be automatically provided to another user based on the other user
causing a message to be sent to the particular user, the basic
presence indication for the particular user being provided without
explicit authorization being required by the particular user. In
addition, the particular user may control, via a user interface
provided to the particular user based on the message being sent
from the other user to the particular user, whether the other user
is allowed to be provided an enhanced presence indication for the
particular user.
[0019] Thus, for example, basic presence information can be
provided to users with whom the particular user may have only
casual contact, without any special configuration being required,
whereas enhanced presence information may be provided to users with
whom the particular user has or desires to have more intimate
contact. Furthermore, the level of presence information allowed to
be provided need not be decided by the particular user in advance
of the contact. In addition, the user may be provided the ability
to control a global "default" presence indication, which may
provide more less information than the basic presence information,
and which may be overridden by more a detailed configuration based
on user's messenger list (e.g., the messenger list may be
configured to allow an enhanced presence indication to be provided
to a particular other user or to completely block a presence
indication from being provided to a particular other user).
[0020] FIG. 1 schematically illustrates an aspect of the invention,
in which a plurality of users (User A 102a, User B 102b, . . . ,
User X 102x collectively, indicated by reference numeral 102) may
communicate over a network using a communication methodology such
as instant messaging (IM). While some of the users may be on the
same IM network, some of the users may be on different IM networks,
such that inter-network communication is required to accomplish IM
communication between such users. In some instances, the networks
may operate according to different IM protocols, such as by
accommodating for the dissimilar protocols inside the IM client
application or by accommodating for the dissimilar protocols inside
an IM server application.
[0021] Referring still to FIG. 1, the messaging network or networks
(such as an IM network or networks) are denoted by the reference
numeral 104. Typically, the IM networks 104 operate using a
protocol operating over one or more public or quasi-public
networks. Furthermore, an IM "presence model" 106 governs the
mechanism and rules by which presence indications are shared among
the users 102. The presence model is typically implemented by
functionality on any one or more of client devices employed by the
users 102 and/or any one or more of servers employed by one or more
IM service providers.
[0022] Furthermore, FIG. 1 illustrates a scenario in which the user
A 102a initiates communication to user B 102b via the messaging
networks 104, as represented by arrow 108(1). This may include, for
example, user A 102a interacting with a client computing device to
cause an instant message to be sent to user B 102b. Furthermore,
user A 102a is not in the messenger list for user B 102b, nor is
user A 102a on a block list for user B 102b. As a result of the
message being sent, the presence model 106 operates (108(2)) to
cause a basic presence indication for User B 102b to be provided to
User A 102a. Thus, user A 102a knew the IM identification for user
B 102b and, thus, is able to send a message to user B 102b and get
a basic presence indication for user B 102b. Furthermore, in
accordance with some examples, as a result of the instant message
being sent to User B 102b, a presence indication (basic or
enhanced) for User A 102a may be provided to User B 102b.
[0023] In addition, a user interface element is caused (108(3)) to
be provided to User B 102b, regarding whether the presence model
106 should allow an enhanced presence indication for User B 102b to
be provided to User A 102a. In addition, the user interface element
may also be regarding whether the presence model should allow even
the basic presence indication for User B 102b to be provided to
User A 102a.
[0024] Thus, User B 102b may, via the user interface element,
approve (108(4)) the provision of the enhanced presence indication
for User B 102b to User A 102a or block the provision of any
presence indication for User B 102b to User A 102a. In this case,
user B 102b approves adding user A 102a to the messenger list for
user B 102b, and the enhanced presence indication for User B 102b
is allowed to be provided (108(5)) to User A.
[0025] In some examples, User B 102b may neither approve the
provision of the enhanced presence indication nor block the
provision of any presence indication. In such an example, a default
action may be taken, such as continuing to allow the basic presence
indication for User B 102b to be provided to User A 102a.
Furthermore, if a presence indication for User A 102a was provided
to User B 102b, this may aid User B 102b in determining what action
to take with respect to allowing a presence indication for User B
102b to be provided to User A 102a by, for example, providing
additional information helpful for user B 102b to make a
determination.
[0026] It can thus be seen that, in accordance with one broad
aspect, a user may precisely control access to her presence
information, based on an informed decision prompted by an attempt
by another user to send a message to that user. In addition, the
attempt by the other user to send the message to that user may
result in allowing enhanced presence information for the other user
to be provided to that user, so as to further inform that user's
decision.
[0027] FIGS. 2A-2D collectively show a storyboard flowchart
illustrating, in greater detail, a scenario providing an example of
this presence model access methodology. The story involves two
users--Sara and Aaron. At frame 202, Aaron desires to converse with
Sara, but Aaron doesn't know whether Sara is online since, at this
point, Aaron has not been provided access to Sara's presence
information. At frame 204, Aaron decides to type Sara's name into
the contacts search bar. In the example, Sara is in Aaron's address
book, so Sara's messaging ID is autocompleted. At frame 206, Aaron
inputs a message to Sara and presses the "send" button.
[0028] In the example shown in the FIGS. 2A-2D storyboard, at frame
208, because Aaron identified Sara and sent Sara a message, in the
presence model, Sara is implicitly added to the list of users for
whom Aaron can be provided a presence indication--in this case, a
basic presence indication. At frame 210, Sara receives a
notification of the incoming instant message from Aaron. Frame 212
is an indication of Sara's quandary, whether or not to communicate
with Aaron.
[0029] Frames 214 to 230 illustrate an example in which Sara
decides to communicate with Aaron. At frame 214, Sara decides to
communicate with Aaron. At 216, Sara clicks on the IM tab for
Aaron's message, which indicates that the message from Aaron is new
and unread. At 218, Sara views Aaron's presence indication (which,
in the FIGS. 2A-2D storyboard example, is an enhanced presence
indication such that more than the basic "online"/"offline"
indication is provided).
[0030] At 220, a user interface element is provided via which Sara
may add Aaron to a messenger list associated with Sara, such that
Aaron is provided an enhanced presence indication for Sara. In
addition, Sara may also utilize the user interface element to block
Aaron from receiving even a basic presence indication for Sara, by
adding Aaron to Sara's block list. However, at 222, Sara converses
with Aaron, all the while without having utilized the user
interface element discussed with respect to 220. In this example,
Aaron continues to be provided the basic presence indication for
Sara, as a default. At 224, Sara closes the IM window. At 226, a
dialog box user interface element is displayed to Sara, inquiring
as to whether Aaron should be added to Sara's messenger list. At
228, Sara adds Aaron to Sara's messenger list, and Sara is provided
Aaron's enhanced presence indication. At 230, due to Sara's action
to add Aaron to her messenger list, Aaron continues to be provided
Sara's enhanced presence indication. It can thus be seen that the
bi-directional relationship (in which both Aaron and Sara get
access to each other's enhanced presence indication) is not
established automatically but, rather, depends on Sara and how
quickly Sara decides to reciprocate Aaron's request (in this
example, as Aaron's request is evidenced by Aaron sending the
message to Sara).
[0031] Frames 232 to 240 illustrate a scenario in which Sara
decides to not allow Aaron to be presented Sara's presence
indication at all. At frame 232, Sara determines that she doesn't
know Aaron. At frame 234, Sara is contemplating blocking Aaron
permanently from being provided Sara's presence indication.
However, at frame 236, Sara decides to just close the tab
indicating Aaron's message to Sara. At 238, Sara is presented with
a dialog box user interface item via which Sara may put Aaron on
Sara's block list, to block Aaron from being provided Sara's
presence indication and, furthermore, to block future messages from
Aaron. At 240, from Aaron's point of view, Sara has gone offline,
since Aaron is blocked from being provided Sara's presence
indication. (It should be noted that, even if Aaron is on Sara's
block list, Aaron may still have access to Sara's online presence
indication which, as discussed with reference to an example below,
may provide Sara's online presence as a default if Aaron requests
the online presence but is not identified to the IM presence model
as Aaron--i.e., for example, is not "logged in.")
[0032] It can thus be seen that a user can control, via her
messenger list and block list, what other users will be provided
her basic and/or enhanced presence indication, while there is a
default state that users not in the messenger list or block list
will be provided the basic presence indication as a result of
identifying the user (e.g., by sending the user a message). FIG. 3
is a table illustrating an example corresponding to the FIGS. 2A-2D
storyboard example, of states with respect to whether a particular
user (in the example, Aaron) is provided with the presence
indication, basic or extended, of another user (in the example,
Sara). Row 302 represents the state of Aaron being provided with a
basic presence indication for Sara, and row 304 represents the
state of Aaron being provided with an extended presence indication
for Sara. Furthermore, column 306 represents the conditions under
which the states represented by the rows exist, and column 308
represents what state otherwise exits, in the absence of the column
306 conditions.
[0033] Turning now to FIG. 3 and specifically to column 306, it can
be seen that, in accordance with the example, in order for Aaron to
be provided Sara's basic presence indication, there is nothing that
Aaron must do beyond specifically identifying Sara, such as by
sending a message to Sara. On the other hand, Aaron must not be in
Sara's block list. Thus, from column 308, in accordance with the
example, it can be seen what occurs if the conditions in column 306
are not met. For example, if Aaron is in Sara's block list, then
the presence indication provided to Aaron for Sara will always
indicate that Sara is "offline." Furthermore, if Aaron is not in
Sara's block list, but Aaron also is not in Sara's messenger list,
then the presence indication provided to Aaron for Sara will be a
basic presence indication.
[0034] It should be noted that the previous examples are just
that--examples--and other examples are possible. For example,
providing or blocking a presence indication is not limited to what
is specifically described. For example, blocking Sara's presence
indication from being provided to Aaron may include completely
blocking the presence indication (and, for example, indicating that
the presence information is being blocked or otherwise providing a
"null" indication) or, in some examples, it may include allowing
the provision of a presence indication to Aaron that is essentially
meaningless, such as always providing an indication that Sara is
offline, whether or not that presence indication is truly
indicative of Sara's presence status.
[0035] As another example, the presence or absence of Aaron on a
white list or black list associated with Sara may be overridden by
other circumstances, such as global profiles associated with the
presence model. As one example, Sara's IM system may be
administratively configured to not allow presence indications to be
provided to users of certain domains, or to only allow presence
indications to be provided to users of certain domains. As another
example, Sara may have configured her profile in a "do not disturb"
mode to globally present an offline presence indication, even
though Sara is not offline.
[0036] In accordance with an additional aspect, a global online
presence indicator may be enhanced such that an individual user's
messaging and/or block list is consulted, thus minimizing or
avoiding inconsistent presence indications. Conventionally, global
online presence indications are provided without consultation to a
user's messenger and/or block list. In accordance with the
additional aspect, then, the particular user can configure the
global online presence indicator to provide a default presence
indication, which may be overridden based on the particular user's
messenger and/or block list, without regard for other users'
messenger lists. That is, this enforces the notion that the only
users who can see the particular user's enhanced presence
indication are users who are on the particular user's messaging
list, without regard for whether, at some point, the particular
user had given permission for the other user's to put the
particular user on their messaging lists.
[0037] Put another way, as an example, the user can have the
ability to set a global "do not show me as online" preference that
will override the ability to see that user's basic presence by all
users not on that user's messaging list. This may be seen as akin,
for example, to not publishing a user's phone number in the phone
book--but anyone who is called by that user can see the user's
number/name via caller ID.
[0038] As another example, Sara may have configured her profile to
allow particular information to only be provided to particular
denoted users, such as very personal information that Sara desires
is not to be made generally available even as part of her "normal"
enhanced profile, except perhaps to close friends or family. Such
configuration may be made, for example, using user interface
elements associated with Sara's messenger list.
[0039] A useful result of the scenarios discussed above includes,
for example, that a user can be prompted to decide "on the fly" if
she wishes to communicate with a particular other user, as the
particular other user attempts to communicate with that user.
Furthermore, that "on the fly" decision may include treating the
particular other user as a mere casual contact such as, by allowing
only basic presence information to be provided to the particular
other user. In addition, by prompting a user to build up her
messenger list "on the fly," this can overcome what might otherwise
be an impediment to using instant messaging, which is that
generally one would have to populate a messenger list with contact
information for other users prior to being able to carry on instant
messaging communication with those users.
[0040] We now refer to FIG. 5, which is a flowchart illustrating an
example process to, using the example users above of Sara and
Aaron, determine whether Sara and Aaron are added to each other's
messaging lists (which, as discussed above, a presence model uses
to control how and what presence indications are provided). The top
portion 502 indicates processing with respect to Aaron (a message
sender), whereas the bottom portion 552 indicates processing with
respect to Sara (a message recipient).
[0041] Starting with the top portion 502, processing begins at 504.
At 506, there are two diverging paths. At 508, Aaron clicks an
"add" button on a user interface presented to Aaron and provides
Sara's messenger ID. On the other path, at 510, Aaron sends Sara a
message (such as an instant message). At 516, Aaron adds Sara to
Aaron's messenger list. Access to Sara's online presence indication
(OPI) is, at this point, according to Sara's global preferences,
since Aaron is neither in Sara's messaging list nor in Sara's block
list. At 518, if it was not already provided, a new messaging
window is presented to Aaron with a message addressed to Sara. At
520, processing ends. Continuing now on the other path, from 510,
at 512, it is determined if Aaron decides to add Sara to Aaron's
messenger list. If not, processing ends at 514. If so, then
processing continues at 516, where access only to Sara's OPI is
provided.
[0042] We now refer to the lower portion 552 of FIG. 5, which
indicates processing with respect to Sara. At 554, it is determined
if Sara has Aaron in Sara's block list. If not, then Sara receives
a new message alert at 556. At 558, it is determined if Aaron is in
Sara's messenger list. If Aaron is already in Sara's messenger
list, then add processing with respect to Sara ends 560. Also, if
at 554, it was determined that Sara has Aaron in Sara's block list,
then Aaron's message is dropped 562 (e.g., with neither Aaron or
Sara being notified of such) and processing ends 560.
[0043] If, at 558, it is determined that Sara does not have Aaron
in Sara's messenger list, then three alternatives 564 are possible.
At 566, Sara decides to add Aaron to Sara's messenger list. Access
to Aaron's OPI relies upon Aaron's preferences. At 568, Sara
decides to block Aaron. Aaron is added to Sara's block list, and
Aaron cannot even see Sara's OPI, since the block list overrides
the OPI. At 570, Sara does nothing with respect to adding Aaron, so
Aaron is neither on Sara's messenger list nor on Sara's block list,
and processing ends at 576.
[0044] Having described the "add flow" (processing to add a user to
a messenger list or block list), we now describe with reference. In
this case, FIG. 6 illustrates how it may be determined what
presence indication to present to Aaron for Sara. The top portion
602 refers to processing with respect to Aaron (a message sender),
whereas the bottom portion 652 indicates processing with respect to
Sara (a message recipient). Processing begins at 604.
[0045] At 606, an IM Window/Profile with Sara is opened. On Sara's
side (see bottom portion 652 of FIG. 6), if Sara has Aaron in
Sara's block list, then Sara's presence is presented to Aaron as
offline. If, at 654, Sara does not have Aaron in Sara's block list
then, if Sara has Aaron in Sara's messenger list (656) then, at
658, Aaron sees Sara's enhanced presence indication, such as
including status message, if Sara has created a status message.
Otherwise, if at 654, Sara does not have Aaron in Sara's block list
and Sara does not have Aaron in Sara's messenger list, then, at
660, Aaron only sees Sara as "available" or "offline."
[0046] On the other hand, if Sara does not have Aaron in Sara's
block list (654) and, at 662, Sara is offline to Aaron (either
because Sara is truly offline, is invisible to everyone, or is
selectively invisible to Aaron), then Aaron sees Sara as offline
(656). Otherwise, Aaron sees Sara as online 664.
[0047] Having described examples of add flow and presence flow, we
now describe an example in which a user may control her online
presence indication (OPI), and related messaging privacy settings,
globally. Furthermore, the example provides that the user may
control her OPI using a continuum of preset privacy settings,
beyond a mere binary on/off setting for the online presence
indication. In FIG. 7a, an example is shown of a slider user
interface 702, in which a privacy setting may be set anywhere from
"private" 704 to "public" 706, with other intermediate
settings.
[0048] FIG. 7B is a table illustrating an example of the continuum
of preset privacy settings. Column 754 (corresponding to the
setting 704 in FIG. 7A) has preset privacy settings for "status,"
"IM's," "add requests" and "sharing" that correspond to what is
deemed to be the most private of settings. On the other hand,
column 756 (corresponding to the setting 706 in FIG. 7A) has preset
privacy settings that correspond to what is deemed to be the most
public of settings. Columns 758,760 and 762 have preset privacy
settings that are progressively more public.
[0049] For example, with the settings of column 754, in general, no
one will see when the user is online, and the user will not receive
messages from users outside of those explicitly listed on the
user's messenger list. For column 758, only users explicitly added
to a user's messenger list will see when the user is online. In
addition, the user will be alerted when users not on the user's
messenger list attempt to see when the user is online. The middle
column 760, is a "middle ground," such that users can see when the
user is online, but the other users will not see the user's
enhanced presence indication (e.g., including a status message for
the user). That is, only a basic presence indication is provided to
users not in that user's messenger list.
[0050] The column 762 is such that, in addition to those listed in
the user's messenger list, users listed in those users' messenger
lists ("friends of friends") can also see the user's enhanced
presence indication. Finally, as mentioned above, the column 756
includes preset privacy settings that are the most public, such
that anyone can see when the user is online and, in addition, can
see the user's enhanced presence indication, including a status
message.
[0051] Embodiments of the present invention may be employed to
configure presence indications in a wide variety of computing
contexts. For example, as illustrated in FIG. 4, implementations
are contemplated in which users may interact with a diverse network
environment via any type of computer (e.g., desktop, laptop,
tablet, etc.) 402, media computing platforms 403 (e.g., cable and
satellite set top boxes and digital video recorders), handheld
computing devices (e.g., PDAs) 404, cell phones 406, or any other
type of computing or communication platform.
[0052] According to various embodiments, applications may be
executed locally, remotely or a combination of both. The remote
aspect is illustrated in FIG. 4 by server 408 and data store 410
which, as will be understood, may correspond to multiple
distributed devices and data stores.
[0053] The various aspects of the invention may also be practiced
in a wide variety of network environments (represented by network
412) including, for example, TCP/IP-based networks,
telecommunications networks, wireless networks, etc. In addition,
the computer program instructions with which embodiments of the
invention are implemented may be stored in any type of tangible
computer-readable media, and may be executed according to a variety
of computing models including, for example, on a standalone
computing device, or according to a distributed computing model in
which various of the functionalities described herein may be
effected or employed at different locations.
* * * * *