TECHNICAL FIELDThis document describes systems and techniques for correlating and retrieving user contact identifiers with a handle.
BACKGROUNDThe development of modern communications technologies has enabled people to communicate by more and richer mechanisms—via e-mail, text messaging, video conferencing, posting content to web pages, microblogging, and other such expanding mechanisms. This increase in communication mechanisms, however, brings about a concomitant increase in the complexity of determining someone's contact information. For example, a particular internet user may have a home telephone number, a cellular telephone number, a work telephone number, a work e-mail address, a personal e-mail address, a home page, a blog, an IM account, and other such mechanisms for communicating with others. This multitude of connection mechanisms can make it difficult to keep track of contact information for a number of friends or acquaintances. Also, it can be hard to get and enter all such information from a new acquaintance. That is why, frequently, people tell a new acquaintance to call their telephone number or e-mail them, so that they can capture, respectively, the other user's telephone number or e-mail address.
Such difficulties become even more pronounced across a user's lifetime as they move from situation to situation. For example, each time a user changes jobs, they generally lose their old work telephone number and e-mail address and acquire new ones. This may result in a business social networking site “pinging” all of their acquaintances to announce that the acquaintances should check for the new contact information. It may also result in acquaintances who are not updated in such a manner getting a wrong number or an e-mail bounce-back when they try to reach an old acquaintance.
SUMMARYThis document describes techniques for correlating and retrieving a handle with contact identifiers. In general, a user may be contacted using a single handle that triggers communication by a variety of different communication mechanisms using a plurality of communication modes, where modes are different types of communication connections such as telephone, e-mail, text messaging, and other such modes. For example, a single alphanumeric string can be submitted by a party wanting to contact the user, whether the party wants to make the contact via telephone, e-mail, chat or other such mode of communication. Thus, for example, a third party can “dial” the handle using a telephone and the handle will lead to a service that translates the handle into another telephone number where the user can currently be reached. In a similar manner, a third party can use the handle plus a common domain (e.g., gmail.com) to e-mail the user, and the e-mail message can be forwarded, using rules defined by the user, to another e-mail account or address for the user. The handle can also be used to push updates regarding various contact mechanisms out to the third party when a user changes such information, such as by sending a new vcf card to the third party.
Such systems and techniques may provide one or more advantages in certain implementations. For example, a user can provide a single point of contact to which acquaintances may point in order to be updated regarding contact information for various contact mechanisms for the user. Also, the acquaintance may be permitted to generally ignore changes in individual contact mechanisms, such as when the user switches to a new job and receives a new work telephone number and new work e-mail address, and simply remember a handle for their acquaintance, where the handle does not need to change every time one of the contact mechanisms that underlies the handle changes. Rather, the handle, by whatever mode submitted, may be mapped to the various communication modes and contact mechanisms (such as e-mail addresses and telephone numbers) for a user, so that the user can keep those mechanisms updated without bothering the user's acquaintances. In addition, the user may establish various routing rules to control how the user is contacting, and via which contact mechanism, where such rules may depend at least in part on the time of day or day of the week when the contact is made, the identity of the person seeking to make contact, and other similar factors that may affect a user's decisions regarding how to be contacted.
In a first general aspect, a computer-implemented method is described. The method includes obtaining, at a computer system, a plurality of different contact identifiers for a computer account holder, wherein the identifiers represent a plurality of different communication modes; identifying a handle for the account holder, wherein the handle is associated with a uniform resource locator; and correlating the handle with the plurality of contact identifiers, and storing the handle and plurality of contact identifiers together so as to permit retrieval of the contact identifiers in response to identification of the handle.
In a second general aspect, a computer-implemented communication management method is described. The method includes receiving at a computer system a handle for an account holder submitted by a computing device; providing, for presentation to the computing device, a group of contact identifiers from a plurality of different communication modes; and electronically connecting the computing device to the account holder by one of the plurality of communication modes in response to a selection by the computing device of a contact identifier corresponding to the one of the plurality of communication modes.
In a third general aspect, a computer-implemented communication system for identifying contact identifiers for an account holder is described. The computer-implemented communication system includes an interface to obtain a plurality of different contact identifiers for a computer account holder, wherein the identifiers represent a plurality of different communication modes; an account manager to identify a handle for the account holder, wherein the handle is associated with a uniform resource locator; and a correlator to correlate the handle with the plurality of contact identifiers, and store the handle, the plurality of contact identifiers together so as to permit retrieval of the contact identifiers in response to identification of the handle.
In a fourth general aspect, a computer implemented communication system for assisting in forming communication sessions is described. The computer implemented communication system includes an interface to receive a handle from a user of a computing device, wherein the handle is associated with a uniform resource locator; a central database associating a group of contact identifiers for an account holder to the uniform resource locator; and a communication mode selector to receive a mode indicator and one or more contact identifiers from the database and to select the contact identifier using a communication mode corresponding to the mode indicator to connect a third party for communication with the account holder.
In a fifth general aspect, a computer implemented communication management method is described. The method includes electronically providing a user account handle; retrieving a plurality of contact identifiers correlated with the user account handle; displaying the plurality of contact identifiers, each contact identifier being different from another contact identifier and associated with a contact rule; and receiving, at a computing device, at least one modification of one of the contact identifiers.
The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.
DESCRIPTION OF DRAWINGSFIG. 1 is a conceptual diagram of a system for retrieving a user's various contact identifiers correlated to a handle.
FIG. 2A is a schematic diagram of a system for retrieving a user's various contact identifiers correlated to a handle.
FIG. 2B is a sequence diagram depicting examples of interactions between clients and servers.
FIG. 3 is a schematic diagram of a system for correlating a handle with contact identifiers.
FIG. 4A is a flowchart showing actions taken to correlate a handle with contact identifiers.
FIG. 4B is a flowchart showing actions taken to retrieve a user's contact identifiers correlated with a handle.
FIG. 5A is a sequence diagram for generating a user account to correlate a handle with a user's contact identifiers.
FIG. 5B is a sequence diagram for retrieving a user's contact identifiers correlated with a handle.
FIG. 6A is an exemplary universal business card.
FIG. 6B is a screenshot of a web page for retrieving a user's contact identifiers correlated with a handle.
FIG. 6C is a screenshot of a web page for correlating a handle with contact identifiers
FIG. 6D is a screenshot of a web page displaying a user's contact identifiers correlated with a handle.
FIG. 7 shows an example of a computer device and a mobile computer device that can be used to implement the techniques described here.
Like reference symbols in the various drawings indicate like elements.
DETAILED DESCRIPTIONIn general, this document describes mechanisms for providing a single point of contact for a user so that third parties may contact the user through various forms of communication without having to use more than the single point of contact. Contact information for the single point of contact may be supplied to third parties who are acquaintances of the user, in one example, through a website that the third parties may visit. The contact information may be tailored to individual third parties or groups, e.g., family may obtain one set of contact information, friends another set, and work contacts a third set of contact information (where the various sets may overlap). The user may also update a particular contact identifier, for example, a work phone number, without needing to update customers, vendors, or co-workers of the contact information change, because the single point of contact may stay fixed while the various contact mechanisms that are made available there to third parties may change. The single point of contact may be designated by a handle, such as an alphanumeric code that can be resolved to a particular web page or IP address. The handle may be a unique string appended to a particular URL as a pointer to a file containing the user's contact information.
A third party may also retrieve information and “slurp” a user's contact information, in the form of the particular contact mechanisms, without the need to copy the information on an individual basis. The third party may store the information for later use on various client devices, e.g., a home computer, an e-mail account, a mobile device, or a home phone, or the third party may use the handle each time to contact the user. Likewise, some clients may allow the third party to choose the method of contact for the user and choose the handle in order to have the client retrieve the particular contact identifier correlated with the handle. For example, instead of providing an individual contact mechanism like a work phone number, the third party can simply supply the invariant handle along with an argument like “work,” and a service may route the third party to the user via the user's current work telephone number. In this manner, a user may update contact information on a regular basis without the concern that various friends, family, or work associates may be unable to contact the user.
FIG. 1 is a conceptual diagram of asystem100 that connectsthird party102 to auser114 of thesystem100 by one of a number of contact mechanisms, where the particular contact mechanism could be specified by thethird party114 or theuser102. In general, thesystem100 may allow thethird party102 to provide a single handle, or perhaps the handled plus additional basic information, in order to contact theuser114 by various mechanisms, without having to know the contact information for those various contact mechanisms. The contact mechanisms may also take a variety of formats, such as telephone, e-mail, and the like.
In theexample system100, athird party102 is shown submitting to the system100 ahandle106, which in this example is a10-digit telephone number. Thethird party102 in this example is trying to contact user114 (whether directly, by leaving a message foruser114, or by being shown content such as a web page thatuser114 has generated) by one of a variety of mechanisms. Although thehandle106 takes the form of a telephone number here because users are accustomed to memorizing such numbers and to assigning them as contact mechanisms, thehandle106 can take a variety of forms that “look” different than a telephone number, such as by looking like the person's full name or like an e-mail address.
Various contact identifiers104 are shown by whichuser114 may be contacted. These contact identifiers are from a plurality of different modes of communication, such as telephone, e-mail, and others. A mode of communication is a particular distinct type of communicating, where each user may be contacted by one or more contact identifiers for any particular mode. For example, the user reflected inFIG. 1 has three telephone numbers, and thus three contact identifiers for the telephone mode of communication (in addition to thehandle106, which may act like a telephone number).
Arouting mechanism110 controls how thethird party102 communicates with the user112 when thethird party102 provides thehandle106 to thesystem100. In particular, the handle may be correlated with a particular contact mechanism of a particular mode of communication. With respect to the telephone mode of communication and telephone numbers as contact mechanisms, the handle may correlate much as a telephone handle is correlated to other telephone modes of contact in a system such as the known GRAND CENTRAL system. However, the handle in this example may also be correlated with multiple modes of communication, so that when thethird party102 provides the handle, thethird party102 is connected by a technique other than a telephone call, such as via e-mail. As a result, the handle may, in certain implementations, be a universal handle for contacting theuser114, by whatever desired mode.
The particular mode of communication may be set by theuser114, by thethird party102, or by one or more rules such as rules defined by theuser114. For example, theuser114 may manually set a flag that indicates their currently-preferred mode of receiving communications. As one example, theuser114, as they enter a large meeting or another location in which a telephone call would be inappropriate, may log into a system and indicate that their preferred mode of communication is one of a number of textual modes, such as e-mail or chat. Thethird party102 may indicate the preferred mode by accompanying their submission of thehandle106 to the system with a mode indicator. For example, the third party may type “123-456-7890 email” along with text for an e-mail message in order to e-mail another user. Thesystem100 will then interpret the request appropriately and form an e-mail message to theuser114 at an e-mail address that the system has determined to be an appropriate e-mail address. For example, if thesystem100 matches a domain relating to the sender to a business-related domain for theuser114, thesystem100 may send the e-mail message to the user's work e-mail account. In contrast, if the domain is a domain such as “aol.com” or a domain on a whitelist for the user (such as an old college friend), the e-mail message may be sent to a personal account.
Theuser114 may also establish rules of various forms for selecting a communication mode. For example, if the user does not like to receive telephone calls or check voice mail over the weekend, but does carry a smart phone with them, they may set their mode of communication to e-mail, so that third parties are induced to send them e-mails. A mix ofthird party102 defined mode anduser114 defined contact identifier under a mode may also be employed. For example, athird party102 may identify e-mail as the mode of communication, and then user-defined rules may determine which e-mail account, from multiple e-mail accounts associated with the user, is to receive the e-mail. Responses by theuser114 may likewise be generalized to reflect the handle in the “from” field, rather than the particular e-mail account used byuser114.
Where thethird party102 does not dictate the mode of communication and the user's preferred mode of communication does not match a mode that the third party initially selects, thethird party102 may be prompted to user the other mode. For example, the third party may initially dial thehandle106 as part of a telephone call. Thesystem100 may determine that theuser114 currently wants to be contacted by e-mail, and may thus play a message such as “If you would like to contact Bob at the moment, please e-mail him at xyz@xyz.com.” Thesystem100 may also transmit data to the third party's computing device so as to start a form e-mail that is automatically addressed to theuser114, or may simply send an e-mail from the user's account to the third party102 (e.g., where the third party's telephone number can be determined from ANI or caller ID data, and can be correlated to an e-mail address for thethird party102, such as through an address book for the user114), so that thethird party102 can simply reply to the incoming e-mail.
In some implementations, the mode indicator may be preselected based on the client device that thethird party102 uses. For example, if thethird party102 is using a mobile phone to transmit thehandle106, thesystem100 may directly connect thethird party102 to theuser114 via the telephone number in thecontact identifiers104. Alternatively, if the third party's client device has more than one mode of communication (e.g., a smart phone), thethird party102 may be provided with various modes of contacting theuser114, including phone, web page, IM, and e-mail, all associated with thehandle106.
As noted above, in this example, thehandle106 includes a telephone number or is in the form of a telephone number, “123-456-7890.” The use of a telephone number may be useful for an individual to remember, given that telephone numbers are commonplace in that many countries use Arabic numerals to some extent. Alternatively, thehandle106 may include an alphanumeric string. For example, thehandle106 may be the user's name or the user's preferred e-mail address or street address. Likewise, thehandle106 may be a portion of the user's full telephone number with a country or state code, or both, e.g., “US-MN-456-7890.”
While thecontact identifiers104 are shown here conceptually as a virtual list from which arouter110 selects one identifier for connecting thethird party102 to theuser114, they may also be actually displayed to theuser114 orthird party102 when such a party accesses a web page in the form of a contact page and directs their attention to theuser114, such as by entering thehandle106 for theuser114 or by entering one of thecontact identifiers104 for theuser114. Such a contact page can show contact identifiers that are a subset of a full set of contact identifiers. For example, if thethird party102 is a new acquaintance to theuser114, theuser114 may provide for a small subset of contact identifiers to be shown to thethird party102, such as a work phone number, work e-mail address, and website. In some implementations, theuser114 can provide thethird party102 with a password to access a larger subset of the full set of contact identifiers. Likewise, the user may provide group-specific passwords to provide different subsets of the full set of contact identifiers to different groups, e.g., family, friends, coworkers, and acquaintances. In one implementation, access to contact identifiers may be coordinated with user statuses in a social networking site, where strangers may be shown limited contact identifiers, acquaintances (which have been affirmatively approved by the user) may see additional identifiers, and an “inner circle” of friends may see even more identifiers (e.g., home phone numbers and the like).
Similarly, the third party's contact identifiers may already be associated with the user's account. For example, theuser114 may have an address book of contacts stored as a part of his or her user account. Contact identifiers for thethird party102 may be associated with an entry for thethird party102 in the address book. For example, a client device for a third party may transmit an identifier, e.g., an e-mail address, telephone number, or IM account name, with thehandle106. The identifier may be associated with a group access level or an individual access level for a subset of contact identifiers.
In these manners, one or more third parties may use a handle such ashandle106 to contactuser114 and/or to see information about theuser114. In one example, thehandle106 is provided so as to connect thethird party102 to theuser114 via one of a number of different contact identifiers and modes of communication. In another example, thehandle106 is used to allow thethird party102 to see information about theuser114, such as various contact identifiers associated with theuser114. As a result, thethird party102 can take advantage of a number of different communication techniques vis-à-vis theuser114 without having to memorize or otherwise manage a large number of different contact identifiers, each of which may change over time. Instead, thethird party102 can, in proper implementations, simply record
FIG. 2A is a schematic diagram200 of a system for retrieving a user's various contact identifiers correlated to a handle. In general, thesystem200 permits various third parties to access and retrieve contact identifiers for users that have user accounts, using a single handle to identify a particular user account. Thesystem200 includes athird party202 using aclient device204 to transmit a request to acontact identifier server206, the request including ahandle208. Thecontact identifier server206 may store thehandle208 with a contact page210 along with contact identifiers212 for a user account.
Thecontact identifier server206 may store contact identifiers for at least one user account correlated to ahandle208. A plurality of contact identifiers may be correlated with a single handle, and a plurality of different communication modes may be represented by those identifiers. In some implementations, thecontact identifier server206 may automatically update data on aclient device204 for a third party when a particular user account is updated. For example, thecontact identifier server206 may receive data from the user for the account to update a phone number. Thecontact identifier server206 may store the data and send an automatic update to any third party device associated with the previously stored phone number, such as users who are identified as friends of the main user in a social network. For example, where a main user has changed their work phone number, thecontact identifier server206 may send information reflecting that changed number to accounts of acquaintances of the main user, e.g. by sending a new user .vcf card with the new work phone number for MICROSOFT OUTLOOK.
In some implementations, the update may be sent upon a request sent from the third party to thecontact identifier server206. For example, if theclient device204 transmits a request for a user's IM contact identifier, thecontact identifier server206 may update theclient device204 with a new IM contact identifier when thecontact identifier server206 connects theclient device204 to a user's device to communication through instant messaging. Likewise, the new IM contact identifier can be transmitted before the connection is made, while the connection is occurring, or after the instant messaging connection has ended.
Alternatively, thehandle208 may be the only identifier saved on the third party'sclient device204. Thehandle208 may be stored in a list of handles on theclient device204, where each handle corresponds to a particular acquaintance of the third party, and the third party makes communication connections simply using the various handles. For example, on a mobile phone, the third party may have an address book of handles for various user accounts, including the name of a particular user assigned as a pseudonym for each handle. In some instances, the third party may be able to designate a particular alias for a user, e.g., an IM screenname or an image. Thehandle208 may be part of a Uniform Resource Identifier, e.g., a URL containing thehandle208 5555551234, “http://www.exampledomain.com/5555551234.”
The third party'sclient device204 may be one of a variety of client devices, such as a mobile device, a smart phone, a laptop computer, a desktop computer, or a landline. Theclient device204 may provide a mode identifier to thecontact identifier server206 so that the contact identifiers transmitted to the client device are limited to contact identifiers with which theclient device204 can make a connection. For example, theclient device204 can be a laptop computer with a VoIP application, an e-mail application, a web browser application, and an IM application. Thecontact identifier server206 may then transmit contact identifiers including telephone numbers, e-mail addresses, blogs, websites, and an IM account name compatible with the particular IM application.
FIG. 2B is a sequence diagram250 depicting examples of interactions between acaller252, acontact identifier server254, and afriend256 of thecaller252 to retrieve for thecaller252 contact identifiers using ahandle260 for thefriend256. The sequence diagram shows thefriend256 providing contact identifiers to thecontact identifier server254, thecaller252 accessing information from thecontact identifier server254 using thehandle260, and thecaller252 contacting afriend256 using thehandle260. In some implementations, both thecaller252 and thefriend256 may have accounts with contact identifiers stored on thecontact identifier server254.
In the figure, thefriend256 initially submits information (indicated by Arrow A1) to thecontact identification server254. Thefriend256 provides his contact identifiers258 (indicated by Arrow A2) correlated to ahandle260. Thecaller252 transmits a request (indicated by Arrow B) to thecontact identifier server254 to access information for thefriend256. Thecaller252 is directly connected to the friend256 (indicated by Arrow C) using a contact identifier provided by thecontact identifier server254.
In some implementations, thecontact identifiers258 may also be stored on a personal computing device. For example, a computing device used by thecaller252 may store one or more of the contact identifiers that thecontact identifier server254 may grant to thecaller252. The computing device may use the stored contact identifiers to connect to a computing device associated with one or more of the contact identifiers correlated with the user'shandle260. For example, thecaller252 may have a cell phone that receives a cell phone number for hisfriend256 from thecontact identification server254. The cell phone may store the cell phone number for hisfriend256. The cell phone can use the received cell phone number to connect to a cell phone of thefriend256. Likewise, the computing device may compare a stored list of contact identifiers with thecontact identifiers258 provided by thecontact identifier server254 to update one or more contact identifiers that thefriend256 may have updated since thecaller252 last sent a request to thecontact identifier server254.
Alternatively, the connection may be made from thecaller252 to thefriend256 through thecontact identifier server254. This connection may be made during the grant of the request for access or after the request for access is granted. For example, thefriend256 may have a preferred method of contact associated with his user account, e.g., an e-mail address. Thecaller252 may request information using a smart phone, and thecontact identifier server254 may provide the smart phone with the e-mail address. An e-mail application on the caller's computing device may receive the e-mail address and generate a new message using the e-mail address in the “To:” field. Similarly, if thecaller252 wishes to call thefriend256, thecaller252 may designate “phone” as a method of contacting thefriend256. Thecontact identifier server254 can receive this request along with thehandle260 and connect thecaller252 with thefriend256 via a telephone connection.
In some implementations, thecaller250 can accesscontact identifiers258 from thecontact identification server254 through a query, using the friend's personal information to gain access to the account for the user. For example, thecaller252 may not know thehandle260. If thecaller252 provides personal information for thefriend256, e.g., a name, an e-mail address, or a telephone number, thecontact identifier server254 may provide access to one or more other contact identifiers to thecaller252. For example, thecaller252 may already have the work e-mail address for hisfriend256, but not have the work phone number for hisfriend256. If thecaller252 provides the work e-mail address to thecontact identifier server254 in a request for the work phone number, the work e-mail address may act as a password or security identifier to thecontact identifier server254. Thecontact identifier server254 may associate the work e-mail address with the work phone number or a work address. The work e-mail address may also be associated with a cell phone number. In some implementations, thecontact identifier server254 may be associated with a website similar to white pages, where the website provides a search tool to find a handle for a user account. For example, if thecaller252 enters the friend's name, the website may provide thehandle260.
FIG. 3 is a schematic diagram of a system350 for correlating a handle with contact identifiers, and for retrieving the contact identifiers correlated with the handle. In general, the system350 permits users to create user accounts that are represented to the outside world by a handle and that internally correlate to a plurality of different contact identifiers representing a plurality of communication modes. The system350 then lets other users search user accounts for information about people or organizations they are trying to contact, where the system may provide such searching users with the handle, and the users may then use the handle to contact another user in various manners and using various different communication modes.
Auser352 may interact with the system350 using acomputing device354 to connect with aserver356. Such communication may occur over one or more networks (not shown), which may include portions of the internet. Theserver356 may be various devices, for example, a single computing device, multiple servers in a cluster, or multiple computing devices spread over the internet in a cloud. Theserver356 may assist in providing contact identifiers to thecomputing device354. Likewise, theserver356 may correlate contact identifiers with a handle for a user account. Thecomputing device354 may be provided with one or more communication applications such as a telephony application, IM application, and e-mail application, which may employ a handle to begin a communication session with a target user that corresponds to the handle.
Theserver356 contains a number of components that permit it to provide a user'scomputing device354 with a connection to contact identifiers that have been correlated with a handle. For example, aninterface358 may handle communications with remote devices such ascomputing device354. Theinterface358 may, for example, receive requests from thecomputing device354 for contact identifiers correlated to a handle. Theuser352 may send a handle, such as “612-555-1234,” to request contact identifiers (in the form of e-mail addresses, telephone numbers and the like) for a particular user account holder. The contact identifiers may relate to various modes of communication, e.g., telephone, e-mail, instant messaging, blogs, and websites that are associated with a user who corresponds to the handle. Theinterface358 may receive this handle and provide contact identifiers in response. The requesting user may employ such identifiers to update contact information for the other user stored in thecomputing device354 or in a contact database associated with a user account for theuser352.
Once theinterface358 receives data, it may transmit the data to another component such as anaccount manager360, which is responsible for providing consistent and personalized interaction with registered users of system350. Theaccount manager360 may identify a handle for a particular user in the received data. The handle may be correlated to a uniform resource locator (URL). For example, the handle may be included in a URL for a website: “http://www.examplehandle.com/612-555-1234.” Theaccount manager360 may also identify passwords for particular accounts. For example, theuser352 may provide a password to set up or edit a user account. Likewise, users may provide passwords to gain access to various subsets of contact identifiers correlated to a particular handle. For example, the user account can be set so that users with a “family” password have access to a mobile phone number and home phone number, but not a work phone number.
Theserver356 may also include acorrelator362 that correlates received handles with contact identifiers relating to the handles. In particular, thecorrelator362 may be programmed to perform a look-up function on the handle, and to return a list of contact identifiers for the handle, where the list may be limited based on an authorization level of a user that is requesting the information. For example, only close friends that have full authorization may be shown a contact identifier for a home telephone number or very private e-mail account. Thecorrelator362 may also cause the handle, the contact identifiers, and pointers connecting the handle to the contact identifiers to be stored for later use. Thecorrelator362 may also correlate passwords with particular handles or particular contact identifiers. In some implementations, thecorrelator362 may store the user account data in a single database. Alternatively, thecorrelator362 may store the user account data in multiple databases.
A database storing information for theserver356 may have various data stores that are used to correlate lists of contact identifiers for user accounts to the corresponding uniform resource locators for such accounts. In some implementations, the database may include apasswords data store366, a contactinformation data store368, and ahandles data store370. Thepasswords data store366 may contain passwords for the user account, including a password for editing the contact identifiers for a particular user account (e.g., where the “owner” of the account is accessing the information) and passwords for accessing various contact identifiers for a particular user account (e.g., where acquaintances of the “owner” are seeking information). The contactinformation data store368 may contain contact identifiers for various users. In some implementations, the contactinformation data store368 may also contain data regarding preferences for particular contact methods, groups for particular contact identifier subsets, and other user-preference data. Thehandles data store370 may store handles for various user accounts. The handles may be integers, as in telephone numbers, alphanumeric strings, images, or other unique identifiers. Generally, thehandles data store370 and the contactinformation data store368 may be combined in the form of a look-up table that is indexed according to particular user handles.
Theserver356 may also include acommunication mode selector364 to receive a mode indicator. The mode indicator may provide information as to the selection of communication method that has been selected for making contact betweenuser352 and another user. For example, thecommunication mode selector364 may receive a “mobile” mode indicator for theuser352 indicating that theuser352 wants to call the other user's cell phone. Such a mode indicator may accompany the handle, as may other mode indicators such as “e-mail” and “home phone”, so thatuser352 merely needs to remember or store the single handle, and then add a general description of the communication mode—rather than having to remember or store a separate identifier for every way in which theuser352 can contact the other users.
Also, certain aspects of the mode indicator can be controlled by the target user either explicitly or via contextual rules. For example, theuser352 may use a telephone to dial another user, and the call may be routed toserver356. The server may recognize the call, via DNIS information received from the telephone system or from other data, as being directed to the particular handle, and may access information about the user that is the target of the call. For example, the system may determine that, at the current time, the target user would prefer to receive e-mail messages. As a result, theserver356 may use a voice synthesis module to speak a message touser352, such as “The user you are calling would prefer to receive e-mail for the next 24 hours.Press 1 to leave a voice message that will be transcribed into an e-mail message or e-mail the user at bob@acme.com.”
Thecommunication mode selector364 may also receive one or more contact identifiers from the database, e.g., the contactinformation data store368. Where multiple contact identifiers are received for a particular mode, the appropriate mechanism for contacting the target user by that mode may need to be determined. For example, thecommunication mode selector364 may receive a home phone number, a cell phone number, a URL for a website, and an e-mail address for a home e-mail account. Thecommunication mode selector364 may initiate a communication session between theuser352 and the other user according to one of the communication modes. For example, thecommunication mode selector364 may use a telephone mode indicator and then look at the target user's schedule to select the cell phone number for the other user, and cause theuser352 to be connected to the cell phone of the target user. The schedule may be set by rules provided by the target user, such as rules defining that the target user is to be contacted at his or her work number during work hours and at his or her cell phone after hours (and perhaps that all calls should automatically roll to a central voice mail or voice mail to e-mail transcription service during sleeping hours). Thus, thecommunication mode selector364 can select a particular mode based on inputs from an initiating party, from a target party, or from rules set up by or selected by one of the parties, and can also select a particular contact identifier from multiple identifiers that may exist for a particular communications mode, by which to complete the communication.
FIG. 4A is a flowchart showing an example of aprocess400 for correlating a handle with contact identifiers. Such a process may be employed by a user of a central connecting service who wants to initially set up a count by selecting a handle and then supplying all of the user's various contact identifiers to be correlated to the handle. Theprocess400 shows one example of generating a user account with contact identifiers across multiple modes of communication, correlated with a single user handle. The single user handle allows the user's contacts to communicate with the user in various communication modes without requiring the contacts to store information regarding the user's various contact identifiers separately or having to update the contact identifiers as the user changes individual contact identifiers.
At an initial step, theprocess400 obtains (402) identifiers for a plurality of contact identifiers for a computer account holder. For example, the identifiers may be unique identifiers for particular mechanisms of communication under various communication modes for a particular user. The communication modes, e.g., blogs, instant messaging, telephone, mail, and e-mail, can each have multiple unique identifiers for each of the mechanisms by which the user can be contacted. For example, in instant messaging, a user may have an MSN MESSENGER identifier, an AMERICA ONLINE Instant Messenger identifier, and a GOOGLE TALK identifier.
Theprocess400 then identifies (404) a handle for the account holder. For example, the handle may be a string that the user selects when setting up his account, such as the user's full name or a particular phone number. The handle can also be selected by the process for the user, such as in the manner that telephone numbers are provided for selection by a user seeking a new telephone number. In some implementations, the handle may be correlated to a URL. For example, the URL may be a website address for a unifying presence site, e.g., “http://www.exampleonesite.com.” The correlated handle may navigate to a unique page designated for the account holder. For example, the URL correlated with the handle may be “http://www.exampleonesite.com/612-555-1234.”
Theprocess400 then correlates (406) the handle with the plurality of contact identifiers. For example, the user's instant messenger accounts and e-mail addresses may be correlated with the handle “612-555-1234.” In some implementations, theprocess400 may store the handle, the plurality of contact identifiers, and pointers connecting the handle to the plurality of contact identifiers in a database. For example, the system350 described inFIG. 3B may store the handle, the plurality of contact identifiers, and the pointers in multiple data stores, e.g., thehandles data store370 and the contactinformation data store368. Also, the handles may be stored in an index field of a look-up table, with the contact identifiers stored in a target field of the same table so that a simply look-up on the handle field may return the corresponding contact identifiers.
In this manner, a user of a computing system may register their contact information, which may span multiple mechanisms for connecting and multiple modes of communication, with a central service. The service may then correlate such mechanisms with a single common handle by which the various forms of information may more easily be recovered or used by other users, such as by being used to connect to the first user in a communication session.
FIG. 4B is a flowchart showing an example of a process420 for retrieving an account holder's contact identifiers correlated with a handle. Such retrieval may be performed by someone searching for the user/account holder discussed inFIG. 4A or by an acquaintance of such an account holder. The acquaintance may have received the handle from the account holder, and may want to find out the latest contact information for the account holder. The process420 shows one example of receiving a handle from a user and using the handle to identify contact identifiers for a particular account holder, though other examples may also be used. The handle allows the user to communicate with the account holder in various communication modes while only requiring the user to provide the single handle.
At an initial step, the process420 receives (422) a handle for an account holder submitted by a user of a computing device. For example, the computing device may submit the handle “ChakaKhan”—a name that is unique enough that it alone could serve as a unique identifying handle. The handle can provide a unique identifier for the process420 to identify a particular account of an account holder. Likewise, the process420 may request a password before providing information about other contact identifiers, such as a home telephone number or work e-mail address.
The process420 then provides (424) a list of contact identifiers from a plurality of different communication modes to the user of the computing device. For example, the list of contact identifiers may include a home mailing or e-mail address, a work address, a work website, a Twitter account identifier, and a cell phone number. In some implementations, different subsets of the list of contact identifiers may be provided. For example, the process420 may only provide the work address and cell phone number to a person given “Work” group access, while a person designated as belonging to a “Friend” group may be provided the home address and the Twitter account. Groups may be designated through various mechanisms. For example, the process420 may determine the level of access through password requests or the process420 identifying the client device used to request contact identifiers.
Atbox426, the process connects the user to the account holder by one of a plurality of communication modes. For example, a work e-mail address may be propagated to a word processing document, with the address field preset to the account holder's work e-mail address. In some implementations, the connection may be made in response to a selection by the user of the computing device of a contact identifier corresponding to the one of the plurality of communication modes. For example, the user may choose “Feed” to read the most recent Twitter post by the account holder.
In some implementations, the handle may be correlated to a URL. As in an example forFIG. 4A, the URL may be a website address for a unifying presence site, e.g., “http://www.exampleonesite.com.” The process420 may receive a request with the URL “http://www.exampleonesite.com/612-555-1234”, retrieve the account for “612-555-1234”, and map the request to a contact identifier included in the account.
FIG. 5A is a sequence diagram for depicting an example ofinteractions500 between anaccount holder502 in a communication system and aserver504. The process shown here is similar to that shown inFIG. 4A, and provides a more explicit indication of exemplary manners in which an account holder and a server system can interact in correlating identifiers with a single user handle. In general, the interactions involve a server generating a user account, assigning a handle to the user account, and correlating a number of contact identifiers with the account.
In the figure, theaccount holder502 initially transmits identifiers (box506), such as e-mail addresses, telephone numbers, and instant message accounts, to theserver504. Such a transmission may occur after theaccount holder502 initially establishes his or her account. Theserver504 then receives the identifiers (box508) and determines a handle (box510) for theaccount holder502. In some implementations, theaccount holder502 provides input to theserver502 regarding a choice of handles. For example, theaccount holder502 may provide an initial suggestion of a handle along with the first identifiers that the account holder transmitted to theserver504. Alternatively, theserver504 can also provide a handle without input from theaccount holder502.
Theserver504 then correlates the handle with the identifiers (box512). Such correlation may occur by storing the handle and the identifiers together in a look up table so that entry of the handle to the table causes the identifiers to be provided. Atbox514, theserver504 stores the handle and the identifiers in a database such as in a look up table. In certain implementations, pointers from a handle to the identifiers may also be stored. As shown inFIG. 3, the identifiers and the handle need not be stored in the same location, though they may. In some implementations, the pointers may be stored with the handle, or, alternatively, the pointers may be stored with the identifiers. The pointers may also be stored in a third location, separately from both the identifiers and the handle.
Once theserver504 has stored the account information, theserver504 transmits a confirmation (box516) that the handle and identifiers (and optionally the pointers) have been recorded and correlated to each other. The confirmation may be a complete listing of all the information, a confirmation containing the handle and identifiers, or simply the handle. Theaccount holder502 then receives the confirmation atbox518. The confirmation can be received in various formats, including an HTML-embedded e-mail, an instant message, a web page, a text message on a cell phone, or a generated voice message.
FIG. 5B is a sequence diagram that depicts an example ofinteractions530 between auser532, anaccount holder534, andservers536. By the process, a third party use may submit a handle to a central system where the handle corresponds to an account holder in the system. The system then identifies a communication mode and mechanism by which the account holder should be contact, and automatically carries out the necessary steps to cause such communication to occur. As such, the process shown here is similar to that shown inFIG. 4A, and provides a more explicit showing of exemplary manners in which a third party can contact the account holder without having to remember or provide detailed contact information. In particular, theservers536 may be part of a unifying identifier system and may communicate with various client devices, such as cell phones, laptop computers, landlines, and smart phones to provide an ease of communication between theuser532 and theaccount holder534 and also to more accurately provide the user's and account holder's preferred methods of communication. In this manner, the connection may be easier for theuser532 because theuser532 need only remember a single handle and perhaps some generic control information (e.g., a common term that identifies the mode of communication), and in certain implementations, the particular contact identifier may be kept anonymous from theuser532. For example, where the contact is made through theservers536, an actual e-mail address or telephone number may be masked using a system address or number via a bridging mechanism similar to that for e-mail communications using on-line services such as CRAIGSLIST.
In the example process, theuser532 initially submits to a group of servers (536) a handle for an account holder (box538). Theservers536 receive the handle (box540), such as a telephone number appended to a URL. Theservers536 then determine contact identifiers (box542) correlated to the handle. The contact identifiers may be selected from a larger group of contact identifiers for theaccount holder534, and may include one or more identifiers within each of a plurality of communication modes. For example, theuser532 may be an unknown individual to theaccount holder534. Therefore, theaccount holder534 may store a setting that theuser532 will not receive a home telephone number that is stored as one of the identifiers.
Atbox544, theservers536 then transmit a list of contact identifiers to theuser532 and theuser532 receives the list of contact identifiers (box546). Theuser536 may receive the list through an application programming interface (API) so that the contact identifiers can be updated in a client device that theuser532 is using to connect to theservers536. In this manner, theuser532 may more readily contact theaccount holder534 through a variety of methods of communication. For example, theuser532 may wish to call theaccount holder534 to discuss an e-mail that theuser532 plans to send to theaccount holder534 during the telephone conversation.
Theuser532 then selects one of the contact identifiers (box548). In some implementations, this determination is made through the user's client device that connects to theservers536. In other implementations, the determination is made because theuser532 is only granted access to one contact identifier, or theaccount holder534 has only provided one contact identifier. Alternatively, theuser532 may select from the list of contact identifiers provided. Theservers536 receive the selection (box550) of contact identifiers. Theservers536 then attempts to connect theuser532 to theaccount holder534 by contacting the user532 (box552) and contacting the account holder536 (box554). The contact may be a VoIP connection or an instant messaging chat session. Theuser532 receives the contact (556) and theaccount holder558 receives the contact (558). If both theuser532 and theaccount holder534 accept the contact, theuser532 and theaccount holder534 are connected (560). The connection may be a direct connection, such as through landlines, a routed connection through theservers536, or a connection through a third party service, such as an instant messaging connection.
In certain implementations, the users may be connected directly, such as by theuser532 submitting a handle and receiving a telephone number in return. The telephone number then may be dialed automatically by the user's client device, such as via an automatically executing dialing link in a mark up document sent by theserver536.
The connection may also be made automatically through theservers536. For example, theservers536 may include servers for completing a VOIP telephone connection, and may carry out the necessary steps to connect theuser532 and theaccount holder534. Such an implementation is particularly well-suit for keeping contact identifiers of theaccount holder534 private, and not sending any information about the identifiers (or at least some of the identifiers) to theuser532. Such an approach may be useful when an account holder is working from home and would like to be reached at home, but does not want people calling his or her work number to get access to his or her home number.
FIG. 6A is an exemplary universal business card600. The universal business card600 may be in an electronic or hard copy format. The universal business card600 shows one example of how an account holder like the account holder discussed above may share contact information with other users. While a traditional business card may include several telephone numbers and other contact information for a number of modes of communication (e.g., mail, e-mail, telephone, etc.), the universal business card600 includes a single handle that can be resolved by a central system automatically into one of the modes of communication and a particular mechanism (e.g., telephone number) for that mode.
The universal business card600, as shown, includes the name602 of the account holder, shown as “Jodi Cisewski,” the employer604 of the account holder, “Engineering, Inc.,” and a link606 to the user's contact identifiers using a handle608. As shown, the handle includes a telephone number and is appended to a URL. The URL may also, in appropriate circumstances, be considered to be part of the handle608. The URL may be a common URL that is easy for user to memorize (e.g., because many of their acquaintances have handles associated with the URL), and the handle may also be an alphanumeric string that is relatively easy for other users to memorize or store. The information underlying the universal business card600 may be updated under the account holder's control to ensure that people may receive current contact information for the account holder, even as the data shown on the card stays the same. The universal business card600 also provides a small amount of data for a third-party to receive. In this manner, a third party can see what the cardholder does, and can also be given access to more information about the cardholder without having the card600 cluttered by detailed information.
FIG. 6B is a screenshot of aweb page610 for retrieving a user's contact identifiers correlated with a handle. Theweb page610 contains thename612 of the account holder, a handle614, and alink616 to contact the account holder. In some implementations, theweb page610 is the site connected to the link from the universal business card ofFIG. 6A. A person looking atpage610 may select thelink616 to be connected automatically to the user, where a central system may automatically select the contact mechanism and mode of communication by which the contact is to occur. For example, if Jodi currently wants to communicate by e-mail, selection of thelink616 may cause a blank e-mail message with a relevant e-mail address for Jodi filled out, to be generated on the same client device that was previously displaying thepage610.
FIG. 6C is a screenshot of aweb page630 for correlating a handle with contact identifiers. Theweb page630 provides entry forms for a user to provide contact identifiers for a system to store and correlate the contact identifiers provided with a handle. InFIG. 6C, the fields include ahandle field632, apassword field634, and aname field636. Other fields includephone640,e-mail642,IM644,website646,blog648,networking site650, andVoIP652. The fields shown below thename field636 each have a “+” button so that a user can add more than one of the types of fields display on theweb page630. For example, there may be multiple instant messaging accounts for multiple instant messaging applications or multiple instant messaging accounts for one instant messaging application. If the “+” symbol is pressed, theweb page630 can add another field of the same mode indicator. For example, theaddress field638 inFIG. 6C is shown as displaying “home”. If the “+” symbol for the address field is selected, the second address field may be marked “work” or “home2”.
In some implementations, theweb page630 provides fields for other forms of contact, such as a call sign for an amateur radio broadcaster. In some implementations, theweb page630 may display one or more fields632-652 that include predetermined information if the system is also connected to a communication mode. For example, if the user has an e-mail account that is accessible through a link displayed on theweb page630, theweb page630 may already display the user's e-mail address, her home page, her user identifier and password for an instant messaging program, her time zone, and any other information she wishes to make public to at least some of the individuals who may access her information through the account. In some implementations, theweb page630 may have a separate page for different groups with different security levels or check boxes or pull-down menus for each field to designate the access level for each group.
InFIG. 6C, theweb page630 also includes acolumn including advertisements654. In some implementations, theadvertisements654 may include data based on the information that the user has input to the web page. For example, if the user provides a phone number with an area code “612”, theadvertisements654 may include data specific to Minneapolis, Minn. Similarly, the advertisements may include data that is associated with a website or blog, as entered in thewebsite646 and blog648 fields.
FIG. 6D is a screenshot of aweb page670 displaying a user's contact identifiers correlated with a handle. Theweb page670 has acontact name672, atelephone number674, a home e-mail address676, a blog link678, and acontact link680 to allow a visitor to request further contact identifiers. Theweb page670 may be a web page for a specific group, such as a friends group or a family group, or theweb page670 may be intended for a general group. In some implementations, theweb page670 may also include a login area so that viewers can provide a password to access more information.
In some implementations, theweb page670 may also display contact information for an account associated with a group rather than an individual. For example, the user may be a non-profit organization with a changing executive board and contact information. In such an instance, the single point of contact may provide continuity because members or interested parties may not need to update contact points. For example, if an executive board elects a president every year, the new president may update thecontact name672,telephone number674, and home e-mail address676 upon his election. The blog link678 may not need to be changed, however. Likewise, if the third parties have the capability to update the information on an automatic basis, no time would be wasted looking up the new contact information. It would be provided to the third parties upon request.
Theweb page670 includes a column foradvertisements682. The advertisements may be specified based on the user account information. The advertisements may also be sponsored. For example, the user may be provided with a financial benefit for each visitor to theweb page670. Similarly, the user may be provided with a financial benefit each time a visitor clicks a link to one of theadvertisements682 on theweb page670.
FIG. 7 is a block diagram of computing devices700,750 that may be used to implement the systems and methods described in this document, as either a client or as a server or plurality of servers. Computing device700 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Computing device750 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other similar computing devices. Additionally computing device700 or750 can include Universal Serial Bus (USB) flash drives. The USB flash drives may store operating systems and other applications. The USB flash drives can include input/output components, such as a wireless transmitter or USB connector that may be inserted into a USB port of another computing device. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed in this document.
Computing device700 includes aprocessor702,memory704, astorage device706, a high-speed interface708 connecting tomemory704 and high-speed expansion ports710, and alow speed interface712 connecting tolow speed bus714 andstorage device706. Each of thecomponents702,704,706,708,710, and712, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. Theprocessor702 can process instructions for execution within the computing device700, including instructions stored in thememory704 or on thestorage device706 to display graphical information for a GUI on an external input/output device, such asdisplay716 coupled to high speed interface708. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices700 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).
Thememory704 stores information within the computing device700. In one implementation, thememory704 is a volatile memory unit or units. In another implementation, thememory704 is a non-volatile memory unit or units. Thememory704 may also be another form of computer-readable medium, such as a magnetic or optical disk.
Thestorage device706 is capable of providing mass storage for the computing device700. In one implementation, thestorage device706 may be or contain a computer-readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. A computer program product can be tangibly embodied in an information carrier. The computer program product may also contain instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as thememory704, thestorage device706, or memory onprocessor702.
The high speed controller708 manages bandwidth-intensive operations for the computing device700, while thelow speed controller712 manages lower bandwidth-intensive operations. Such allocation of functions is exemplary only. In one implementation, the high-speed controller708 is coupled tomemory704, display716 (e.g., through a graphics processor or accelerator), and to high-speed expansion ports710, which may accept various expansion cards (not shown). In the implementation, low-speed controller712 is coupled tostorage device706 and low-speed expansion port714. The low-speed expansion port, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.
The computing device700 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server720, or multiple times in a group of such servers. It may also be implemented as part of a rack server system724. In addition, it may be implemented in a personal computer such as alaptop computer722. Alternatively, components from computing device700 may be combined with other components in a mobile device (not shown), such as device750. Each of such devices may contain one or more of computing device700,750, and an entire system may be made up of multiple computing devices700,750 communicating with each other.
Computing device750 includes a processor752,memory764, an input/output device such as adisplay754, acommunication interface766, and atransceiver768, among other components. The device750 may also be provided with a storage device, such as a microdrive or other device, to provide additional storage. Each of thecomponents750,752,764,754,766, and768, are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.
The processor752 can execute instructions within the computing device750, including instructions stored in thememory764. The processor may be implemented as a chipset of chips that include separate and multiple analog and digital processors. Additionally, the processor may be implemented using any of a number of architectures. For example, the processor410 may be a CISC (Complex Instruction Set Computers) processor, a RISC (Reduced Instruction Set Computer) processor, or a MISC (Minimal Instruction Set Computer) processor. The processor may provide, for example, for coordination of the other components of the device750, such as control of user interfaces, applications run by device750, and wireless communication by device750.
Processor752 may communicate with a user throughcontrol interface758 and display interface756 coupled to adisplay754. Thedisplay754 may be, for example, a TFT (Thin-Film-Transistor Liquid Crystal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display interface756 may comprise appropriate circuitry for driving thedisplay754 to present graphical and other information to a user. Thecontrol interface758 may receive commands from a user and convert them for submission to the processor752. In addition, anexternal interface762 may be provide in communication with processor752, so as to enable near area communication of device750 with other devices.External interface762 may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used.
Thememory764 stores information within the computing device750. Thememory764 can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units.Expansion memory774 may also be provided and connected to device750 throughexpansion interface772, which may include, for example, a SIMM (Single In Line Memory Module) card interface.Such expansion memory774 may provide extra storage space for device750, or may also store applications or other information for device750. Specifically,expansion memory774 may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example,expansion memory774 may be provide as a security module for device750, and may be programmed with instructions that permit secure use of device750. In addition, secure applications may be provided via the SIMM cards, along with additional information, such as placing identifying information on the SIMM card in a non-hackable manner.
The memory may include, for example, flash memory and/or NVRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as thememory764,expansion memory774, or memory on processor752 that may be received, for example, overtransceiver768 orexternal interface762.
Device750 may communicate wirelessly throughcommunication interface766, which may include digital signal processing circuitry where necessary.Communication interface766 may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. Such communication may occur, for example, through radio-frequency transceiver768. In addition, short-range communication may occur, such as using a Bluetooth, WiFi, or other such transceiver (not shown). In addition, GPS (Global Positioning System)receiver module770 may provide additional navigation- and location-related wireless data to device750, which may be used as appropriate by applications running on device750.
Device750 may also communicate audibly usingaudio codec760, which may receive spoken information from a user and convert it to usable digital information.Audio codec760 may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of device750. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on device750.
The computing device750 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as acellular telephone780. It may also be implemented as part of a smartphone782, personal digital assistant, or other similar mobile device.
Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” “computer-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), peer-to-peer networks (having ad-hoc or static members), grid computing infrastructures, and the Internet.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, various forms of the flows shown above may be used, with steps re-ordered, added, or removed. Also, although several applications of correlating and retrieving a handle with contact identifiers and methods have been described, it should be recognized that numerous other applications are contemplated. Accordingly, other embodiments are within the scope of the following claims.