System and method for providing identity-based services

Abstract

Users of Internet communication services (e.g., SKYPE messaging service, GOOGLETALK messaging service, AOL INSTANT MESSENGER messaging service, and MICROSOFT MESSENGER messaging service, IP PBX systems, etc.) that are initially identified using separate identifiers (e.g., username@serviceprovider) can manage these network identities using a single, personal, unified set of account information managed by a registry service. The registry authenticates the user's request(s) to bind a service provider identity to his or her personal registry identity by presenting a random challenge to the user that the registry must then receive back from the service provider corresponding to the identity being added. Later, the registry may authenticate itself to service providers using information received from a service provider application as the service provider application authenticates itself to the service provider.

Description

FIELD OF INVENTION

The present invention is directed to a method and system for managing network identities using an identity registry.

DISCUSSION OF THE BACKGROUND

A number of on-line communication protocols exist that enable users to create network identities and communicate with each other. For example, on the Internet, MICROSOFT MESSENGER messaging service, AOL INSTANT MESSENGER messaging service, SKYPE messaging service, and GOOGLETALK messaging service each provide some level of communication between their users as well as some presence information. However, communication between these competing systems has often been problematic. For example, these applications each maintain their own namespaces, even though they may support identical modes of communication (voice, say, or text IM), and they generally do not interoperate.

Some attempts have been made to utilize services or protocols that interconnect the separate services such that communication can be made between services. TRILLIAN messaging service and JABBER messaging service are attempts that have been made to allow inter-service communication with limited success. Moreover, the management of user identities is still not yet truly unified.

BRIEF DESCRIPTION OF THE DRAWINGS

The following description, given with respect to the attached drawings, may be better understood with reference to the non-limiting examples of the drawings, wherein:

FIG. 1 is a block diagram of a network including a registry for user identities;

FIG. 2 is a message flow diagram showing a first identity authorizing process for use with the network of FIG. 1;

FIG. 3 is a message flow diagram showing a second identity authorizing process for use with the network of FIG. 1;

FIG. 4 is a message flow diagram showing the propagation of presence information from a registry to plural service providers;

FIG. 5 is a message flow diagram showing a first process for authentication and presence information updating; and

FIG. 6 is a message flow diagram showing a second process for authentication and presence information updating.

DISCUSSION OF THE PREFERRED EMBODIMENTS

Turning to FIG. 1, a user of plural Internet services (e.g., SKYPE messaging service, GOOGLETALK messaging service, AOL INSTANT MESSENGER messaging service, and MICROSOFT MESSENGER messaging service) is initially identified using separate user names or other identifiers for each of the plural Internet services. For example, a fictitious user (e.g., John Jones) may have user names such as fictitioususer1@gmail.com and fictitiousdad@aol.com. Both of these user names provide methods of enabling other users to reach John Jones. However, there is no linkage between the two user names that allows John Jones to manage his account information uniformly and in one place. In addition, John Jones may not want all other users to know all of his user names or the presence information provided by the applications with which those user names are associated. To aid in account management, John Jones may subscribe to a registry service that will enable Mr. Jones to unify his on-line identities and centralize his account management and account log-on functions. One example of a registry may be the Personal Internet Communications Unification Project from NET2PHONE, Inc., referred to hereinafter as “PICUP” or “picup.com”.

When Mr. Jones subscribes to the registry service, he is assigned or is allowed to select a registry-specific identifier, such as johnjones@picup.com. As shown in FIG. 2, Mr. Jones may authenticate himself with that name to the registry service (through any number of known authentication techniques and protocols). For example, as shown in FIG. 1, Mr. Jones may use an application (labeled “Reg. App” for registry application) to communicate with the registry service. Applications that can be used for this authentication include, but are not limited to, a web browser (e.g., MICROSOFT INTERNET EXPLORER web browser or MOZILLA FIREFOX web browser) using a user name and password combination or a custom application that passes authentication information (e.g., a user name and password combination, a fingerprint, a secure token or a signed message).

Having acquired a registry identifier from the registry and having authenticated himself to the registry, Mr. Jones can, as part of the identity management process, begin associating other identities with the registry identifier. To do this, Mr. Jones sends to the registry an “Add identity” message including an identifier such as a user name corresponding to one of the plural service providers. For example, Mr. Jones sends fictitioususer1@gmail.com to the registry.

The registry may parse the received identifier into a domain name and a user id and, if necessary (as indicated by the dashed line in FIG. 2), request a connection with the service provider associated with the domain name. For example, the registry may contact the GOOGLETALK messaging service server associated with the gmail.com domain name.

The registry then sends a “challenge” to Mr. Jones via his registry application. The challenge may be in the form of a random number, text or even graphic containing clear or obscured random text/numbers. For example, the challenge could be a random number “9157638.” As depicted by the dashed line of FIG. 2, the user then transfers (e.g., copies and pastes or retypes) the random number from the registry application to a service provider application corresponding to the service provider (e.g., the GOOGLETALK messaging service server) for the identity (e.g., fictitioususer1@gmail.com) being added. The service provider application then contacts, on behalf of Mr. Jones, the service provider corresponding to the identifier (e.g., fictitioususer1@gmail.com) that he sent the registry. (Like with the registry application, the service provider application may also be implemented as either a customized application or a web browser-based application.) The service provider application then sends to the service provider the same information that was contained in the challenge that he received from the registry. Lastly, the service provider sends to the registry the challenge that the service provider received from the service provider application (as it was transferred by the user). This completes a confirmation cycle that enables the registry to verify that the user does control the account corresponding to the identifier of the service provider.

As shown in FIG. 3, a second identity adding process can be used instead. In this process, the registry is not required to make a connection with the service provider to receive the challenge. Instead, after the challenge is received by the registry application, the challenge is provided to the service provider application that signs the challenge using a private key of a public/private key pair. The service provider application then sends the signed message back to the registry, and the registry can verify the signed message using the public key received from a key repository corresponding to the service provider.

The registry may consolidate not only identities but also real-time information (e.g., presence information) about the identities. For example, as shown in FIG. 4, Mr. Jones may set his status information to “on-line” (using either a registry application or using a service provider application). When this change is received by the registry, the registry propagates this information to all of the service providers that are managed by the registry. However, this information management assumes that the registry and the services can authenticate each other so that the service providers and the registry know that the information is to be shared.

One way in which this can be achieved is to have a service provider application running locally that authenticates the user to both the service provider and to the registry. As shown in FIG. 5, a service provider application has authenticated itself to its corresponding service provider (e.g., AOL Instant Messaging service). When the user elects to use the registry to centralize its presence information, the service provider application sends to the registry the log-in information (e.g., username and password) used in the initial authentication to the service provider. The registry can then authenticate itself to the service provider as well using the authentication information that the service provider is expecting. To avoid the service provider assuming that this is a new login by the user at a different location (that may cause the existing log-in to be terminated), the registry identifies to the service provider that the registry is logging on only as a proxy that will receive presence information and not as a communications end-point.

Later, when Mr. Jones uses his service provider application to change his presence information (e.g., by setting it to “Do Not Disturb”), the information received by the service provider will be passed to the registry so that other information services may see the same change, as shown in the last two steps of FIG. 5.

Alternatively, in the case of having used the authentication method of FIG. 3, as shown in FIG. 6, the service provider application can be configured to send the change in presence information to both its corresponding service provider and the registry. When the change in presence information is sent to the registry, it is preferably signed using the same private key that was used during the process of adding an identity shown in FIG. 3. In such a configuration, the registry can verify the authenticity of signed message containing the change in presence information using the public key corresponding to the identity. This enables the registry to receive presence information updates without requiring the registry to log into the service provider as a proxy. Moreover, if the registry has cached a copy of the public key received during the identity adding process, the registry does not have to re-contact the service provider to verify the authenticity of the change. This can reduce load on the service provider's network.

As shown in FIGS. 7 and 8, various other authentication protocols are also possible. In FIG. 7, assuming that the registry application has already sent an “Add identity” message including an identifier to the registry, the registry sends back a random challenge to the registry as was discussed above with reference to FIG. 2. However, as shown in FIG. 7, contemporaneously with receiving the challenge, the registry application also receives a phone number (or the name of an identity) indicating where it should be contacted. The user provides this phone number (or identity) to the service provider application which forwards it to the service provider for initiation of a telephone call. The service provider then connects to the telephone number (or identity). In at least one such embodiment, the telephone number (or identity) being used by the registry is provided by the service provider such that the authentication phone call remains “on network” for the service provider. Upon establishing a phone connection between the service provider and the registry, the user is prompted to enter the challenge (e.g., using a keyboard or DTMF tones, depending on the capabilities of the service provider application). Because the registry is able to determine on whose behalf the incoming call is being made (e.g., by looking at the caller ID information for a SKYPE telephone to SKYPE telephone call), the registry can then confirm that the challenge has been properly delivered to the user corresponding to the identity which is being added.

Alternatively, as shown in FIG. 8, similar to the authentication process shown in FIG. 7, a telephone connection can be made between the service provider and the registry so that the user may send the challenge to the registry over a telephone connection. However, in FIG. 8, it is the registry that establishes a connection to the service provider associated with the identity being added and requests that a connection be made to that identity. In this way the requirement for authentication of the identity on the service provider is pushed to the original service provider itself

While the above embodiments of FIGS. 7 and 8 have been described with respect to establishing a telephone connection (e.g., a SKYPE telephone) between the registry and the service provider, other types of connections are also possible. For example, a text messaging connection between authenticated text messaging clients (e.g., between MICROSOFT MESSANGER messaging service clients) can also be established and the challenge(s) sent across those connections.

In configurations such as those discussed above with respect to FIGS. 7 and 8, the registry may include an automated response program (e.g., an avatar) that handles the incoming and/or outgoing connections and the parsing of the received challenges and/or the prompting for the challenges, whether the connections be telephone-based, text-based or a combination thereof

A system, such as the registry described above, that tracks identities can provide additional services. For example, the registry can support in-bound and out-bound directed advertising to a particular user, whether or not the user manages plural identities through the registry. The advertising sent may be informed by the user's behavior on one or across multiple service provider domains. In an out-bound advertising system (i.e., a push advertising system), the registry gathers and stores (e.g., in a database or file system that is linked to a user's registry record) selected information regarding characteristics of at least one of the identities. Such information may be static information (e.g., a person's name or social security number), dynamic (e.g., based on computer usage information such as web sites visited), or semi-permanent (or infrequently changing) information (e.g., address information, age, number of dependents, and marital status). An advertising service (which might include a server and database) that is coupled to and associated with the registry can then receive and store a series of advertisements aimed at consumers and other users based on the static, semi-permanent and/or dynamic information that is associated with each of them in the registry. The advertisements may be in the form of messages to be delivered, such as could be delivered in text, voice or video formats. Along with the advertisements, or at a later time, or both, the advertising service would receive a set of criteria that advertisers wish to use to target specific groups of users.

Later, after a user logged on to the registry or to a service provider linked to the registry, the advertising service would be able to determine if any of the identities being used by the user matched any of the criteria for any of the stored advertising. Such a criteria-checking policy could be performed prior to the user being logged on, when the user is logged on, or periodically after the user is logged on. When the advertising service determines that at least one of the criteria has been met for a logged on user, the advertising service transmits one of the advertisements to at least one of the identities.

In one embodiment, the advertiser may specify a preference order for the delivery of the advertisements. Such an order may specify which of the advertisements to deliver first if more than one advertisement matches a user's criteria. Such a technique can be used to deliver the message in a preferred format. For example, an advertiser may select a preference for delivering the same message but in different formats such that the advertising is sent preferably in the following order: (1) video form (e.g., MPEG), (2) as an animation to be played by the ADOBE FLASH player, (3) as an animated JPEG or animated GIF, (4) as a voice clip (e.g., an MP3 file) or (5) as a text message.

The advertising service would track the conditions under which each of the advertisements were delivered and provide reports to the various advertisers detailing how the advertisers' advertisements were delivered. In the case of an interactive advertisement (e.g., a web-page style advertisement or an animation to be played by the ADOBE FLASH player), the advertising service may also provide to the advertisers or receive from the advertisers information on how the user interacted with the advertisement such that the efficacy of the advertisement to a particular group may be tracked. Typically, the advertising service would then receive advertising fees from the advertisers based on an advertising agreement (e.g., as a fixed monthly fee (regardless of the number of advertisements delivered), as a function of the number of advertisements, as a function of the number of advertisements targeted and delivered to specific groups, and/or as a function of the efficacy of the advertisements).

Alternatively, the advertising may be based on an in-bound system (a pull system). In such a system, it is the user (through at least one identity) that selects what kind of advertising it will accept. Just as in the out-bound system, the registry gathers and stores (e.g., in a database or file system) selected static, semi-permanent and/or dynamic information about at least one identity. The advertisements again may be in the form of messages to be delivered, such as could be delivered in text, voice or video formats. Along with the advertisements, or at a later time, or both, the advertising service would receive a set of criteria that the advertisers wish to use to target specific groups of users and also a user's preferences for how he/she wishes to receive advertisements.

Later, after a user logged on to the registry, the advertising service would be able to determine if any of the identities being used by the user matched any of the criteria for any of the stored advertising that were compatible with the kinds of advertising that the user specified he/she would accept. Such a criteria checking policy could be performed prior to the user being logged on, when the user is logged on, or periodically after the user is logged on. When the advertising service determines that at least one of the advertiser's and user's criteria has been met for a logged on user, the registry transmits one of the advertisements to at least one of the identities.

In one embodiment, the advertiser and the user may specify a preference order for the delivery of the advertisements. The advertising service would then deliver the advertisement in the format that matches the user's and advertiser's highest combined matching preference. In one such embodiment, the registry, the advertising service, and the user would then both receive an advertising fee from the advertiser for having received the advertiser's advertisement(s). The user's fee may be in the form of a coupon, a credit to a store, a credit to a registered credit card, etc.

The user may also be paid a fee by the advertising service or by the advertiser for being willing to receive advertisements, even if none are in fact delivered. The user's fee may be in the form of a coupon, a credit to a store, a credit to a registered credit card, etc.

Advertising may be displayed to a user in the form of a separate window that receives advertisements. Alternatively, advertisements may be displayed to the user as part of a user interface that controls the messaging performed on behalf of the user. In addition, when using voice messages, a separate user interface is not necessary and a message may simply play periodically through the user's speakers. In yet another embodiment, an icon in the system tray flashes to alert a user that there is a new advertisement such that the user may accept or reject the advertisement. When an advertisement is accepted, the appropriate player (e.g., audio or video player) is launched or activated such that the advertisement can be delivered.

A system for providing advertising as described above may further gather information on a user's web browsing habits to better target advertisements. Known systems have used “cookies” to track how a particular web browser uses a web site. However, by using cookies associated with a web browser, a web site may associate either too much data or not enough data the actual user that the site is trying to track. This is because plural users may use the same web browser on a shared computer such that one family member's interaction data is incorrectly combined another family member's. This can happen, for example, in the case of a parent and child sharing a computer or spouses sharing a computer. Additionally, the information about the user can be under-inclusive from the perspective that a user's interactions from his/her home computer are not grouped with interactions from his/her office computer.

To address this concern, a web server may track web activities based on presence information rather than on (or in addition to) cookies. In one such embodiment, an advertising service associated with a web server requests information from the registry on what user is associated with the computer that has sent the web server a request. For example, when the web server receives a request for a web page from the (fictitious) IP address 123.124.125.126, the web server, or the associated advertising service, can request that the registry identify which user, if any, is currently authenticated at that address. If there is an authenticated user at that address, then the information about the user may be returned to the web server to help track the user's activities.

In an alternate embodiment, an application running on the user's computer may receive information from the user's web browser about what web page the user is viewing or has recently viewed. This information can be collected along with the identity that the user is authenticated with at the time on the registry and periodically sent to either a central information repository or to the web sites associated with the viewed web pages. The visited web sites can be monitored by installing hooks into the web browser that monitor web sites or URLs.

In yet another embodiment, the web site may send to the user's web browser an ACTIVEX control (as part of the web page) that communicates with the registry application (or with a registered service provider application) such that the web browser is able to send to the web server the identity that the user is authenticated with at the time the web server is contacted. For example, when a “submit” button is selected on a web page, the ACTIVEX control is activated to send a message (e.g., a dynamic data exchange (DDE) message) to the registry application and receive a response containing the identity before sending (e.g., POSTing) any form information contained on the page.

A system, such as the registry described above, that tracks identities can also act as a tool for reducing the amount of unwanted communications that a user receives. This is possible because it is believed that many unwanted solicitations and offers come from sources that wish to remain anonymous and/or untraceable. Using the method described herein, a user can provide information to the registry that reduces the user's anonymity (at least to the registry) and increases the registry's ability to track the user. The more verifiable information about the user that the registry collects, the higher the user's trust rating becomes. For example, if the user provides an address that is to correspond to his account, then the registry system can send out a letter to the address with a form to be returned or instructions on verifying to the registry that the letter was received at the specified address. The instructions may take the form of a response (e.g., random number) to enter the next time that the user visits his account information page at the registry. Similarly, the verifiable information may be a voice or facsimile telephone number where the user can be contacted by a customer service representative of the registry. After having been contacted with the appropriate information, the registry increases the user's trust rating. Other types of verifiable information include a credit card number and name such that the registry can successfully charge a nominal fee to the credit card provided by the user, thereby authenticating the user. The registry can establish rules for what kind of information is needed to achieve a specific user trust rating.

Later, when an initiating user attempts to establish a communication with another user (i.e., a receiving user) through the registry, the registry can first determine if the initiating user has a user trust rating that is at least as high as the minimum user trust rating specified by the receiving user. If not, then the registry will indicate to the initiating user that communication with the specified receiving user is blocked due to the initiating user's user trust rating.

Registry-based authentication can be used with email as well. In a first embodiment, the registry acts as a mail server and users can log on to the registry to both send and receive email. When both the sender and receiver use the registry to send and receive mail and when the sender wishes to send an email, the registry can check the user trust rating of the sending user and the minimum trust rating specified as acceptable for the receiving user. If the ratings do not match, the registry can notify the sender that the email has been refused because of the sender's user trust rating or add it to the receiver's email but with a special flag that indicates that the email has not been approved, depending on the receiver's settings. However, if the minimum is met, the mail can be added to the receiver's email box with an indication that it meets the receiver's minimum criteria. Using filters, a registry user can then easily separate the email into approved and unapproved email.

However, some users may not wish to change where their received email is stored such that those users would not want to receive their email through the registry. Those users, however, may still use user trust ratings of the registry. The registry can act as a public key repository for a user's identity such that receiving users can check the authenticity of a signed email as well as the user trust rating for the sending user. The registry can even act as a repository for public keys from other service providers that are added to the user's identity as part of the authentication process discussed above.

In an alternate embodiment, senders would log on to the registry when sending and then the registry could simply forward on the email to the receiver's normal account having added a registry system signature (such that users don't need their own public/private key pair). Alternatively, the registry could simply add (and remember) a message identifier and a hash such that the user's filtering program could verify that the received message had the appropriate identifier and hash before indicating that the message met the higher authentication rating.

Using a system such as the registry system described above, a user may also be able to manage a set of preferences that controls the order in which the user will be contacted when an in-bound request for communications arrives at the registry. For example, when Bob wants to initiate a text/voice messaging session with Sally, Bob's registry-compatible text messaging client may see that Sally is on-line and available for text messaging, but it may not show whether Sally is using AOL IM messaging service, GOOGLE TALK messaging service, or NET2PHONE COMMCENTER messaging service (because Sally doesn't want it known or because Bob's contact management software only displays presence information about modes, not applications). Bob might therefore invite Sally to a text and/or voice messaging chat session without knowing to which application the “invite” message is sent. That decision could be made by the registry in accordance with logic rules Sally establishes. For example, Sally might have established a connection preference rule (e.g., a “find me” rule) for the PICUP persona Bob is calling that “rings” her first using the NET2PHONE COMMCENTER messaging service, then using the GOOGLE TALK messaging service, then using the AOL INSTANT MESSANGER messaging service. Alternatively, the preference may be based on dynamic conditions, such as which application was most recently used, what time of day it is, what day it is, whether it is a holiday, etc. Other logic rules are possible, and all could be maintained as part of the registry user record for Sally.

Such preferences also make it possible to receive a preferred mode of communication. For example, the list of preferences may state that during the weekday, the preferred method of connecting is via a specified work telephone number, and then at a cell phone, and then at a voice-based messaging service, then at a text-based messaging service, etc. Alternatively, the list of preferences may state that during the weekend, the preferred method of connecting is via a voice-based messaging service, then at a text-based messaging service, and then no other connections are permitted. Thus, an initiating user may use the registry application to ask the registry what the best match is for contacting a receiving user, and then, based on the information returned, the registry application can start (or request that the user start) the appropriate service provider application to establish the communication channel between the initiating and receiving users.

The registry application may also be configured such that it interfaces with at least one of the service provider applications to provide connection control (e.g., call set up and tear down) and messaging services. In such a configuration, the user interfaces with the registry application to send messages (e.g., text message, voice messages or voice-over-IP call streams) to the service provider application which then sends them on to its corresponding service provider. The registry application may perform media protocol translations as necessary to provide the messages to the service provider application in a format which it understands. For example, if the registry application receives a voice stream in a first format (e.g., raw) but the service provider application expects it in a second format (e.g., compressed), then the registry application may perform the necessary conversion. In one embodiment, the registry application and the service provider application engage in a format negotiation to determine a preferred format for sending the messages.

While certain configurations of structures have been illustrated for the purposes of presenting the basic structures of the present invention, one of ordinary skill in the art will appreciate that other variations are possible which would still fall within the scope of the appended claims.

Claims

1. A method of providing advertising to computer users, comprising: maintaining a set of identities in a registry;maintaining a set of advertisements;determining characteristics about the identities that match characteristics relevant to delivering the advertisements to users associated with the identities;delivering at least one of the advertisements to a user corresponding to at least one of the identities based on the matching characteristics.

2. The method as claimed in claim 1, wherein the advertising is provided as out-bound advertising.

3. The method as claimed in claim 1, wherein the advertising is provided as in-bound advertising.

4. The method as claimed in claim 1, wherein the user specifies at least one characteristic which must be met before delivering at least one of the advertisements to the user.

5. The method as claimed in claim 4, wherein the user receives compensation for receiving at least one of the advertisements.