Account linking

Abstract

Linking multiple identities from a single service includes for a user of a single service having multiple identities within the single service, authenticating a primary identity having a first buddy list associated with an account, authenticating a secondary identity having a second buddy list associated with the account, and creating an association between the primary identity and the secondary identity, where the primary identity and the secondary identity simultaneously share a common graphical user interface such that the primary identity interacts with the first buddy list and the secondary identity interacts with the second buddy list using the common graphical user interface.

Description

TECHNICAL FIELD

This document relates to linking accounts for an instant messaging system.

BACKGROUND

Many people have multiple instant messaging accounts that they use for different identities or personalities. In general, people can only appear online with one account at a time, unless multiple instant messaging clients are run. Therefore, only the buddy list corresponding to the account that was used to sign into the instant messaging system is shown. Similarly, messages can only be sent to and from the account that was used to sign in.

SUMMARY

In one general aspect, linking multiple identities from a single service includes for a user of a single service having multiple identities within the single service, authenticating a primary identity having a first buddy list associated with an account, authenticating a secondary identity having a second buddy list associated with the account, and creating an association between the primary identity and the secondary identity, where the primary identity and the secondary identity simultaneously share a common graphical user interface such that the primary identity interacts with the first buddy list and the secondary identity interacts with the second buddy list using the common graphical user interface.

Implementations may include one or more of the following features. For example, authenticating the primary identity may include using a first password to authenticate the primary identity and authenticating the secondary identity may include using a second password to authenticate the secondary identity. In one implementation, the first password and the second password may be the same. In another implementation, the first password and the second password may be different.

In one implementation, the primary identity and the secondary identity may be authenticated by using a SecureID. The association between the primary identity and the secondary identity may be created by using a one-way link configuration to create the association between the primary identity and the secondary identity. The association between the primary identity and the secondary identity may be created by using a bi-directional-link configuration to create the association between the primary identity and the secondary identity. The association between the primary identity and the secondary identity may be created using a star-link configuration to create the association between the primary identity and the secondary identity. The association between the primary identity and the secondary identity may be created using a mesh-link configuration to create the association between the primary identity and the secondary identity.

The primary identity may be a part of a first domain and the secondary identity may be a part of a second domain that differs from the first domain. Setting preferences for the primary identity also may set the preferences for the secondary identity. First preferences for the primary identity may be set and second preferences may be set for the secondary identity.

The first buddy list and the second buddy list may include one or more common buddies listed on both the first buddy list and the second buddy list.

The single service may enable linking multiple identities within the single service so as to enable presence of one to be reflected based on a login of another of the multiple identities.

In another general aspect, enabling communications by a user having multiple identities includes displaying a common graphical user interface including a list for each of the multiple identities where the list includes other identities with whom the multiple identities are used to communicate. A source identity may be selected from among multiple identities using a common graphical user interface for the identities from which to initiate an electronic communication, where the multiple identities are from a single electronic communication service. A buddy from a list of buddies associated with the source identity may be selected using the common graphical user interface to send the electronic communication. The electronic communication may be sent to the buddy such that the electronic communication is identified to the buddy as being sent from the source identity.

Implementations may include one or more of the following features. For example, the multiple identities may be linked using linking logic based on a remote server. The user may be offered a list of potential identities to which a link from the multiple identities may be created, where the list of potential identities may be created based on relationships between the potential identities and the multiple identities known to exist within the remote server.

A response to the electronic communication may be received from the buddy addressed to the source identity. A first identity that differs from the source identity may be used to log on to a communications system and in response to logging on to the communications system using the first identity, the source identity may automatically be logged on to the communications system.

The multiple linked identities may be displayed in the common graphical user interface. The lists of buddies associated with each of the multiple linked identities may be displayed in the common graphical user interface.

In response to an addition of an identity to the list for one of the multiple identities, the identity may be added to the lists for the other multiple identities.

In another general aspect, a graphical user interface may include one or more window interfaces that are structured and arranged to enable a display portion configured to make perceivable multiple identities for a user, where one or more buddy lists each having one or more buddies are associated with each of the multiple identities, where the multiple identities are from a single electronic communication service. A visual indicator may be configured to display the current logon status of the buddies from the buddy lists of the multiple identities, where at least one buddy from one of the buddy lists associated with a first of the multiple identities is selectable as an intended recipient of an instant message from the user, and where at least one buddy from one of the buddy lists associated with a second of the multiple identities also is selectable as an intended recipient of an instant message from the user.

Implementations may include one or more of the following features. For example, the window interfaces are structured and arranged to enable a display of an instant message addressed to one of the multiple identities. The window interfaces may be structured and arranged to enable sign on of all the identities of the user in response to a sign on of one of the identities. The window interfaces may be structured and arranged to enable sign on of all the identities of the user in response to a sign on of any one of the identities. The window interfaces may be structured and arranged to enable the user to designate preferences for each of the multiple identities. The window interfaces may be structured and arranged to enable the user designate preferences for one of the multiple identities, where the preferences may be applied globally to the other identities of the user.

These general and specific aspects may be implemented using a system, a method, or a computer program, or any combination of systems, methods, and computer programs.

Other features will be apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of a communications system.

FIGS. 2 and 3 are expansions of the block diagram of FIG. 1.

FIGS. 4A-4C, 5A and 11 are illustrations of exemplary interfaces for showing buddy lists for multiple linked instant messaging accounts.

FIG. 5B is an illustration of an exemplary interface for managing multiple linked accounts.

FIGS. 6A-6D are illustrations of an exemplary interface for linking and unlinking accounts.

FIG. 7 is a flow chart of an exemplary process for linking accounts.

FIGS. 8A and 8B are diagrams of exemplary relationships between linked accounts.

FIGS. 9A and 9B are illustrations of exemplary interfaces for signing into an instant messaging system with a linked account.

FIG. 10 is a flow chart of an exemplary process for logging into an instant messaging system.

FIGS. 12A-12D and 13A-13C are illustrations of an exemplary interface for sending communications to and from a linked account.

FIGS. 14A and 14B are flow charts of exemplary processes for communicating from a linked account.

FIG. 15 is a flow chart of an exemplary process for forwarding instant messages to a client.

FIG. 16A is an illustration of an exemplary notification that a specified action has been performed by a buddy of one of the linked accounts.

FIG. 16B is an illustration of an exemplary interface for specifying actions.

Like reference symbols in the various drawings may indicate like elements.

DETAILED DESCRIPTION

A buddy list is a user-definable list of other co-users (i.e., buddies) of an online or network communications systems that enables the user to perceive presence information and changes for the co-users in a unique graphical user interface (GUI) and to track changes to presence status for the co-users in substantially real-time automatically, where presence indicates the status of the co-user with respect to the online or network communications system. The buddy list also provides the user with a mechanism to initiate communications (e.g., instant messages (IMs), electronic mail (e-mail), chat, and other communications) with the co-users. A user may create separate buddy lists of co-users, either with intersecting or disjoint lists of users, and label these buddy lists according to the user's preferences or otherwise.

Each user account may have one or more buddy lists. When a user logs on to a system, the user's set of buddy lists is presented to a buddy list system. The buddy list system attempts to match co-users currently logged into the system with the entries on the user's buddy list. Any matches are displayed to the user. As co-users logon and logoff, a user's buddy list is updated to reflect these changes. An indication also may be added to show that a co-user just logged on or logged off the system.

In one exemplary implementation, a user may link multiple accounts that are held by the user for use in a communications system, such as an instant messaging system. Each of the multiple accounts held by the same user may be identified by a different unique identifier (e.g., a screen name, a number, a user identity, or other alphanumeric string). By logging into one of the linked accounts, the linked accounts all may appear to be logged into the communications system simultaneously. The user can send and receive communications from each linked account all while appearing to other users as the particular identity that the user is known to by others. As a result, the user appears to be online more often and has the potential to receive more communications.

A primary account is chosen by the user to sign in to the communications system. After the primary account is authenticated, a single GUI shows a buddy list, or a list containing the users of the communications system with which communications regularly occur, for the primary account and each of the linked accounts. Thus, by signing onto a single account, the user's other linked accounts also may be started. The GUI may separate the buddy lists for the multiple linked accounts. In one implementation to be described with respect to FIGS. 4A and 4B, only the buddy lists for one of the linked accounts is shown at a time with the buddy lists from other accounts hidden or minimized. In another implementation to be described with respect to FIG. 4C, more than one of the buddy lists from the linked accounts may be simultaneously displayed to the user. The user may make modifications to the buddy list when it is displayed. The GUI also contain an element for accessing a control panel through which the accounts to be linked can be specified. The control panel allows the user to add an account to be linked by enabling the entry of authentication information for the account to be linked.

After authentication, communications to and from the account to be linked may occur. A communication interface enables the specification of a linked account from which the communications are sent to a recipient of the communications. If the communications with the recipient from the selected linked account are allowed to occur, the communications are sent. Also, communications directed to any of the linked accounts may be received and made perceivable to the user. When a message is received, the account to which the message was sent is determined, and the response to the message is configured to automatically send from that account. Notifications of the status of users listed on the buddy lists for the linked accounts are also presented. The notifications specify the account whose buddy list contains the user whose status merited notification.

For illustrative purposes, FIGS. 1-3 show an example of a communications system for implementing techniques for transferring electronic data. For brevity, several elements in the figures described below are represented as monolithic entities. However, as would be understood by one skilled in the art, these elements each may include numerous interconnected computers and components designed to perform a set of specified operations and/or may be dedicated to a particular geographical region.

Referring to FIG. 1, a communications system 100 is capable of delivering and exchanging data between a requestor system 105 and a provider system 110 through a communications link 115. The requestor system 105 may include a client system and the provider system 110 may include a host system. The requestor system 105 typically includes one or more requestor devices 120 and/or requestor controllers 125, and the provider system 110 typically includes one or more provider devices 135 and/or provider controllers 140. For example, the requestor system 105 or the provider system 110 may include one or more general-purpose computers (e.g., personal computers), one or more special-purpose computers (e.g., devices specifically programmed to communicate with each other and/or the requestor system 105 or the provider system 110), or a combination of one or more general-purpose computers and one or more special-purpose computers. The requestor system 105 and the provider system 110 may be arranged to operate within or in concert with one or more other systems, such as, for example, one or more Local Area Networks (“LANs”) and/or one or more Wide Area Networks (“WANs”).

The provider system 110 may include a communication interface such as an electronic mail gateway. For instance, the provider system 110 may include a dedicated mailing system that is implemented by specialized hardware or executed by a general purpose processor capable of running various applications, such as electronic mailer programs, and capable of employing various file transfer protocols, such as the Simple Mail Transfer Protocol (“SMTP”). The communications interface of provider system 110 enables communications between the provider system 110 and other systems through, for example, communications link 115.

The requestor device 120 (or the provider device 135) is generally capable of executing instructions under the command of a requestor controller 125 (or a provider controller 140). The requestor device 120 (or the provider device 135) is connected to the requestor controller 125 (or the provider controller 140) by a wired or wireless data pathway 130 or 145 capable of delivering data.

The requestor device 120, the requestor controller 125, the provider device 135, and the provider controller 140 each typically include one or more hardware components and/or software components. An example of a requestor device 120 or a provider device 135 is a general-purpose computer (e.g., a personal computer) capable of responding to and executing instructions in a defined manner. Other examples include a special-purpose computer, a workstation, a server, a device, a component, other physical or virtual equipment or some combination thereof capable of responding to and executing instructions. The requestor device 120 and the provider device 135 may include devices that are capable of peer-to-peer communications.

An example of a requestor controller 125 or a provider controller 140 is a software application loaded on the requestor device 120 or the provider device 135 for commanding and directing communications enabled by the requestor device 120 or the provider device 135. Other examples include a program, a piece of code, an instruction, a device, a computer, a computer system, or a combination thereof, for independently or collectively instructing the requestor device 120 or the provider device 135 to interact and operate as described. The requestor controller 125 and the provider controller 140 may be embodied permanently or temporarily in any type of machine, component, physical or virtual equipment, storage medium, or propagated signal capable of providing instructions to the requestor device 120 or the provider device 135.

The communications link 115 typically includes a delivery network 160 making a direct or indirect communication between the requestor system 105 and the provider system 110, irrespective of physical separation. Examples of a delivery network 160 include the Internet, the World Wide Web, WANs, LANs, analog or digital wired and wireless telephone networks (e.g., PSTN, ISDN, and xDSL), radio, television, cable, satellite, and/or any other delivery mechanism for carrying data. The communications link 115 may include communication pathways 150 and 155 that enable communications through the one or more delivery networks 160 described above. Each of the communication pathways 150 and 155 may include, for example, a wired, wireless, cable or satellite communication pathway.

An electronic information store 180 may be connected to the provider system 110, included as a component of the provider system 110, and/or connected to the delivery network 160. The electronic information store 180 may be a repository for electronic information that may be in an indexed and/or searchable format. For example, in one implementation, the electronic information store 180 may be used to store information related to the relationships between the linked accounts of the communications system 100.

FIG. 2 illustrates a communications system 200 including a requestor system 205 communicating with a provider system 210 through a communications link 215. Requestor system 205 typically includes one or more requestor devices 220 and one or more requestor controllers 225 for controlling the requestor devices 220. Provider system 210 typically includes one or more provider devices 235 and one or more provider controllers 240 for controlling the provider devices 235. The communications link 215 may include communication pathways 250 and 255 that enable communications through the one or more delivery networks 260.

Examples of each element within the communications system of FIG. 2 are broadly described above with respect to FIG. 1. In particular, the provider system 210 and communications link 215 typically have attributes comparable to those described with respect to the provider system 110 and the communications link 115 of FIG. 1. Likewise, the requestor system 205 of FIG. 2 typically has attributes comparable to and illustrates one possible implementation of the requestor system 105 of FIG. 1.

The requestor device 220 typically includes a general-purpose computer 270 having an internal or external storage 272 for storing data and programs such as an operating system 274 (e.g., DOS, Windows™, Windows 92™, Windows 98™, Windows 2000™, Windows Me™, Windows XP™, Windows NT™, OS/2, or Linux) and one or more application programs. Examples of application programs include authoring applications 276 (e.g., word processing programs, database programs, spreadsheet programs, or graphics programs) capable of generating documents or other electronic content; client applications 278 (e.g., stand alone e-mail client or AOL client, CompuServe client, AIM client, AOL TV client, or ISP client, all of which may include a built-in or embedded e-mail or instant messaging client) capable of communicating with other computer users, accessing various computer resources, and viewing, creating, or otherwise manipulating electronic content; and browser applications 280 (e.g., Netscape's Navigator or Microsoft's Internet Explorer) capable of rendering standard Internet content and also capable of supporting a web-based e-mail client and a web-based instant messaging client.

The general-purpose computer 270 also includes a central processing unit 282 (CPU) for executing instructions in response to commands from the requestor controller 225. In one implementation, the requestor controller 225 includes one or more of the application programs installed on the internal or external storage 272 of the general-purpose computer 270. In another implementation, the requestor controller 225 includes application programs stored in and performed by one or more device(s) external to the general-purpose computer 270.

The general-purpose computer also includes a communication device 284 for sending and receiving data. One example of the communication device 284 is a modem. Other examples include a transceiver, a set-top box, a communication card, a satellite dish, an antenna, or another network adapter capable of transmitting and receiving data over the communications link 215 through a wired or wireless data pathway 250. The general-purpose computer 270 also may include a TV tuner 286 for receiving television programming in the form of broadcast, satellite, and/or cable TV signals. As a result, the requestor device 220 can selectively and/or simultaneously display network content received by communications device 284 and television programming content received by the TV tuner 286.

The general-purpose computer 270 typically includes an input/output interface 288 for wired or wireless connection to various peripheral devices 290. Examples of peripheral devices 290 include, but are not limited to, a mouse 291, a mobile phone 292, a personal digital assistant 293 (PDA), a MP3 player (not shown), a keyboard 294, a display monitor 295 with or without a touch screen input, a TV remote control 296 for receiving information from and rendering information to subscribers, and an audiovisual input device 298.

Although FIG. 2 illustrates devices such as a mobile telephone 292, a PDA 293, and a TV remote control 296 as being peripheral with respect to the general-purpose computer 270, in another implementation, such devices may themselves include the functionality of the general-purpose computer 270 and operate as the requestor device 220. For example, the mobile phone 292 or the PDA 293 may include computing and networking capabilities and function as a requestor device 220 by accessing the delivery network 260 and communicating with the provider system 210. Furthermore, the requestor system 205 may include one, some or all of the components and devices described above.

FIG. 3 illustrates a communications system 300 that includes a requestor system 305 communicating with a provider system 310 through a communications link 315. The communications link 315 may include communications pathways 350 and 355 that enable communications through one or more delivery networks 360. Examples of the elements within the communications system 300 are broadly described above with respect to FIGS. 1 and 2. In particular, the requestor system 305 and the communications link 315 typically have attributes comparable to those described with respect to the requestor system 105 and 205 and the communications links 115 and 215 of FIGS. 1 and 2. Likewise, the provider system 310 of FIG. 3 typically has attributes comparable to and illustrates one possible implementation of the provider system 110 and 210 of FIGS. 1 and 2.

The provider system 310 includes a gateway server 370, an administrative (“admin”) server 372, an authentication server 374, an authentication database 376, an account linking server 378, an account linking database 380, and an instant messaging server 382.

The gateway server 370 communicates with the requestor system 305 over the delivery network 360 through a web server 384 regarding account linking and unlinking actions. In one implementation, the gateway server 370 receives account linking and unlinking requests and forwards them to the admin server 372.

The admin server 372 acts as a clearinghouse for the account linking information management and linked account validation functions. The admin server 372 manages the account linking information and profiles in association with each screen name. The admin server 372 is configured to process requests received from the gateway 370 and saves linking information from successful processes in the account linking database 380 through the account linking server 378. Linking information from unsuccessful processes typically is not stored or saved. The admin server 372 typically is configured to communicate a response message to the requestor system 305 through the gateway server 370, web server 384, and delivery network 360.

The authentication server 374 is configured to process and to validate account authentication requests from the admin server 372 against the authentication database 376 and any partner database system 386. Once accounts have been validated, the admin server may be configured to update that information in the account linking database 389 through the account linking server 378. Accounts may be authenticated and validated on different basis including the presence of a correct account name and password. For validated accounts, account attributes may be forwarded from the authentication database 376 through the authentication server 374 for further use, processing, and/or storage by the admin server 372. For accounts that are not maintained by the provider system 310, the authentication server 374 is configured to communicate the authentication requests to an appropriate partner database system 386 for authentication and validation.

The account linking server 378 interacts with the account linking database 380, which stores and maintains user buddy list and account linking information. The account linking server 378 is configured to manage the information flow to and from the account linking database 380. The type of information contained in the account linking database 380 may include, but is not limited to, users settings of account linking information. The account linking information may be organized in different manners. In one exemplary implementation, the account linking information is organized by screen name. In other implementations, the account linking information may be organized by guide, a unique identifier used in the Open Name Space.

Other types of information contained in the account linking database 380 may include a list of alias screen names linked by a particular screen name, linking attributes associated with each screen name (e.g., timestamp for which an alias account whose password was last changed at the time when the link is created and default visibility/presence preferences), and linking profile information (e.g., revalidation information and a linking account order).

The instant messaging server 382 is configured to process communications sent to and received by users of the communications system. The instant messaging server 382 interacts with the account linking database 380 through the account linking server 378 and also interacts with the admin server 372 to request and receive authentication information using the authentication server 374 and the authentication database 376. Once a user of the requester system 305 has been authenticated and the user's different accounts have been linked and the user has been signed-on to the linked accounts, the user may send and receive communications by interacting with the instant messaging server 382 using the delivery network 360.

An account is needed to use the communications systems 100, 200, and 300. Each account typically has at least one associated screen name. The screen name is the identifier of the account that is authenticated by a client of the communications system. Communications sent throughout the communications system are addressed by the screen names of the intended recipient accounts.

When a first account is linked to a second account, the first account may be called an alias of the second account. In one implementation, either account may be used to sign on to the communications system initially and then any other linked accounts may be signed on to the communications system automatically. In one exemplary implementation, the aliases of a primary account are signed on to the communications system when the main account is signed on to the communications system. The aliases can send and receive communications in the same way as the primary account. Through a single client program and a single, common GUI, communications can be sent substantially simultaneously to and from the primary account and the aliases of the primary account.

Preferences for the each of the accounts may be set on an individual account basis or on a global basis by setting the preferences in one account and applying them globally in other linked accounts. In one exemplary implementation, certain preferences, including away messages and privacy settings, may be set by each of the aliases. All other preferences for the alias accounts may be set to be the same as the preferences for the primary account.

Accounts from multiple communications systems may be linked together. For example, accounts from America Online (AOL), America Online Instant Messenger (AIM), and ICQ may be linked together so that communications may be sent over multiple communications systems using only one client program. In addition, accounts from partner domains may be linked. For example, accounts of an online gaming club may communicate using the AIM communications system, and the accounts from the gaming club may be linked to AIM accounts such that communications may be sent and received by gaming club accounts while not signed into the gaming club on a gaming device. Similarly, accounts from a dating service that uses the AIM communications system may be linked to other accounts such that the members of the dating service can communicate with their dating service accounts while not logged in to the dating service. The architecture described in FIG. 3 is one possible implementation of a communications system, and other implementations for sending communications are possible.

Referring to FIG. 4A, a buddy list interface 400 displays buddy lists for all linked accounts. In one exemplary implementation only one account's buddy lists 402a are shown at a time. The buddy lists 402a includes one or more screen names 404a. For example, the buddy lists 402a include the screen name 404a, BHeikes8. The screen names 404a are used to address communications to and from the specified accounts. The screen names 404a may be separated into one or more groups 406a. The groups 406a are listed with a name, a number of people from the group that are currently logged in to the communications system, and the total number of people in the group. For example, group 406a is named AIM, and seven out of the eleven members of the group are logged in to the communications system.

The buddy list interface 400 includes tabs 408a-408e that can be used to access the buddy lists for the various linked accounts. There is one tab 408a-408e for each of the linked accounts. For example, tab 408a is for an account named AIMUIUser, tab 408b is for an account named AOLMember, tab 408c is for an account named AIMUser, tab 408d is for an account named AIMUser2, and tab 408e is for an account named PersonalsUser@love.com, an account from a partner domain. The buddy lists for an account is displayed when the tab for that account is selected. For example, the buddy list 402a is displayed because the tab 408c for the account named AIMUser has been selected. Referring also to FIG. 4B, selecting the tab 408a for the account named AIMUIUser displays the buddy lists 402b from for that account. The buddy lists 402b includes multiple screen names, including screen name 404b for BerndEw, and groups, including group 406b named Co-Workers, which has two out of six members logged in.

A setup button 410 allows for configuration of the currently displayed buddy list. Selecting the setup button 410 enables the addition and deletion of screen names, such as screen names 404a and 404b, and groups, such as groups 406a and 406b, to the buddy list 402 that is currently displayed. In one implementation, adding a screen name to a buddy list of a linked account causes the screen name to be added to the buddy lists of the other linked accounts. After selecting a screen name 404 from the buddy list, selecting an IM button 412 displays an interface for communicating with the account corresponding to the selected screen name. In one implementation, the user may be given an option to add one or more linked accounts.

Referring to FIG. 4C, an alternative implementation of the buddy list interface 400 displays buddy lists for all linked accounts simultaneously. The buddy list interface 400 includes a buddy list 402a for an account with a screen name AIMUIUser and a buddy list 402b for an account with a screen name AIMUser. The buddy list 402a for the account with the screen name AIMUIUser is displayed first because that account was used to sign in to the communications system. The buddy lists 402a and 402b include one or more screen names 404a and 404b. For example, the buddy list 402a includes the screen name 404a, Alexis101, and the buddy list 402b includes the screen name 404b, Bheikes8. The buddy lists 402a and 402b also may be separated into one or more groups 406a. The groups 406a are listed with a name, a number of people from the group that are currently logged in to the communications system, and the total number of people in the group. For example, group 406a is named Buddies, and two out of the thirteen members of the group are logged in to the communications system, while group 406b is named AIM, and seven out of the eleven members of the group are logged in to the communications system.

A setup button 410 allows for configuration of the displayed buddy lists. Selecting the setup button 410 enables the addition and deletion of screen names, such as screen names 404a and 404b, and groups, such as groups 406a and 406b, to the buddy lists 402a and 402b that are displayed. In one implementation, adding a screen name to a buddy list of a linked account causes the screen name to be added to the buddy lists of the other linked accounts. After selecting a screen name 404 from one of the displayed buddy lists 402a and 402b, selecting an IM button 412 displays an interface for communicating with the account corresponding to the selected screen name.

Referring to FIG. 5A, the buddy list interface 400 includes a menu bar 502 that includes an option 504 labeled “My AIM.” Selecting the option 504 creates a submenu 506. The submenu 506 includes an account linking option 508, labeled “Link Accounts.” Selecting the account linking option 508 displays an account linking control panel 500 from FIG. 5B. The account linking control panel 500 enables the specification of the accounts to be linked as well as various preference settings related to the linked accounts. For example, selecting a linking button 510 enables the specification of the accounts to be linked. For each linked account, multiple preference settings related to account visibility and away message are presented on the account linking control panel 500. Presence information for an invisible account may not be seen by other users of the communications system. Therefore, if a linked account is set to be invisible, then other users of the communications system are unable to see that the account is logged into the system even though the account, and other accounts that are linked to the account, are logged into the system. For example, selecting checkbox 512a will cause the account named LinkedScreenName4 to appear invisible to other users of the communications system. Likewise, selecting checkbox 512b will cause the account named LinkedScreenName5 to appear invisible, and selecting checkbox 514c will cause the account named LinkedScreenName6 to appear invisible.

The account linking control panel 500 also enables the specification of an away message for each of the linked accounts. The away message is displayed when an account is logged into but not actively using the communications system. Each away message has a name for quick reference, as well as text that is displayed to the other users of the communications system. For each linked account, an away message can be chosen and modified using the account linking control panel 500. For example, selection box 514a enables the selection of an away message for the account named LinkedScreenName4. The text of the selected away message appears in a text box 516a, where the text may be modified. Similarly, an away message for the account named LinkedScreenName5 may be selected using the selection box 514b, and the text of the selected away message may be modified in a text box 516b. Finally, an away message for the account named LinkedScreenName6 may be selected using the selection box 514c, and the text of the selected away message may be modified in a text box 516c.

In other implementations, preferences related to outgoing self-expressions, buddy icons, a block list, a warn list, a buddy list, certificates, privacy, and profiles may be set for each linked account suing the account linking control panel 500. In addition, any preference for the screen name used to sign in to the instant messaging system may be set with the account linking control panel 500. Other preferences for each of the linked accounts are determined by the setting of the account used to sign in to the instant messaging system. These preferences include presence, idle time, incoming expression settings, typing indicator, time stamp, and font.

A number of accounts less than the total number of linked accounts may be displayed on the account linking control panel at a time. A back button 518 and a next button 520 enable moving between different subsets of the set of linked accounts such that the preferences for the linked accounts in the various subsets may be specified. Any changes made to the invisibility and away message preferences may be immediately applied to the current session with the communications system using an apply button 522. Similarly, any changes that have been made may be discarded by selecting a cancel button 516524 When all desired changes have been made, the account linking control panel 500 may be closed by selecting a done button 526.

If no accounts have been linked together, then the account linking control panel includes only the linking button 510. The other elements for setting the visibility and away messages for the linked accounts are not presented on the account linking control panel 500.

Referring to FIG. 6A, an account linking interface 600 enables the linking of an account to other linked accounts. The accounts that have been linked together are listed on the account linking interface 600. For example, eight accounts named ScreenName1 through ScreenName8 have been linked using the account linking interface 600. Selecting an add button 602 allows for more accounts to be added to the set of linked accounts.

Next to each account listed in the account linking interface 600 is a checkbox that can be used to select the corresponding account. For example, a checkbox 604a is associated with an account named ScreenName1, a checkbox 604b is associated with an account named ScreenName2, a checkbox 604c is associated with an account named ScreenName3, a checkbox 604d is associated with an account named ScreenName4, a checkbox 604e is associated with an account named ScreenName5, a checkbox 604f is associated with an account named ScreenName6, a checkbox 604g is associated with an account named ScreenName7, and a checkbox 604h is associated with an account named ScreenName8. An unlink button 606 enables the breaking of links from the accounts that have been selected using the checkboxes 604a-604h. For example, selecting the checkbox 604a for the account named ScreenName1 and subsequently selecting the unlink button 606 would break the link between the account named ScreenName1 and the other linked accounts. An optional confirmation may be presented to verify that the selected screen names should be unlinked.

When no accounts have been linked together, only the add button 602 is shown on the account linking interface 600. The list of linked accounts, the checkboxes 604a-604h, and the unlink button 606 are not included in the account linking interface 600.

Referring to FIG. 6B, the account linking interface enables the entry of authentication information for an account after the add button 602 has been selected. The screen name of the account to be linked may be entered in a name text field 608, while the password for the account to be linked may be entered in a password text field 610. After the authentication information has been entered in the name text field 608 and the password text field 610, selecting a save button 612 verifies the entered authentication information and creates a link to the other linked accounts. A cancel button 614 may be selected to dismiss the account linking interface 600 without linking any more accounts. After the cancel button 614 is selected, the list of linked accounts shown in FIG. 6A is presented to the user.

In the event that the entered authentication information is incorrect, a notification will be presented, and the authentication information may be entered again. If additional authentication information, such as a SecureID code, is needed to authenticate the account, a means for entering the additional information is presented.

Referring to FIG. 6C, after successful authentication of the account to be linked and creation of a link between the existing linked accounts and the newly linked account, the user is notified of the number of accounts that still may be linked to the existing set of linked accounts, if such a limit exists. A yes button 616 and a no button 618 enable the user to decide if more accounts are to be linked to the set of linked accounts. If the yes button 616 is selected, the name text field 608 and the password text field 610 are presented again to allow the user to enter authentication information for the additional account to be linked. If the no button 618 is selected, the list of linked accounts is displayed. The yes button 616 and the no button 618 are only presented if the limit on the number of linked accounts has not been reached. If the limit has been reached, then the user is presented with a message saying that the limit has been reached and that no more accounts may be linked. A single confirmation button dismisses the message and displays the list of linked accounts when selected.

Referring to FIG. 6D, in one implementation, the account linking interface 600 may suggest a set of accounts to be linked, thus simplifying the account linking process. The accounts may be suggested based on the structure of the accounts for the communications system. For example, a hierarchy may exist where a set of accounts are subordinate to a master account. In such a case, the account linking interface 600 may suggest that the subordinate accounts be linked to the master account. For example, the account linking interface 600 may suggest that eight accounts named ScreenName1 through ScrenName8 be linked together. Next to each account listed in the account linking interface 600 is a checkbox that can be used to select the corresponding account. For example, a checkbox 620a is associated with an account named ScreenName1, a checkbox 620b is associated with an account named ScreenName2, a checkbox 620c is associated with an account named ScreenName3, a checkbox 620d is associated with an account named ScreenName4, a checkbox 620e is associated with an account named ScreenName5, a checkbox 620f is associated with an account named ScreenName6, a checkbox 620g is associated with an account named ScreenName7, and a checkbox 620h is associated with an account named ScreenName8. A link button 622 enables the creation of links between the accounts that have been selected using the checkboxes 620a-620h and the account for which the account linking interface 600 is displayed. For example, selecting the checkbox 604a for the account named ScreenName1 and subsequently selecting the link button 622 would create a link between the account named ScreenName1 and the account for which the account linking interface 600 is displayed. An optional confirmation may be presented to verify that the selected screen names should be linked. Referring to FIG. 7, a process 700 is used to link multiple accounts such that communications may be sent simultaneously from the linked accounts. The process 700 begins when a main account is used to log into a communications system (702). The account linking control panel is accessed so that other accounts may be linked to the main account used to sign in to the communications system (704). The button on the account linking control panel for linking an account is selected (706), and the authentication information for the account to be linked is entered (708). In one implementation, the authentication information for the account to be linked may be known already by the main account. For example, an account hierarchy may exist where authentication information may be known by a master account for all of the accounts subordinate to the master account. The account to be linked may subordinate to the main account, so the authentication information for the account to be linked may be known already by the main account. In such an implementation, the account information for the account to be linked does not need to be entered. If the authentication information is correct, then the account is linked to the accounts that have been previously linked. If more accounts are to be linked (710), the button for linking an account is selected (706), and the authentication information for the account to be linked is entered (708). In this manner, the authentication information is sequentially entered and verified for all of the accounts to be linked.

After all of the accounts to be linked have been entered (710), a list of linked accounts is presented. If any accounts are to be unlinked from the rest of the linked accounts, then they are selected from the list (712). The unlink button is pressed to break the links between the selected accounts and the other accounts that remain linked (714).

Referring to FIGS. 8A and 8B, seven accounts 802-814 have been linked together using different relationships between pairs of directly linked accounts. The type of relationship used to directly link a pair of accounts determines whether a different pair of accounts may be indirectly linked. For example, a bi-directional link exists between the accounts in FIG. 8A. A bi-directional link is a two-way link such that linking a first account to a second account means that the second account also is linked to the first account. Therefore, two relationships are created with a single link.

Specifically, in FIG. 8A, bi-directional links exist between different accounts, and SN1 is linked to SN2, SN3, SN4, and SN5. Thus, when SN1 is used to sign in to the communications system, SN2, SN3, SN4, and SN5 appear as aliases of SN1. SN2 is linked to SN1 and SN7, which appear as aliases of SN2 when SN2 is used to sign in to the communications system. SN3 is linked to SN1, which appears as an alias of SN3 when SN3 is used to sign in to the communications system. Similarly, SN4 is linked to SN1, which appears as an alias of SN4 when SN4 is used to sign in to the communications system, and SN5 also is linked to SN1, and SN1 appears as an alias of SN5 when SN5 is used to sign in to the communications system. SN6 is linked to SN7, which appears as an alias of SN6 when SN6 is used to sign in to the communications system. Finally, SN7 is linked to SN2 and SN6, which appear as aliases of SN7 when SN7 is used to sign in to the communications system.

In FIG. 8B, one-way linking is used between accounts, so a reflexive relationship does not necessarily exist between two linked accounts. For two accounts to appear linked to one another, each account has to create a link to the other account. Specifically, in the example, SN1 is linked to SN3, SN4, and SN5, which appear as aliases of SN1 when SN1 is used to sign in to the communications system. SN2 is linked to SN1, and SN1 appears as an alias of SN2 when SN2 is used to sign in to the communications system. SN3, SN4, and SN5 are not linked to any other accounts and do not have any aliases. SN6 is linked to SN7, so SN7 appears as an alias of SN6 when SN6 is used to sign in to the communications system. SN7 is linked to SN2, which appears as an alias of SN7 when SN7 is used to sign in to the communications system.

The description provided above with respect to FIGS. 8A and 8B is premised on the accounts 802-814 being linked using a star linking scheme, which dictates that a direct link must exist between two accounts before the accounts are linked. On the other hand, two accounts may appear to be linked even though a direct link between the two accounts does not exist. This linking scheme, called mesh linking, calls two accounts linked if there is an indirect link between the two accounts. For example, in FIG. 8B, SN2 and SN4 may be called linked under a mesh linking scheme because they are indirectly linked through SN1. In general, two accounts may be called linked in a mesh-linking scheme if there exists a path of linked accounts between the two accounts.

Referring to FIG. 9A, a sign in interface 900 allows the user to enter the authentication information needed to log in to the communications system with a primary account. The screen name of the primary account may be selected from a selection box 902. Alternatively or additionally, the screen name of the primary account may be typed in the selection box 902. The password for the primary account may be entered in the text box 904. If the checkbox 906 is selected, then the password for the account listed in the selection box 902 is automatically entered in the text box 904 from memory. Selecting a checkbox 908 will cause the primary account to appear as invisible, which prevents other users of the communications system from detecting the presence of the primary account even though the primary account is logged in to the communications system. After the necessary authentication information has been entered, a sign on button 910 is selected. After selecting the sign on button 910, the authentication information entered on the sign on interface 900 is verified. If additional authentication information, such as a SecureID code, is needed, a means for entering the additional information is presented. If the information is successfully verified, then the buddy list interface 400 is shown for the primary account and all of the linked accounts.

Referring to FIG. 9B, a dialog box 912 may be presented after verification of the authentication information and before the buddy list interface 400 is displayed. The dialog box 912 informs the user that a link to an alias account has been broken because the password for the alias account has changed. The option to relink the alias account to the primary account is given. A relink button 914 is enables the reestablishment of the link. Selecting the relink button 914 displays the account linking interface 600, and the new password for the alias account may be entered. After successful authentication of the new password, the link between the primary account and the alias account is reestablished, and the dialog box 912 is dismissed. In one implementation, the user may be presented with a separate form or a text box within dialog box 912 to enter a new password for revalidation of a broken link.

A cancel button 916 dismisses the dialog box 912 without reestablishing the broken link. The link between the primary account and the alias account remains broken. A dialog box 912 may be presented for each link from the primary account to an alias account that has been broken. After all of the broken links have been reestablished or dismissed, and the buddy list interface 400 is presented.

In another implementation, the link between the primary account and the alias account may be maintained despite a change in the password for the alias account. In such an implementation, the dialog box 912 is not presented, and the link to the alias account does not need to be reestablished.

Links between accounts also may be broken manually. From the perspective of a single user with multiple linked accounts, the user may break any link between the linked accounts regardless of the linked account used to sign in to the communications system and regardless of whether the link is bi-directional. Authentication information for the accounts connected by the link to be broken may be entered in order to authorize the destruction of the link. Similarly, from the perspective of multiple users with multiple linked accounts, a link between an account to which the link extends and an account from which the link extends may be broken by the user corresponding to the account to which the link extends. A notification may be sent to the account from which the link extends, and the permission of the account from which the link extends may be required for destruction of the link.

Referring to FIG. 10, a process 1000 is used to sign in to a communications system with multiple linked accounts. The process 1000 begins when authentication information for a primary account for signing in to the communications system is entered and verified (1002). The visibility of the primary account is checked (1004). If the primary account is to be visible, then the presence of the primary account is announced to the other accounts that currently are logged in to the communications system (1006). If broken links from the primary account are detected, then the links may be repaired to reestablish a connection between the primary account and an alias account (1008).

Next, a set of accounts that are linked to the primary account, including those accounts that had a broken link repaired, is accessed (1010). One of the linked accounts from the set of linked accounts is chosen (1012). The chosen linked account is authenticated based on authentication information stored with respect to the primary account (1014). After authentication, the visibility of the linked account is checked (1016). If the linked account is to appear visible, then the presence of the linked account is announced to the other accounts that currently are logged in to the communications system (1018).

A determination is made as to whether more accounts to be linked exist in the set of linked accounts (1020). If more accounts do exist, a linked account is chosen (1012), the linked account is authenticated (1014), the visibility of the linked account is checked (1016), and the presence of the linked account is announced if the linked account is to be visible (1018). In this manner, the accounts that are linked to the primary account are signed in to the communications system sequentially. Once all of the linked accounts have been signed in to the communications system (1020), a buddy list interface displaying the buddy lists for the primary account and the linked accounts is displayed (1022). Communication can then occur using the primary account and the linked accounts.

Referring to FIG. 11, a buddy list interface 400a has been displayed for a user of a communications system with linked accounts. The user has two linked accounts, one with a screen name of AIMUIUser, and one with a screen name of AIMUser. The buddy list interface 400a includes a buddy list 402a for the account with screen name AIMUIUser and a buddy list 402b for the account with the screen name AIMUser. The buddy list 402a is displayed first because the screen name AIMUIUser was used to sign in to the communications system. In addition, two other users, a user with a screen name OtherUser1 and a user with a screen name OtherUser2 are logged in to the communications system, and the corresponding buddy list interfaces 400b and 400c, respectively, are displayed. OtherUser1 and OtherUser2 do not maintain any linked accounts, so the buddy list interfaces 400b and 400c each only display a single buddy list 402c and 402d, respectively. The buddy list 402c for OtherUser1 includes the screen name AIMUIUser, which indicates that the account with the screen name AIMUIUser is logged in to the communications system. The buddy list 402d for OtherUser2 includes the screen name AIMUser, which indicates that the account with the screen name AIMUser is logged in to the communications system. Even though the account with the screen name AIMUser did not directly log in to the communications system, the account is still shown as logged in because the account is linked to the account with the screen name AIMUIUser, which was used to log in to the communications system.

Referring to FIG. 12A, communications may be sent to and from the linked accounts using a communications interface 1200. The communications interface 1200 includes a recipient indicator 1202 that indicates a recipient of the messages sent with the communications interface 1200 and a sender indicator 1204 that indicates a sender of the messages sent with the communications interface 1200. For example, the communications interface 1200 is used to send communications from the screen name OtherUser1 to the screen name AIMUIUser. The communications interface 1200 is seen by the user with the screen name OtherUser1 as the user sends messages to the screen name AIMUIUser. The screen name OtherUser1 may send messages to the screen name AIMUIUser after seeing the screen name AIMUIUser on the buddy list interface 400b from FIG. 11. The screen name AIMUIUser appeared on the buddy list interface 400b from FIG. 11 because the account with the screen name AIMUIUser logged directly in to the communications system.

A message transcript text box 1206 displays the text of the messages sent between the sender and the recipient. Further messages may be specified in a message text box 1208. Once specified in the message text box 1208, the message may be sent by selecting a send button 1210.

Referring to FIG. 12B, a different communications interface 1200 is displayed for the user with the screen name AIMUIUser after a message is sent from the user with the screen name OtherUser1. The communications interface 1200 is used by the user with the screen name AIMUIUser to send a response to the user with the screen name OtherUser1. The recipient indicator 1202 indicates that the screen name OtherUser1 is the recipient of messages sent with the communications interface 1200. Similarly, the sender indicator 1204 indicates that the screen name AIMUIUser is the sender of messages sent with the communications interface 1200. A message transcript text box 1206 displays the text of the messages sent between the sender and the recipient, including the original message sent from the screen name OtherUser1 to the screen name AIMUIUser. Further messages may be specified in a message text box 1208. Once specified in the message text box 1208, the message may be sent by selecting a send button 1210. Messages may be sent from the account with the screen name AIMUIUser because the account with the screen name AIMUIUser was used to log directly in to the communications system.

Referring to FIG. 12C, a communications interface 1200 may be displayed for the user with a screen name OtherUser2. The communications interface 1200 is used to send communications from the screen name OtherUser2 to the screen name AIMUser. The communications interface 1200 is seen by the user with the screen name OtherUser2 as the user sends messages to the screen name AIMUser. The screen name OtherUser2 may send messages to the screen name AIMUser after seeing the screen name AIMUser on the buddy list interface 400c from FIG. 11. The screen name AIMUser appeared on the buddy list interface 400c from FIG. 11 because the account with the screen name AIMUser is linked to the account with the screen name AIMUIUser, which was used to log directly in to the communications system.

A message transcript text box 1206 displays the text of the messages sent between the sender and the recipient. Further messages may be specified in a message text box 1208. Once specified in the message text box 1208, the message may be sent by selecting a send button 1210.

Referring to FIG. 12D, a different communications interface 1200 is displayed for the user with the screen name AIMUser after a message is sent from the user with the screen name OtherUser2. The user with the screen name AIMUser is the same as the user with the screen name AIMUIUser because the corresponding accounts are linked. The communications interface 1200 is used by the user with the screen name AIMUIUser or AIMUser to send a response to the user with the screen name OtherUser2. The recipient indicator 1202 indicates that the screen name OtherUser2 is the recipient of messages sent with the communications interface 1200. Similarly, the sender indicator 1204 indicates that the screen name AIMUser is the sender of messages sent with the communications interface 1200. A message transcript text box 1206 displays the text of the messages sent between the sender and the recipient, including the original message sent from the screen name OtherUser2 to the screen name AIMUser. Further messages may be specified in a message text box 1208. Once specified in the message text box 1208, the message may be sent by selecting a send button 1210. Messages may be sent from the account with the screen name AIMUser because the account with the screen name AIMUser is linked to the account with the screen name AIMUIUser, which was used to log directly in to the communications system. Furthermore, the user with the screen names AIMUIUser and AIMUser may transparently send messages using the communications interface 1200 from two linked accounts simultaneously.

Referring to FIG. 13A, a communication interface 1200 has a different appearance before a first message is sent. The communication interface 1200 includes a sender selection box 1302 in which the account that the communication is sent from is specified. All communications sent using the communication interface 1200 appear to be from the account selected in the sender selection box 1302. For example, the account with the screen name AIMUIUser has been selected as the sender of the communication, and all communications will appear to be from that account. The screen names of all the linked accounts are presented in and may be selected from the sender selection box 1302. An expanded sender selection box 1304 includes the names of all of the linked accounts from which the communication interface 1200 may be sent. The expanded sender selection box 1304 may be displayed below the sender selection box 1302 when the arrow on the right side of the sender selection box 1302 is selected. The expanded sender selection box 1304 also may be displayed below the sender selection box 1302 when attempting to scroll through the selections included in the sender selection box 1304.

The recipient of the communication is specified using the recipient selection box 1306. For example, the account with the screen name AIMBuddy has been selected as the recipient of the communication. The screen names of possible recipient accounts are presented in and may be selected from the recipient selection box 1306. The screen name of the recipient also may be typed in the recipient selection box 1306. An expanded recipient selection box 1308 includes the names of possible recipients of messages sent using the communication interface 1200. The expanded recipient selection box 1308 may be pre-populated with the names included in a buddy list for the sender selected in the sender selection box 1302. The expanded recipient selection box 1308 may be displayed below the recipient selection box 1306 when the arrow on the right side of the recipient selection box 1306 is selected. The expanded recipient selection box 1308 also may be displayed below the recipient selection box 1306 when attempting to scroll through the selections included in the recipient selection box 1306. In one implementation, as the sender is changed in the sender selection box 1302, the names of possible recipients of messages are changed to correspond to the newly selected sender's buddy list.

Alternatively or additionally, a recipient for the message may be chosen from the buddy list interface 400. In this case, the screen name for the recipient may be entered automatically entered in the recipient selection box 1306, and the screen name of the account whose buddy list the recipient was chosen from may be automatically entered in the sender selection box 1302.

The message to be sent is typed into the message text box 1208. After specification of the sender with the sender selection box 1302, the recipient with recipient selection box 1306, and the message in the message text box 1208, a send button 1210 is used to send the message from the sender to the recipient.

Referring to FIG. 13B, the appearance of the communication interface 1200 changes after the send button 1210 is pressed for the first time. In one exemplary implementation, once the sender and recipient accounts have been specified and one message has been sent from the sender to the recipient, the sender and recipient accounts may not be changed.

Therefore, the sender selection box 1302 and the recipient selection box 1304 are removed from the communication interface 1200. A recipient indicator 1202 indicates the recipient chosen in the recipient selection box 1304, and a sender indicator 1204 indicates the recipient chosen in the sender selection box 1302. A transcript text box 1206 replaces the sender selection box 1302 and the recipient selection box 1304. The transcript text box 1206 includes the text of each message that has been sent between the sender and recipient accounts using the communication interface 1200, as well as an indication of whether the sender account or the recipient account sent the message.

A new message to be sent may be entered in the message text box 1208, and the message may be sent to the specified recipient by selecting the send button 1210. In addition, the recipient may be added to the sender's buddy list by selecting an add buddy button 1310.

Referring to FIG. 13C, before messages are delivered to the chosen recipient account from a chosen sender account, a determination is made as to whether the sender and recipient accounts are allowed to send messages to each other. If not, then the message that was specified in the message text box 1208 is not delivered to the recipient after the send button 1210 was selected. Instead a message from the communications system appears in the transcript text box 1206 informing the user that communication between the selected sender and recipient accounts may not occur. In addition, the recipient indicator 1202 indicates the communication was intercepted by the communications system, but the sender indicator 1204 still indicates the recipient chosen in the sender selection box 1302.

Communication between two accounts may be denied if the accounts do not belong to the same domain. For example, if the recipient belongs to a gaming club, but the sender does not, then the sender may not be allowed to send messages to the recipient. In general, communication may be denied if the sender does not have permission to send messages to the recipient or if the recipient denies a request to communicate with the sender.

Referring to FIG. 14A, a process 1400 is used by a sender to initiate communications with a recipient. The process 1400 begins when the sender chooses one of the accounts linked to the account used to sign in to the communications system to communicate from (1402). Next, the recipient of the communications is chosen (1404). The compatibility of the chosen sender and recipient accounts is checked to verify that communication between the sender and the recipient is allowed to occur (1406). If so, the sender account is free to send communications to the recipient (1408).

Referring to FIG. 14B, a process 1450 is used to respond to a message received from a user of the communications system. The process 1450 begins when a message is received from a user of the communication system by a client program that is running for multiple linked accounts (1452). The intended recipient of the message is determined (1454). The intended recipient is one of the linked accounts for which the client program is running. A response to the original message is sent from the linked account to which the original message was addressed (1456). The determination of the intended recipient account of the original message is automatic. Should a response to the original message be sent, it will automatically appear to be from the account to which the original message was sent.

Referring to FIG. 15, a process 1500 is used to forward messages to locations where recipients are available to receive them. Because accounts may be linked, the same account may be signed in to the communications system at multiple physical locations. A message is sent to every location where a recipient of the message is signed in to the communications system and may be replied to at any of the locations where the recipient account is signed in to the communications system. If an away message is up, the message is forwarded to the next location that does not have an away message up, where the locations are ordered based on the time of sign in. If away messages are up at all locations where the recipient account is signed in, the message is held at the location where the recipient account first signed in to the communications system.

The process 1500 begins when a message is received by the communications system (1502). A set of locations at which a recipient of the message is signed in to the communications system is identified (1504). The locations are the places where the message may be received by the recipient. The message is sent to one of the set of identified locations (1506). A determination is made as to whether the location is available to receive the message (1508). In other words, a determination is made as to whether the location has an away message displayed. If the location is available to receive the message because it does not have an away message displayed, then the message is left at the location (1510). If the location is unable to receive the message because an away message is up, then it is determined if there is another location that may be available to receive the message (1512). If there are no other locations that may receive the message, then the message is held at the location where the recipient first signed in to the communications system (1514). Otherwise, the message is forwarded to the next location in the set of locations, based on the sign in time of the recipient (1516). A determination is made again as to whether the location may receive the message (1512). If so, the message is held at the location (1514). Otherwise it is forwarded to another location if one exists. In this manner a message may be passed between all of the locations where the recipient is signed in to the communications system so that the recipient can receive and respond to the message.

For example, consider again the linking scenario of FIG. 8A. Imagine that SN1 was used to sign in at a first location and that SN2 was used later to sign in at a second location. SN1 is linked to SN2, SN3, SN4, and SN5, so messages for SN1, SN2, SN3, SN4, and SN5 may be received at the first location. SN2 is linked to SN1 and SN7, so messages for SN1, SN2, and SN7 may be received at the second location. If the first location has an away message up and the second location does not have an away message up, then messages sent to SN1 and SN2 are forwarded to the second location. If the second location has an away message up, messages for SN1 and SN2 are forwarded to the first location, while messages for SN7 are held at the second location, the only place where SN7 is signed in. If both locations are have away messages displayed, then the messages for SN1 and SN2 are held at the first location, where SN1 and SN2 first signed in, and messages for SN7 are held at the second location, where SN7 first signed in.

Referring to FIG. 16A, a notification 1600 is presented after one of a specified series of events relating to the accounts listed on the buddy lists of a set of linked accounts. The header 1602 of the notification 1600 contains screen name of the linked account whose buddy list contains the account that triggered the notification. The body 1604 of the notification contains the screen name of the account that triggered the notification as well as a description of the event that triggered the notification.

Certain actions by the accounts listed in the buddy lists for the linked accounts may cause a notification 1600 to appear. The actions include signing on to the communications system, signing off of the communications system, going away from the communications system by putting up an away message, returning from away, going idle by not using the communications system for a specified amount of time, and returning from idle. Which actions cause a notification to appear, if notifications are to appear at all, may be set in the preferences control panel 1650 of FIG. 16B. The section of the preferences control panel 1650 that governs when notifications 1600 are displayed may be accessed by selecting the notifications option 1652 in the list of preference categories. The notifications section of the preferences control panel 1650 includes a checkbox 1654 for selecting whether notifications 1600 should be displayed. Selecting the checkbox 1654 causes notifications 1600 to appear when they are triggered.

A series of options 1656-1666 govern which actions lead to the display of notifications 1600. For example, selecting option 1656 will cause notifications to appear when accounts on the buddy lists for the linked accounts sign on to the communications system. Similarly, selecting option 1658 causes notification to appear when accounts on the buddy lists sign off of the communications system. Option 1660 causes notifications 1600 to appear when accounts go away, and option 1662 causes notifications 1600 to appear when accounts return from away. Finally, option 1664 causes notifications 1600 to appear when accounts go idle, and option 1666 causes notifications 1600 to appear when accounts return from idle.

Any changes made to the preferences control panel 1650, including changes to the notifications settings, may be saved with an accept button 1668. Selecting the accept button 1668 closes the preferences control panel 1650 and applies the changes made to the preferences control panel. On the other hand, a cancel button 1670 may dismiss the preferences control panel 1650 without making any of the changes to the settings that govern when notifications 1600 are shown.

The described systems, methods, and techniques may be implemented in digital electronic circuitry, computer hardware, firmware, software, or in combinations of these elements. Apparatus embodying these techniques may include appropriate input and output devices, a computer processor, and a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor. A process embodying these techniques may be performed by a programmable processor executing a program of instructions to perform desired functions by operating on input data and generating appropriate output. The techniques may be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and Compact Disc Read-Only Memory (CD-ROM). Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits).

It will be understood that various modifications may be made without departing from the spirit and scope of the claims. For example, advantageous results still could be achieved if steps of the disclosed techniques were performed in a different order and/or if components in the disclosed systems were combined in a different manner and/or replaced or supplemented by other components. As another example, a screen name is used throughout to represent a unique identifier of an account, but any other unique identifier of an account may be used when linking accounts. Accordingly, other implementations are within the scope of the following claims.

Claims

1. A method comprising: receiving, from a user, login information to a communications service for a first account of the user;in response to receiving the login information to the communications service for the first account of the user, and using at least one processor, logging the user in to the first account and a second account of the user using only the received login information for the first account, wherein the second account differs from the first account;using a graphical user interface to enable selection, by the user from among the first account and the second account, of a particular source account from which to initiate an electronic communication;sending, the electronic communication to a second user; andidentifying the electronic communication sent to the second user as having been sent from the particular source account selected by the user.

2. The method as in claim 1, wherein the first account and the second account of the user are linked using linking logic based on a remote server.

3. The method as in claim 2, further comprising offering the user a list of potential accounts to which a link from the first account may be created, wherein the list of potential accounts is created based on relationships between the potential accounts and the first account known to exist within the remote server.

4. The method as in claim 1, further comprising receiving a response to the electronic communication and addressed to the particular source account.

5. The method as in claim 1, further comprising displaying indications of the first account and the second account of the user in the graphical user interface.

6. The method as in claim 5, further comprising displaying lists of screen names associated with each of the first account and the second account of the user in the graphical user interface.

7. The method as in claim 1, further comprising, responsive to an addition of a new screen name to the list for the first account of the user, adding the new screen name to the second account of the user.

8. The method as in claim 1, further comprising displaying a single graphical user interface configured to accommodate multiple lists of screen names with whom the user communicates electronically, wherein the single graphical user interface is configured to: enable the user to select a particular list corresponding to one of the first account or the second account of the user; andin response to a selection by the user of the particular list, display the particular list that corresponds to the account selected by the user.

9. The method as in claim 8, wherein displaying the single graphical user interface configured to accommodate multiple lists of screen names corresponding to users with whom the user communicates electronically comprises concurrently displaying lists corresponding to each of the first account and the second account of the user.

10. A graphical user interface comprising: one or more window interfaces that are structured and arranged, using at least one processor, to enable: a sign on of a secondary account of a user in response to a sign on of a primary account of the user, the sign on of the secondary account of the user using only login information for the primary account of the user;a display portion configured to make perceivable the primary account of the user and the secondary account of the user;one or more visual indicators that are configured to display the current logon status of other users associated with the primary and secondary accounts of the user; andwherein at least a first user associated with the primary account of the user and represented by a first screen name is selectable as an intended recipient of a message from the user, andwherein at least a second user associated with the secondary account of the user and represented by a second screen name is selectable as an intended recipient of a message from the user.

11. The graphical user interface of claim 10, wherein the window interfaces are structured and arranged to enable the user to designate preferences for each of the primary account and the secondary account of the user.

12. The graphical user interface of claim 10, wherein the window interfaces are structured and arranged to enable the user to designate preferences for the primary account of the user, wherein the preferences are applied to the secondary account of the user.

13. A method comprising: maintaining, for a user who has multiple accounts that are hosted by a single communications service provider for use in communicating electronically with other users, a first contacts list corresponding to a first account of the user, the first contacts list including screen names that each represent another account hosted by the single communications service provider and correspond to another user, and the first contacts list enabling the user to communicate electronically with the other users corresponding to the screen names included within the first contacts list;maintaining, for the user, a second contacts list corresponding to a second account of the user, the second contacts list being separate from the first contacts list and including additional screen names that each represent an additional account hosted by the single communications service provider and correspond to an additional user, and the second contacts list enabling the user to communicate electronically with the additional users corresponding to the additional screen names included within the second contacts list, wherein a particular screen name representing a particular account hosted by the single communications service provider and corresponding a particular user is listed in both the first contacts list corresponding to the first account of the user and the second contacts list corresponding to the second account of the user;receiving, from the user, login information to the single communications service for the first account of the user;in response to receiving the login information to the single communications service for the first account of the user, using at least one processor, logging the user in to the first account and the second account of the user using only the received login information for the first account, wherein the second account differs from the first account; andcreating an association between the first account of the user and the second account of the user, wherein the association between the first account of the user and the second account of the user triggers display of a single graphical user interface for both the first account of the user and the second account of the user in response to authentication of both the first account of the user and the second account of the user, the single graphical user interface being configured to display the first contacts list corresponding to the first account of the user separately from the second contacts list corresponding to the second account of the user such that: the first contacts list includes a contiguous listing of the screen names representing the other accounts hosted by the single communications service provider and corresponding to the other users and the second contacts list includes a contiguous listing of the screen names representing the additional accounts hosted by the single communications service provider and corresponding to the additional users, andthe single graphical user interface enables the user to interact with the first contacts list to communicate with the other users using the first account of the user and to interact with the second contacts list to communicate with the additional users using the second account of the user.

14. The method as in claim 13, wherein receiving login information for the first account comprises receiving a first password to log in to the first account.

15. The method as in claim 13, wherein receiving login information for the first account comprises receiving a SecureID to log in to the first account.

16. The method as in claim 13, wherein creating the association between the first account and the second account comprises using a one-way link configuration to create the association between the first account and the second account.

17. The method as in claim 13, wherein creating the association between the first account and the second account comprises using a bi-directional-link configuration to create the association between the first account and the second account.

18. The method as in claim 13, wherein creating the association between the first account and the second account comprises using a star-link configuration to create the association between the first account and the second account.

19. The method as in claim 13, wherein creating the association between the first account and the second account comprises using a mesh-link configuration to create the association between the first account and the second account.

20. The method as in claim 13, further comprising setting preferences for the first account, wherein setting the preferences for the first account also sets the preferences for the second account.

21. The method as in claim 13, further comprising: setting first preferences for the first account; andsetting second preferences for the second account.

22. The method as in claim 13, wherein the single communications service enables linking multiple accounts hosted by the single communications service so as to enable presence of one account to be reflected based on a login of another account of the multiple accounts.

23. A method comprising: receiving, from a user, login information to a service provider for a first account of the user;in response to receiving the login information for the first account of the user, logging the user in to the first account and a second account of the user using only the received login information for the first account, wherein the second account differs from the first account;displaying, using at least one processor, to the user a graphical user interface that comprises: a first contacts list that corresponds to the first account of the user and that comprises a first contiguous listing of screen names, each of the screen names included in the first contiguous listing representing, an account also hosted by the service provider, anda second contacts list that is separated from the first contacts list, that corresponds to the second account of the user, and that comprises a second contiguous listing of screen names, each of the screen names included in the second contiguous listing representing an account also hosted by the service provider;receiving an indication of a selection by the user from within the graphical user interface of a particular screen name from the first contacts list;in response to receiving the indication of the selection of the particular screen name from the first contacts list, enabling the user to compose a first electronic communication to the particular screen name; andbased on the selection of the particular screen name from the first contacts list that corresponds to the first account of the user, sending the first electronic communication composed by the user to the particular screen name in a manner that identifies the first electronic communication as having been sent from the first account.

24. The method of claim 23, further comprising collapsing the first contacts list within the graphical user interface such that the contiguous listing of the screen names is not visible within the graphical user interface after collapsing the first contacts list.

25. The method of claim 23, wherein displaying the graphical user interface that comprises both the first contacts list and the second contacts list comprises concurrently displaying both the contiguous listing of the screen names associated with the first contacts list and the contiguous listing of the screen names associated with the second instant messaging contacts list within the graphical user interface on a single display screen.