GB2452283A

GB2452283A - Establishing a common ID in first and second domain

Info

Publication number: GB2452283A
Application number: GB0716766A
Authority: GB
Inventors: Rufus Simon Tobias Evison
Original assignee: CLICKSTREAM TECHNOLOGIES PLC
Current assignee: CLICKSTREAM TECHNOLOGIES PLC
Priority date: 2007-08-30
Filing date: 2007-08-30
Publication date: 2009-03-04
Also published as: GB0716766D0

Abstract

Methods of establishing a common user identity are described, utilising only first-party cookies. The method comprises receiving at a first domain 3 a first request 2 from the client computer 1, transmitting 4 from the first domain 3 to the client computer a first identity for the user associated with the first domain and a first redirection instruction. The first redirection instruction is configured to cause the second domain to transmit 6 to the client a second identity for the user associated with the second domain, wherein the second identity is related to the first identity. A request may also be received at the first domain from a client computer, the request including an identity for the user associated with the first domain, and if the user has an identity associated with a second domain, recording a relationship between the user's identity associated with the first domain and a user's identity associated with a second domain.

Description

1 2452283 User Identification

Background

The current invention relates to the identification of users accessing web sites using the internet, and in particular to the development of a common identity between web sites.

It is beneficial for content and service providers to be able to acquire information on the number of visitors to web-sites and particularly to be able to establish a history of web accesses by a particular user. Such a history enables content to be targeted to users dependent upon the content they view and other features of their behaviour while viewing web-sites. In order to compile a history for a user, web-sites must be able to identify the user accessing them and relate that to accesses to other web-sites by the same user. A common identity is therefore required for each user across the web-sites that will be included in the user's history.

A common identity is also valuable as it allows different web-sites to recognise a particular user and tailor their content to that user, dependent not only upon the users preferences on that web-site, but also on other web-sites for which the common identity is established.

Developing a common identity is problematic as web-page requests from web-browsers do not contain sufficient information to identify accesses to different sites as being by the same user.

A common method of identifying particular users is to provide users with usernames such that when they visit sites they log-in using that username. The identity of the user is then apparent and each user's access can be tracked. However, this system is disadvantageous as it can only operate on sites that provide a log-in system and can only track users when they log-in using their user name. Furthermore, users may be put off visiting a site if it requires them to log-in several times as they move from one part of the site or set of sites to another part as the log-in process consumes time and inconveniences the user.

In some situations it is possible to identify a user from their network address, but such methods are unreliable as a user's network address may change relatively frequently and thus an address is not necessarily synonymous with a particular user. Furthermore, addresses are often shared between multiple users and thus it is not then possible to identify a single user from an address.

Cookies are small pieces of data that can be transmitted between web-servers and web-browsers to allow the identification of a particular user by the domain name to which the cookie corresponds. Once a web-browser has a cookie for a particular domain name, that cookie is sent back to the web-server each time a page from that domain name is requested (depending upon the settings of the cookie, sending of the cookie may be restricted to only requests for certain pages, sub-domains or directories within the domain). The web-server can therefore establish the identity of a user requesting a web-page by the content of the cookie. Cookies sent by a web-server in the context of the data sent by the web-server are known as first-party cookies since they relate directly to the data received by the user.

A cookie is only accessible by the domain name to which it corresponds, and so can only be utilised to establish a user's identity when that particular domain name is accessed. First-party cookies do not therefore allow the establishment of a common identity between domain names.

Third-party cookies are defined as cookies that are not sent in the context of the content received. For example, a cookie received from A in response to a request for information from A is a first-party cookie. However, if the content requested from A also includes a cookie or reference to retrieve a cookie from Z, that cookie is a third-party cookie. Third-party cookies can be used to track users between domain names by inserting a piece of information from a server, Z, into a number of pages A, B and C (which may be located on the same, or different, domains). Each time a user accesses A, B or C, their web-browser automatically requests the information from Z. The first time Z is accessed, a cookie is sent to the client, and thereafter each access to A, B or C results in that cookie being sent back to Z as the information from Z is requested. It is therefore possible for Z to monitor accesses to A, B or C. Third-party cookies are unpopular as they create security and privacy issues and many web-browsers now automatically block third-party cookies making their use impractical.

There is therefore a requirement for a method of establishing a common identity for a user between multiple domain names, while overcoming the disadvantages of the prior art.

Summary

The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

There is provided, a method of establishing a common identity for a user of a client computer in a network comprising a first domain and a second domain, the method comprising transmitting a first request from the client computer to the first domain, receiving at the client computer a first identity for the user associated with the first domain and a first redirection instruction, wherein the first redirection instruction instructs the client computer to transmit a second request to the second domain, transmitting from the client computer to the second domain a second request and information relating to the first identity, and receiving at the client computer a second identity for the user associated with the second domain and a second redirection instruction, wherein the second identity is related to the first identity.

The second redirection instruction may instruct the client computer to transmit a request to.

the first domain.

The network may further comprise a third domain, and the redirection instruction instructs the client computer to transmit a request to the third domain.

The method may further comprise the step of transmitting from the client computer to the first domain a third request including the identity associated with the first domain, wherein the third request is a request for content, which content is also requested by the first request.

The method may further comprise the step of receiving at the client computer the content requested in the third request.

The first identity and the second identity may be associated by containing a common item of data.

The first identity and the second identity may be associated by a database, in which the relationship between the two identities is recorded.

The first request may be transmitted in response to a third redirect instruction received from the second domain.

The client may receive the third redirect instruction from the second domain in response to a fourth request to the second domain for content.

The client may receive content requested in the second request in addition to the second identity.

The first identity may be related to an identity identified in the first request.

There is also provided a method of establishing a common identity for a user of a client computer in a network comprising a first domain and a second domain, the method comprising receiving at the first domain a first request from the client computer, ascertaining if the user of the client computer has an identity associated with the first domain, if the user does not have an identity associated with the first domain, transmitting from the first domain to the client computer a first identity for the user associated witi the first domain and a first redirection instruction, wherein the first redirection instruction instructs the client computer to transmit a second request to the second domain, and the first redirection instruction is configured to cause the second domain to transmit to the client a second identity for the user associated with the second domain, wherein the second identity is related to the first identity.

The method may further comprise ascertaining if the user of the client computer has an identity on a third domain, and relating the identity on the third domain to the user's identity on the first domain.

The step of ascertaining if the user of the client computer has an identity associated with the first domain may be performed by ascertaining whether a cookie containing an identity was received with the first request.

There is also provided a method of establishing an identity for a user, the method performed at a first domain and comprising the steps of receiving a request at the first domain from a client computer, if the request includes an identity for the user associated with the first domain, ascertaining if the user has an identity associated with a second domain of the network and if the user has an identity associated with the second domain, recording a relationship between the user's identities associated with the first and second domains.

The method may further comprise if the request does not include an identity for the user associated with the first domain, ascertaining if the user has an identity associated with a second domain of the network, if the user does have an identity associated with the second domain, transmitting to the client an identity associated with the first domain, wherein the identity is related to the identity associated with the second domain.

Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings.

Description of the drawings

Embodiments of the present invention will now be further described, by way of example, with reference to the drawings, wherein:-I0 Figure 1 is a schematic network diagram of a client and two web-servers; Figure 2 is a flow-chart of a process for assigning a common identity between two domains, when the client visits the master domain first; Figure 3 is a flow-chart of a process for assigning a common identity between two domains, when the client visits the slave domain first; Figure 4 is a flow-chart of a process for re-assignment of an identity when the master domain's cookie has been lost; Figure 5 shows a schematic diagram of a network having three domains and one client; Figure 6 shows the path of a client's accesses through an arbitrary number of domain names when acquiring a new identity; Figure 7 shows a schematic diagram of a network having one master and four slave domains; Figure 8 shows a flow-chart of the process of assigning an identity when a client visits a slave domain for the first time in the network of Figure 7; Figure 9 shows a schematic diagram of a network having two domains kept in synchrony; Figure 10 shows a schematic diagram of a network having three levels of domain; Figure 11 shows a flow-chart of a method of assigning common identities in which more than one master domain assigns identities; Figure 12 shows a flow-chart of a method of assessing whether a client is accepting cookies; Figure 13 is a flow-chart of a method of assigning identities utilising a peer-to-peer system; Figure 14 is a schematic diagram of a network including identification systems for implementing methods according to the current invention; and Figure 15 is a flow-chart of a system for assigning a common identity utilising identification systems.

Detailed description

The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

In order to track the history of a user's web-access it is necessary to be able to establish a common identity for each user between domain names.

The current invention provides a method of identifying a user between domain names without the use of third-party cookies. As has been described hereinbefore the use of third party cookies is undesirable as they lead to security and privacy concerns.

In Figure 1, A.com and B.com are domains which may be visited by a client computer 1.

Figure 2 shows a flow-chart of a method of establishing a common identity for client 1 between A.com and B.com. Arrows in Figure 1 indicate transmissions of information during the assignment of a common identity to the client according to the method of Figure 2.

A user of the client computer I may wish to access "a.com/alpha.html" located on A.com. At block 20 the client computer I issues a request 2 for that content, which request 2 is routed to the server 3 of A.com according to the routing data associated with A.com. Upon receipt of the request A.com analyses the request (block 21) and ascertains whether it includes a cookie for A.com. If the request does include a cookie then the client already has an identity on A.com from a previous visit and the requested content is served directly to the client at block 22.

As will be apparent to the skilled reader cookies are stored by a web-browser in relation to a user's account on that web-browser. The identity provided by a cookie therefore is that of an account on a web-browser, which does not necessarily correlate to a single user, because a single account may be used by more than one user. Furthermore, a single user may have multiple accounts and therefore be identified by multiple cookies. However, for purposes of clarity, the term user' will be used to describe the entity identified by a cookie. The term client' is used to describe the computer and web-browser used to request and receive content from web-servers.

If at block 21 the request does not include a cookie for A.com then the user is considered to not have an identity on A.com (it may be that an identity does exist but the cookie has been lost, in which case the identity may be recovered as described below). A.com recognises the * lack of a cookie and instead of responding with the requested web-page, responds (4, block * 23) with a cookie containing an identity for the user, and with a redirect to a predefined page on B.com. For example, if the user is to be assigned the identity 1', A.com may respond with "redirect B.com/intercept.html?lD 1 &A.com/al pha.html". Upon receipt of this response, the client stores the cookie sent by A.com (block 24), and at block 25 requests 5 intercept.html from B.com with the parameters supplied by A.com.

"intercept.htm" is a predefined page on B.com that is used to indicate to B.com that the request is in relation to a user's identity, and not a request from a user for content. The parameters associated with the content request (10=1 and A.comlalpha.html) notify B.com of the identity assigned by A.com and the page on A.com that the user originally tried to access.

B.com replies 6 at block 26 to the request with a cookie containing the same identity as that given by A.com, and with a further redirect to the page originally requested, for example "redirect A.com/alpha.html". The cookie from B.com is received by the client in the context of content from B.com (a redirect back to A.com) and so it is categorised as a first-party cookie.

The cookie will not therefore be blocked by the client's web-browser, and since it cannot be used to identify the user on other domains (the B.com cookie only allows identification of the user on B.com), it does not create any privacy issues.

At block 27 the client stores the cookie from B.com and requests 7 A.com/a!pha.html. The A.com cookie stored on the client is sent with the request 7. When A.com receives the request the presence of the cookie indicates that the user has an identity associated with A.com and so at block 28 A.com responds 8 with the requested content (alpha.html).

The client has thus received the content requested and has cookies for both A.com and B.com, each of which contains the same identity. Subsequent requests to A.com or B.com can thus be attributed to the same user, allowing that user's access history on A.com and B.com to be compiled. By extension of the method to more domain names, a more complete history can be compiled.

The identity may be encoded directly into the cookie in which case each cookie for a given user will contain the identity of the user. Alternatively, cookies may each contain a unique reference number, which is related to a user by a database containing the reference numbers and identities. In this example, the database would contain the reference number of the A.com and B.com cookies and the user identity to which they relate. That database may be held at A.com, B.com or a remote computer in contact with A.com and B.com. Where herein cookies are described as having a particular identity, this is intended to include both of the above possibilities, or any alternative methods of allowing an identity for a particular cookie to be established.

Behaviour tracking systems can be utilised to acquire more complete information about user's behaviour in relation to domain names on which the user has an identity. For example, US Patent 6,763,383 describes methods of acquiring user information suitable for use in conjunction with the current invention. The code discussed in US Patent 6,763,383 can be transmitted to the user with the cookie described hereinbefore. The user's identity may be included in the information sent by the tracking system, thereby allowing correlation of logs received by many domain names.

In the current example, Acorn acts as a master web-server and B.com as a slave web-server in relation to the assignment of identities. These names are only used in relation to the function of assigning identities performed by the web-servers and do not imply any structural or hierarchical differences. To avoid an identity being duplicated, the master (A.com) is responsible for selecting and assigning new identities, while the slave (B.com) only assigns an identity when instructed to do so by A.com. Due to the difference in function of master and slave servers, the method of assigning a new identity vanes dependent upon whether the user first visits a master or a slave. In the foregoing example, the user first visited a master (A.com). Figure 3 shows a flow-chart of a process to assign a common user identity between two domain names (A.com and B.com) in the event that a user visits a slave (B.com) first.

Upon receiving a request at block 30 for B.com/beta.html, without a B.com cookie, B.com responds at block 31 to the client with instructions to request A.com/intercept.html?B.com/beta.html at block 33 (i.e. the client is redirected to A.com/intercept.html). As explained previously, intercept.html is* predefined as a page for assigning identities. The client follows this redirect and requests A.com/intercept.html?B.com/beta.html. A.com recognises a request for intercept.html as being a request for a new user identity and the parameters as identifying the content that was initially requested by the client.

At block 33 A.com checks if an A.corn cookie was received with the request, the presence of which indicates that the user has previously visited A.com and has been assigned an identity.

If that is the case the user has an A.com cookie, but not a B.com cookie. If the method described above has been used to assign identities this will only occur if the B.com cookie has been deleted or has expired, because A.com and B.com cookies are, in that method, always assigned together. However, in alternative methods, when a user visits a master site for the first time, only an identity for that master site may be assigned, with identities for other sites being assigned as the user visits those sites. A.com responds (block 34) with a redirect to B.com/beta.html&ID=2, where the identity provided corresponds to that of the user's A.com cookie. The client follows the redirect and at block 35 requests B.com/beta.html&1D2.

B.com recognises the parameter 10=2 as an instruction to assign the identity 10=2 to the user and, when serving beta.html to the client, also sends a B.com cookie having that identity (block 36). The client thus acquires both A.com and B.com cookies corresponding to the same identity.

If at step 33 the request to A.com is found to not include a cookie, then A.com assigns the next available identity and in addition to responding with the redirect as set out above in relation to block 34 also sends an A.com cookie to the user including that identity (block 37).

As in the previous case, the client thus acquires A.com and B.com cookies having the same identity.

The identification system relies on the Acorn and B.com cookies being retained by the user and being sent with each request for content from A.com or B.corn. If either of the cookies are deleted or expire (i.e. become lost) it may be possible to re-establish the identity of the user by reinstating the cookies. In order to re-establish the identity various methods set out below may be utilised and the user can be identified as previously having had an identity, the ability to track the user may be recovered by reinstatement of the cookies.

If only the B.com cookie has been lost, it will be reallocated as explained above in relation to Figure 3, when the user next visits B.com.

If only the A.com cookie has been lost, a new A.com identity is assigned as explained below in relation to Figure 4 by reconstructing the user's identity from their surviving B.com cookie.

At block 40, A.com receives a request for A.com/alpha.htm, but no cookie is present with the request because it has been lost and so A.com assumes this is a new user and begins following the same steps described in relation to Figure 2 (blocks 40 -42 in Figure 4).

However, at block 42, since client has a cookie for B.com, that cookie is sent with the request to B.com. When B.com receives the request for a new identity with a B.com cookie it recognises that the Acorn cookie has been lost. At block 43 a redirect is sent to A.com/alpha.html together with parameters indicating that an identity matching that given in these parameters should be assigned. At block 44, the client requests alpha. html from A.com with the parameters given by B.com. At block 45 A.com serves alpha.html together with a cookie having the identity specified. At block 46 that cookie is stored in place of the previous cookie by the client. Thus the previous identity is reinstated and the A.com and B.com identities correspond to each other.

The new A.corn cookie may have the same identity as the cookie that has been lost, or alternatively may have a new identity that is related to the previous identity by a database which is used to record correlations between identities. In an alternative method, no replacement cookie is sent at block 45, but an entry is made in a database to correlate the old and new identities, thus allowing data from the old and new identities to be related to the same user.

If both of the cookies have been deleted the user's identity cannot be directly recognised and the process is restarted as if the user had not previously had an identity. However, it may be possible to link the old and new identities, and thereby establish a consistent identity.

If either A.com or B.corn has a log-in system, a database may be maintained relating user log-ins to identities. Each time a user logs-in this database can be updated to relate the user's current cookies to any previous ones that may have been lost. Once this link is established, the previous identities could be sent to the client to replace their current ones, or the link could be recorded in the database.

Alternatively, the client's network address or other information may be used to attempt to match the user to a pre-existing identity. If a match can be made the same identity may be reissued, or a new identity is sent and related to the old one.

The methods described above require that the client computer accepts and stores cookies.

For security reasons, users may set their web-browser to not accept cookies, thereby preventing operation of the above-described methods. For example, in the method set out in Figure 2, the client would be continually redirected between A.com and B.com as requests will never be accompanied by a cookie and so each server will continually redirect the client in order to assign an identity to that user. If this occurs the client will be in an unending loop and unable to view the pages requested. A mechanism is therefore required to detect such behaviour and prevent it occurring.

One solution is to detect whether a client's request for a valid page (i.e. not an "intercept.html" page) is a direct request or one that has resulted from a redirect instruction. From the methods described herein it is clear that redirects to "real" pages should only occur once the user has a cookie for the domain to which the request is directed. The lack of a cookie can thus be assumed to indicate that the client's computer is not accepting cookies.

The lack of acceptance by cookies can also be determined by checking what the referring domain is for a request for a real page. If a request for a real page on A.com is received by A.com and the referring domain is B.com, the absence of a cookie will indicate a lack of acceptance of cookies.

In a further method of checking for the acceptance of cookies, the address or parameters passed by a domain during a redirect, when that redirect should be accompanied by a cookie, may be selected specifically to indicate that a cookie should be present. If a domain receives a request that includes an indication in the address or parameters that a cookie should be present, but no cookie is received, then it is clear that cookies are not being accepted by the client.

Figure 12 shows a flow chart of a method of directly checking whether a client is accepting cookies. At block 120 A.com receives a request for alpha.html without a cookie. The lack of a cookie indicates that the user has not been assigned an identity on A.com, or that the cookie has been lost. Before attempting to assign an identity to the user, the client is first checked for the acceptance of cookies. At block 121 A.com responds to the client with a cookie for A.com (this cookie may be a temporary identity cookie or may correspond to the identity that may be assigned to the user if the check is successful) and a redirect to A.com/cookiecheck.html. If the client is configured to store cookies, at block 122 the cookie will be stored on the client and at block 123 the client requests cookiecheck.html from Acorn, together with the A.com cookie. At block 124 A.com receives the request and recognises the presence of an A.com cookie. The presence of the cookie indicates that the client is accepting cookies and an identity is established for the client utilising one of the methods described herein. If the client is not accepting cookies, at block 126 a request is made for A.com/cookiecheck.html, but since according to the client's configuration the A.com cookie was not stored, that request is not accompanied by a cookie. Acorn recognises the absence of an A.com, whi ch indicates the lack of acceptance of a cookie. At block 127 A.com does not proceed with assigning an identity to the client, but serves the requested page.

Alternatively, an alternative identification system may be employed that does not rely on the client accepting cookies.

The methods described herein rely on cookies for operation and so once it has been determined that a client is not accepting cookies, other methods need to be utilised to establish a common identity It is desirable to establish a common identify over as many domains as possible in order to be able to generate a complete view of a user's behaviour. The basic principles described above in relation to the establishment of a common identity for a user in relation to two domains can be expanded to an arbitrary number of domains by a continuation of the principles described hereinbefore.

Figure 5 shows a schematic diagram of a common identity being established between a network of three domains, A.com, B.com and C.com.

A client requests 51 A.com/alpha.html, but since the client has not visited A.com previously it does not have a cookie for A.com. A.com recognises this lack of a cookie and instead of serving the requesting page, responds 52 with a cookie containing an identity, for example ID=1, and a redirect to B.com/intercept.html?ID=1&A.com/alpha.html. The client follows 53 this redirect, and as explained above, B.com recognises the request for intercept.html as a request to assign a new user identity, with lD=1, and responds 54 with a cookie containing that identity. In order to also establish an identity for C.com, the response 54 from B.com also includes a redirect to C.com/intercept.html?ID=1&A.com/alpha.html, which is followed 55 by the client. C.com recognises the request as a request to assign a new identity and responds 56 with a cookie containing the requested identity. Since C.com is the final domain in the network, it responds with a redirect to A.com/alpha.html, which is followed by the client.

Since the client now has a cookie for A.com, this is sent 57 with the request for A.com/alpha.html and A.com serves 58 the page as requested by the client. The client has thus acquired cookies for A.com, B.com and C.com with the same identity.

The above method can be extended to an arbitrary number of sites. Figure 6 shows a schematic diagram of the redirects used by an arbitrary number of servers to establish a common identity. The user initially accesses 60 A.com without a cookie, and A.com responds with a cookie and a redirect 61 to B.com. B.com recognises the request for a new identity and responds with a cookie and a redirect 62 to C.com. C.com recognises the request for a new identity and responds with a cookie and a redirect 63 to the next domain in the chain.

Each domain is visited in turn and an identity assigned until the final domain 64 in the chain is reached, at which point the redirect 65 is back to A.com, which serves 66 the page as requested. The client thus acquires identities from all of the domains in the network.

As will be apparent from the foregoing description a common identity is established by the client being redirected to each domain in turn to acquire a set of cookies having the requisite identity. The order in which the sites are visited is not significant to the operation of the method and many permutations are possible. For example, each domain may redirect the client back to A.com, and A.com may then redirect to the next domains in its list. This may be advantageous as it allows a master list of domains to be held by A.com, and amendments to the domains across which an identity will be established can be made by amending that master list. However, a disadvantage of this pattern may be that additional redirects are required to visit all of the domains, thereby slowing the process.

As the number of domains across which a common identity is required increases, it may become impractical for a client to be redirected to all of the domains in the network as that may lead to unacceptable delays in serving the requested page. Furthermore, it is unlikely that a user will visit all of the domains across which an identity can be established and so there may be no requirement to obtain an identity for all of the domains. Described below are methods of establishing a common identity that do not require all of the sites across which the identity is to be established to be visited. The term network' is used herein to describe the group of domains across which a common identity is to be established.

In order to allow for the establishment of a common identity without requiring all of the domains in a network to be visited, one of the domains in the network, as has been described previously, is defined as the master domain, which domain is responsible for storing a master list of identities. The other domains are defined as slave domains which rely upon the master domain to manage and assign identities. Figure 7 shows a schematic diagram of five domains in which A has been defined as the master domain. The links shown are purely to highlight the topology and do not imply any form of permanent or defined connection, nor does an absence of a link imply no communication.

If the first domain in the network visited by a client is the master domain (A) an identity is selected for the client by that domain and a cookie is sent having that identity. In contrast to the methods described hereinbefore, no redirects are made to provide identities for B, C, D or E to the client, but rather the identity in connection with those domains is assigned when the client visits each domain.

Figure 8 shows a process of assigning an identity in the network of Figure 7 when a client visits a slave domain for the first time.

When a client visits a slave domain (e.g. B, C, D or E) for the first time (block 80), which is detected by the absence of a cookie for the respective site, the site redirects (block 81) the client to a page on A, which is defined as a page used for assigning identities, for example A.com/intercept.html. The address of the content requested by the client is also included in the redirect such that once identities have been assigned the correct content can be served to the client. The request to A, in response to the redirect, will include a cookie for A if the client has previously been assigned an identity on A. At block 82 the presence of an A.com with the request is checked.

If the master site (A) detects that the client does not have an identity in the network (i.e. it does not have an A cookie), the site responds (block 83) with a cookie containing an identity for the client and redirects the client back to the requested content on B, passing as a parameter the identity that has been assigned.

Upon receipt of the request, B responds (block 84) with a cookie having an identity corresponding to the A identity (as passed in the parameter with the redirect) and with the requested content.

If the master site (A) detects that the client does have an identity of the network, the identity of the A cookie is ascertained at block 85. A then redirects (block 86) the client back to the requested content on B and passes the identity as a parameter. Upon receipt of the request, B responds at block 84 to the client with a cookie having an identity corresponding to the A identity (as passed from A to B in the parameter with the redirect) and with the requested content.

The client therefore has corresponding identities on A and B. The same methods can be utilised for each of the identities in the network. As will be appreciated these methods are comparable to those described in relation to Figure 3.

The assignment of identities on a domain-by-domain basis reduces the number of transactions at each stage thereby reducing any delay caused by the system as it establishes an identity. Furthermore, an identity on each domain is only established when it is required, thereby reducing the number of identities created that are not used. As explained above, this is particularly important as the number of sites increases.

Although the above method decreases the number of steps necessary to form a common identity, a single master site must be visited each time a new slave site is visited. In order to reduce the load on the master site a topology such as that shown in Figure 9 may be utilised.

A is defined as a master domain, and is responsible for assigning new identities. However, each time A assigns a new identity, that identity is also assigned on Z, as per the methods described in relation to Figure 2. Once a user has an identity on A and Z, the client can visit either of those domains to acquire a new identity on any of the slave domains. For example, when the user visits B, C, D or E for the first time domain A is used with the method of Figure 8 to assign the same identity for the visited domain. When the user visits V, W, X or Y for the first time, domain Z is used with the method of Figure 8 to assign the same identity for the visited domain.

The load of creating new identities on slave sites is thus shared between two domains.

Although there is an increase in overhead each time a user visits the network for the first time (because identities must be created on two domains -A and Z), this is more than compensated for by the sharing of subsequent load between two domains.

In order to further reduce the load of assigning identities, domains can also be arranged in a further level of hierarchy as shown in Figure 10. A is still defined as the master domain.

When a client visits one of the domains in the tree for the first time it is redirected up the tree, using the methods described hereinbefore, until it reaches either the master site (A), or a domain for which it has an identity cookie. On the first visit to the network the client will arrive at the master domain which will assign an identity to that client. The client is then redirected back down the tree, and is assigned a matching identity for each domain it traverses. For example, if the client initially arrives at domain F, it will acquire cookies from A, B and F as it traverses the tree from F to A and then back to F. If the same client then returns to the network to H it would be redirected to B, where its identity would become apparent, and then revert to H which would serve the requested page and an identity cookie corresponding to that of B. The load of assigning new identities is thus distributed amongst the various domains within the network.

A mechanism for establishing a common identity amongst domains can be summarised as follows. When a client arrives at a domain for which the client does not have an identity, the client is redirected in steps across the network towards the master domain. If the client reaches a domain for which it has an identity, the client is then redirected back to the initially visited domain, together with information to allow the initially visited domain to assign the same identity. If the client reaches the master domain, a new identity is assigned and the client is redirected back to the initially visited domain together with information to allow the initially visited domain to assign the same identity. The same identity may also be assigned by other domains in the network that are visited by the client during the redirection process.

In order to further reduce the load on the master server, it is possible to utilise multiple domains to assign identities, each assigning a unique sub-set of identities to avoid duplication. Such a system utilises a peer-to-peer arrangement of master domains. For example, in the network of Figure 9, both A and Z may be configured to be master domains.

Figure 11 shows a flow chart summansing the process of assigning identities in the network of Figure 9, when both A and Z are configured to assign identities.

The client visits one of the slave domains for which it does not have an identity. At block 110 the domain recognises the absence of a cookie as indicating that the client does not have an identity on the site and at block 111 redirects the client to the most local master server. If the client has visited domains B, C, D or E, this will be A, if the client has visited domains V, W, X or Y, this will be Z. At block 112 the master server identifies whether the client has an identity on that server by checking for the presence of a cookie for that server. If an identity is found on that server, at block 113 one other master server may also be checked for an identity for the client. This is done by redirecting the client to the other master to be checked and the other master ascertaining the presence, or absence, of a cookie for that master. If an identity is found for the client on that master, at block 114 the relation of the two identities is recorded in a database, which can be utilised to correlate information gathered with regard to each of the individual identities. If at block 114 no identity is found for the client, one may be assigned at block 115 and its relation to the client's identity on the other master recorded in a database at block 114.

The steps of checking another master for an identity, and the subsequent assignment or relating of those identities, are not essential to the performance of the method. However, the step of checking other masters for an identity, if not performed at the shown point in the method, must be performed at some point, otherwise a set of discreet identities will be developed with no link between them. In order to establish a common identity for a user links between identities that relate to the same user must be established. In alternative methods, one other server may be checked for an identity, but no new identity created if one is not found. Furthermore, more than one other master may be checked for identities, which may be advantageous when the network of masters grows very large. As will be appreciated, when there are more than two masters assigning identities, a selection of which.master to check must be made. This selection may be made according to a predetermined pattern, algorithm or at random.

After block 114, the client is redirected back to the visited site, together with an identity to be assigned to the user. That identity is passed to the user as described hereinbefore and the requested content served to the user.

If the local master does not have an identity for the user, one other master is checked at block 116 for an identity for that user. That check is performed, as described in detail hereinbefore, by redirecting the user to the domain to be checking and ascertaining whether the user has a cookie for that domain. As explained previously in relation to block 113, the other master to be checked may be selected by any suitable method.

If no identity is found for the user at block 116, at blocks 117 and 118 a new identity is assigned on the local master and the domain visited using the methods described here iribefore.

If an identity is found for the user at block 116, an identity corresponding to that identity is assigned by the local master at block 119 prior to redirection back to the domain visited. The identity assigned may be the same as that found on the other master, or may be a different identity that is related to the previous identity. If the identity is not the same as that on the other master, at block 120 the correlation of the two identities is recorded in a database such that the relation of the two identities to the same user can be established. If the identities assigned are the same there is no need to record their correlation since their relation to the same user can be identified from the fact that the identities are the same. At block 121 the identity assigned by the local master is also assigned by the domain visited and the content requested is served to the user.

This method therefore allows the establishment of a common identity for a user across a network of sites. Since a plurality of domains are responsible for assigning identities, the load on each domain is greatly reduced. By increasing the number of domains responsible for assigning identities the load on each domain is increased. However, identities assigned by different domains must be related to each other in or1er to develop a common identity. As the number of domains assigning identities increases, the task of relating those identities also increases as there is a greater likelihood of a single user having multiple identities assigned by different domains.

In the foregoing description, each time an identity is assigned by a domain, one other domain is checked for an identity for that user, and if one is found the relation is identified. Checking one domain each time a new identity is assigned for a new domain may not be sufficient to establish relations between all of the identities for a user where the number of domains assigning identities is large. It may therefore be required to check for other identities on a more regular basis. For example, each time a domain receives a request for content, one or more other domains may be checked for an identity for the user.

The process of checking for other identities and recording relationship consumes time and therefore delays any action that has triggered the check. It is therefore necessary to balance the delay caused by the checking against the need to perform sufficient checks to relate identities. The time taken to perform a check for an identity, or to assign a new identity, is proportional to the number of redirects, (hops) that are necessary to reach a domain which can assign an identity. As the size of the network grows, there is therefore a requirement for more masters to assign identities so that the number of hops to reach a master is always sufficiently small to cause an insignificant delay.

In an alternative system of establishing a common identity, but employing the same principles described in relation to other methods, a peer-to-peer system can be utilised to assign identities. In such a system all domains in a network are able to assign a sub-set of identities and so an identity can be assigned immediately upon receipt of a request for content. The identities assigned by each domain are then correlated and related to each other in a database to allow a common identity to be established across a network of domains.

Figure 13 shows a flow-chart of a method of assigning identities utilised a peer-to-peer structure.

At block 130 a domain receives a request for content from a client. At block 131 the request is checked for the presence of a cookie, the presence of which indicates that the user has an identity on that domain. If the user does have an identity on the domain, at block 132 the client is redirected to another domain in the network, which checks, at block 133 for an identity on that domain.

If the user does not have an identity on the other domain, at block 134 an identity corresponding to that on the domain visited may be assigned by that domain. Alternatively, a different identity may be assigned and related to the user's identity on the domain visited by a database. Either of these steps, however, are optional and there it is not essential to assign an identity for the other domain since that domain has not yet been visited to retrieve content.

The client is then returned to the visited domain at block 135 and subsequently the requested content is served at block 1351.

If the user does have an identity on the other domain, that identity is ascertained and the relation of the two identities to the same user is recorded in a database (Block 136). Either of the identities may already be related to other identities of the user on different domains in the network, and so a mesh of related identities can be established across the network allowing a user to be identified at each of the domains.

If at block 131 it is established that the user does not have an identity on the domain visited, the client is redirected to another domain at block 137 to check, at block 138, for the existence of an identity on the other domain. If no identity is found, the client is redirected back to the visited domain at block 139 and a new identity is assigned by the visited domain and served together with the requested content at block 1300.

If at block 138 the user does have an identity on the other domain checked, the client is redirected at block 1301 back to the domain visited. The user's identity on the other domain may also be sent to the domain visited. At block 1302 an identity is assigned to the user and the requested content served. The identity assigned may be the same as that sent by the other domain, or alternatively may be a different identity which is then related to the other identity using a database, as has been described previously.

In addition to the above checking of one other domain for an existing identity, further domains may also be checked. By checking more domains, the completeness of the common identity is increased, but the time taken to do the checking is increased. It is also possible to check for other identities at different points to those shown in the methods above. For example, every time the user requests content, a check may be made of one or more domains.

The other domains checked in these methods may be selected at random, or may be selected according to a predetermined algorithm or pattern.

In order to increase the efficiency of relating identities, an indication may be provided in the cookie of the domains on which an identity has been established and related to the current identity. For example, in a network having 4 domains, each domain may assign an identity that includes an indication of the domain to which the identity is related, and a list of other domains to which that identity has been related. If the client visits domain A first, the identity assigned may be "Al". This indicates that the identity is for domain A that it is identity number I, and the absence of any other parameters shows that this identity has not been related to any other identities.

On a subsequent visit to domain A, the domain then picks another of the domains at random to check. If domain B is checked, and an identity is found and related to the A identity, the A cookie is updated to read "Al B2" and the database storing identity relationships is updated.

The "B2" part indicates that this identity is related to an identity number 2 on the B domain.

On a further visit to the A domain, it is apparent that the B domain has already been checked and so the domain elects to check either C or D. When the C domain is checked a C cookie containing "C3 D4" may be found, indicating that the user has an identity 3 on domain C and that that identity has been related to an identity 4 on domain D. These additional relationships are stored in the database and the A cookie can be updated to include "Al B2 C3 04", indicating that a complete set of identities has been established.

On subsequent visits to A, no checks for identities need be made as the A domain is aware that all identities are related to the A identity, thereby saving time and reducing unnecessary load on the domains.

At each of the above visits, the other cookies may also be identified. For example in the final visit to A, the C cookie may also be updated with the information already in the A cookie, such that the C cookie also indicates that the full set of relationships has been established.

The above example is only one example of possible methods of indicated established relationships between identities and there are many other possible schemes to provide the same functionality. For example, the cookies themselves may not be updated, but a database may be consulted by the domains to ascertain which relationships have already been established and to identify which other domains should thus be checked for related identities.

As per the above example, the identities assigned by each domain may include an indication of the domain that assigned them. This is a convenient method of providing an indication to other domains what the source of an identity is.

The inclusion of related identities in a cookie can also be utilised in conjunction with any of the other methods described herein to facilitate establishing a network of identities in an efficient manner.

In the foregoing description the identification services have been provided by the web-server serving the content for a given domain. Figure 14 shows an alternative configuration in which an identification system, independent of the web-server, is utilised to provide and manage identities.

Client 140 and domains 141 and 142 are conventional systems and operate as in a normal network. Identification systems 143 and 144 are connected to the network and are configured to communicate with client 140 and their respective domain 141 and 142. The routing information for domains 141 and 142 is set such that all requests for content from those domains are first directed to the respective identification system. The identification system passes those requests on to the respective domain, and then on the return of content from the web-server passes the content on to the client. An identity management database 145 may also be provided to maintain a database of identities and relations between identities, as has been explained previously.

The identification systems are configured such that they can view requests sent by the client, and in particular so that the identification system can view cookies for their respective domains, and pass cookies to the client for that domain. The identification systems thereby perform all of the functions described above as being performed by web-servers. Such a system allows the implementation of the identification methods described herein, without requiring modification of the operation of web-servers and without any additional load being placed on those servers. In Figure 14, one identification system is show for one domain, but one system may, in fact, serve multiple domains. For example, a hosting company who hosts a large number of domains may utilise a single identification system for all of the domains hosted on their servers.

The identification systems implement the above-methods by intercepting and, as appropriate, amending requests and responses from and to the client. Many of the steps of the methods described hereinbefore can be performed exclusively by the identification system.

Furthermore, some parts of the methods can be performed in parallel, thereby further improving the efficiency of the methods Figure 15 shows a flow-chart of a method of assigning a common identity utilising the network of Figure 14.

At block 150 a client 140 requests A.com/alpha.html without a cookie, because the user has not visited that domain before. At block 151 the request is intercepted and processed by identification system 143. The method then splits into two parallel paths to increase the efficiency of the system. However, it is also possible for the parallel steps to be performed sequentially, should that be required for any reason.

In a first path of the method at block 152 the identification system 143 responds to the client with a redirect B.com.interecept.html, together with a cookie for A.com containing an identity and a parameter indicating the identity assigned. The client requests intercept.html from B.com and includes the parameters giving the identity to be assigned. At block 153 the identification system 144 for B.com intercepts the request and at block 154 responds to the client with a B.com cookie corresponding to the identity passed by A.com together with a redirect to A.com/alpha.htrnl. At block 155 the client follows this redirect and requests A.com/alpha.html, which request is intercepted at block 156 by the identification system 143 for A.com.

The request for alpha.html is accompanied by a cookie and the identity of the cookie allows it to be correlated to the earlier request which began the process.

In the second path of the method at block 157 the identification system 143 for A.com passes the request for Alpha.html to A.com. At block 158 A.com serves alpha.html, which is stored by the identification system 143 for later transmission to the client.

Once the request of block 155 has been intercepted at block 156, and alpha.html has been received at block 158, alpha.html is served to the client at block 159.

The client has thus acquired both A.com and B.com cookies, and hence identities, and has also been served the requested content. The identification systems allow the efficiency of the system to be improved because parts of the method can be conducted in parallel and furthermore the tasks performed by the web-servers are significantly reduced. In this method, A.com only serves the requested page and B.com does not perform any steps. This is contrast to the implementation of the same method without the identification systems in which both A.com and B.com were required to perform a number of steps.

The identification systems only perform functions related to the establishment and management of identities and so can be configured particulaily to those functions. The systems can therefore perform the tasks more efficiently than web-servers, which must also perform large numbers of other tasks.

Any of the methods described herein may be implemented using identification systems.

Obvious modifications of the methods may be required in order that they work in conjunction with the identification systems and to ensure that they operate in the most efficient manner possible by making use of parallel paths in the methods and reducing the load placed on web-servers.

As will be apparent to the skilled person the above methods may be used in combination to provide the required assignment of identities. Furthermore, parts of the different methods may be combined.

As will be apparent to the skilled person, cookies sent by domains may contain additional information to the identity of the user to which they correspond. For example, cookies for a given domain may also contain information relating to the operation of a shopping system on that domain. The operation of the methods described herein is not affected by the inclusion of additional information in the cookie.

Where in the foregoing description reference has been made to assigning an identity to a client, this phrase is intended to describe the process of transmitting a cookie to the client having the identity.

In order to provide a more efficient assignment of identities, some or all of the domains used in the methods described herein may be domains that do not host any content, but are used purely in the assignment of identities. For example, it may be particularly beneficial for master domains to only be utilised to assign identities.

The domain and content names referred to throughout this document are used by way of example only and are in no way limiting.

Where reference is made to identities being the same, this does not necessarily require that the cookies sent relating to those identities are identical, but simply that there is a common feature of the two identities that indicates they are related to the same user. Furthermore, the relating of identities by a database has been described in relation to some of the methods described herein for which such a system is particularly suitable. However, such a database may be utilised in conjunction with any of the methods described herein to relate identities rather than using the same identities.

The term computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.

The methods described herein may be performed by software in machine readable form on a storage medium. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

This acknowledges that software can be a valuable, separately tradable commodity. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network).

Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.

It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. It will further be understood that reference to an' item refers to one or more of those items.

The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments of the invention. Although various embodiments of the invention have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.

Claims

Claims 1. A method of establishing a common identity for a user of a client computer in a network comprising a first domain and a second domain, the method comprising transmitting a first request from the dient computer to the first domain, receiving at the client computer a first identity for the user associated with the first domain and a first redirection instruction, wherein the first redirection instruction instructs the client computer to transmit a second request to the second domain, transmitting from the client computer to the second domain a second request and information relating to the first identity, and receiving at the client computer a second identity for the user associated with the second domain and a second redirection instruction, wherein the second identity is related to the first identity.
2. A method according to claim 1, wherein the second redirection instruction instructs the client computer to transmit a request to the first domain.
3. A method according to claim 1, wherein the network further comprises a third domain, and the redirection instruction instructs the client computer to transmit a request to the third domain.
4. A method according to claim 1, further comprising the step of transmitting from the client computer to the first domain a third request including the identity associated with the first domain, wherein the third request is a request for content, which content is also requested by the first request.
5. A method according to claim 4, further comprising the step of receiving at the client computer the content requested in the third request.
6. A method according to claim 1, wherein the first identity and the second identity are associated by containing a common item of data.
7. A method according to claim 1, wherein the first identity and the second identity are associated by a database, in which the relationship between the two identities is recorded.
8. A method according to claim 1, wherein the first request is transmitted in response to a third redirect instruction received from the second domain.
9. A method according to claim 8, wherein the client receives the third redirect instruction from the second domain in response to a fourth request to the second domain for content.
10. A method according to claim 9, wherein in addition to the second identity, the client receives content requested in the second request.
11. A method according to claim 1, wherein the first identity is related to an identity identified in the first request.
12. A method of establishing a common identity for a user of a client computer in a network compnsing a first domain and a second domain, the method comprising receiving at the first domain a first request from the client computer, ascertaining if the user of the client computer has an identity associated with the first domain, if the user does not have an identity associated with the first domain, transmitting from the first domain to the client computer a first identity for the user associated with the first domain and a first redirection instruction, wherein the first redirection instruction instructs the client computer to transmit a second request to the second domain, and the first redirection instruction is configured to cause the second domain to transmit to the dient a second identity for the user associated with the second domain, wherein the second identity is related to the first identity.
13. A method according to claim 12, further comprising ascertaining if the user of the client computer has an identity on a third domain, and relating the identity on the third domain to the user's identity on the first domain.
14. A method according to claim 12, wherein the step of ascertaining if the user of the client computer has an identity associated with the first domain is performed by ascertaining whether a cookie containing an identity was received with the first request.
15. A method of establishing an identity for a user, the method performed at a first domain and comprising the steps of receiving a request at the first domain from a client computer, if the request includes an identity for the user associated with the first domain, ascertaining if the user has an identity associated with a second domain of the network and if the user has an identity associated with the second domain, recording a relationship between the user's identities associated with the first and second domains.
16. A method according to claim 15, further comprising if the request does not include an identity for the user associated with the first domain, ascertaining if the user has an identity associated with a second domain of the network, if the user does have an identity associated with the second domain, transmitting to the client an identity associated with the first domain, wherein the identity is related to the identity associated with the second domain.