WO2006103616A1

WO2006103616A1 - Processing requests for content pages from deep-linking visitors

Info

Publication number: WO2006103616A1
Application number: PCT/IB2006/050923
Authority: WO
Inventors: Stephen M. Pitchers
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-03-30
Filing date: 2006-03-27
Publication date: 2006-10-05
Also published as: EP1955202A1

Abstract

A server (30) hosts a site comprising a plurality of content pages (33, 34) in a hierarchical manner beneath a main page (32). When server (30) receives a request to access a page which is at a level below the main page it determines whether the request originates from a user who has been referred from another site (a deep-link). Server (30) allows access to the requested page and modifies the content of the requested page. The page can be modified to include content based on the identity of the referring site and can include links back to pages of the referring site. Server (30) may allow restricted access to the requested page to that user for a limited period of time or a limited number of accesses.

Description

DESCRIPTION

PROCESSING REQUESTS FOR CONTENT PAGES FROM DEEP-LINKING VISITORS

This invention relates to a server which stores content pages, such as a web server, and to a method of processing requests for content pages from the server.

Interconnected data networks, such as the Internet, are widely used to obtain information. Servers host websites which offer a set of content pages. A basic principle of websites is that of linking between pages and sites so that a user can easily move from one content page to another, and from one website to another site. In this way, a user can easily find the information they are searching for.

Figure 1 shows two servers 20, 30 each connected 21 , 31 to a communication network 15 such as the Internet. Each server 20, 30 hosts a website which comprises a set of content pages 22, 23, 24, 32, 33, 34. The pages are accessible by browser software 11 on a user terminal 10 in a well known manner. Each page is associated with a Uniform Resource Locator (URL) which allows the page to be referenced by a browser. Each website hosted by a server 20, 30 has a home page 22, 32. The home page has a high-level Uniform Resource Locator (URL), such as http://www.philips.com. Other pages 23, 24, 33, 34 within each server are stored in a hierarchical manner beneath the home page. Pages typically comprise a collection of images and text with embedded links (hyperlinks) to the other pages on that server. A user can select a hyperlink, using their browser, to retrieve another page on the server. Pages within a single server 20 will typically include links to other pages within that server 20 (e.g. page 23 can include a link to page 24) and to home pages of other servers, such as the home page 32 on server 30. It is also possible to include direct links to pages on other servers which are positioned at a level beneath the home page. This practice is generally known as 'deep-linking'. Figure 1 shows an example of a deep link 25 between a page 23 on server 20 and a page 34 on server 30.

Some organisations are reluctant to allow deep links to pages on their website, instead preferring all visitors to navigate down through the hierarchy of pages from the site's own homepage. A server hosting a website can control deep-linking by refusing attempts to directly access pages beneath the home page or by requiring a user to enter authorisation data, such as a usemame and password, to access deep links. This restriction on the manner in which viewers are allowed to locate, reference and access web pages stands against one of the main positive effects of the Web, which is making information easy to find and retrieve. Users trying to access information via a deep link already know the page of most interest to them and they prefer to be taken there immediately. If such users are required to navigate down from the top level homepage of the site, they will experience a disincentive to access the information at all. Some websites are complex, with many levels, and it may be very difficult to locate the desired information by following the links down from the home page. The website owning the deep linked page thereby loses the opportunity of establishing a fruitful relationship with a new customer.

The present invention seeks to improve the way in which requests received from deep-linking visitors are processed.

Accordingly, a first aspect of the present invention provides a method of processing requests for content pages at a server which hosts a site comprising a plurality of content pages arranged in a hierarchical manner beneath a main page, the method comprising: receiving a request to access a page which is at a level below the main page; determining whether the request originates from a user who has been referred from another site; and, if so, allowing access to the requested page and modifying the content of the requested page. Rather than rejecting all requests to access pages beneath the home page from users who have been referred from another site, the server allows access to the requested pages and modifies the content of pages returned to users who reach the site in this manner. This can benefit the user, who receives content they would otherwise have been barred from accessing, and can allow the owner of the site to attract new users and to target content to the user. In this manner, visitors can follow a deep link to a site without any special prior set up or subscription on the part of the visitor.

Advantageously, the step of modifying the content of the page selects content to present in the requested page based on the identity of the referring site. This can include one or more links to pages of the referring site which are preferably links to pages beneath the home page of the referring site.

A second aspect of the invention provides a method of processing requests for content pages at a server which hosts a site comprising a plurality of content pages arranged in a hierarchical manner beneath a main page, the method comprising: receiving a request to access a page which is at a level below the main page; determining the identity of the user; determining whether the user has been referred from another site; and, if so, permitting restricted access to the requested page to that user.

The access can be restricted in terms of a limited period of time, a limited number of accesses to the requested page (or pages) of the site or a combination of these criteria. Both of these aspects of the invention solve a common problem of processing requests from users who are referred from another site. The first and second aspects of the invention can be combined with one another, and with any of the preferred features of the invention.

The functionality described here can be implemented in software, hardware or a combination of these. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed processing platform. Accordingly, another aspect of the invention provides a computer program product carrying instructions for implementing the method. The software may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium. The software may be downloaded directly to the server via a network connection.

Further aspects of the invention provide a controller for a server and a network server which perform the above method.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:-

Figure 1 schematically shows two websites and an example deep link between them;

Figure 2 shows a first embodiment of a method to process deep-linking requests; Figure 3 shows a registration page which can be presented to deep- linking visitors;

Figure 4 shows messaging between network entities; Figure 5 shows an example of customised content page; Figure 6 shows functional blocks within a server to implement an embodiment of the invention; and,

Figure 7 shows a further example of a customised content page.

Figure 2 shows a first embodiment of a method performed at a server 30 to control deep-linking between servers. The scenario shown in Figure 1 will be used as an example, where a user at terminal 10 makes a direct request to access content page 34 on server 20 after following a link 25 provided by page 23 on server 20.

The method begins 50 by the server 30 receiving a request to access a page stored on that server. A visitor may reach the page 34 by following a link from another page (e.g. page 33) on server 30 or by following a link provided by another server. Step 51 determines whether the request is from a deep-link visitor, i.e. a request to directly access a page at a level beneath the home page 32 which has been referred to the server 30 from another server 20. As will be described more fully below, messages exchanged between the server 30 and browser software 11 of the user identify the referring server 20. If the visitor is not a deep link visitor, then the requested page of content is delivered to the requesting user as normal at step 52 as the user is deemed to have navigated to that page from the home page. Returning to step 51 , if the user is determined to be a deep-linking visitor, then the method begins a process of monitoring and restricting access to the site for that user. At step 53 the method determines whether the user has visited before. This can be achieved by inspecting the IP address of the user, or searching for a cookie stored on the user's terminal 10. If the user is determined to be a new visitor to the site (i.e. user's IP address is unknown, and no cookie can be found on the user's terminal 10) then a new visitor record is created for the user. The requested page is returned at step 55 but this can be customised from the form that it would normally take for a regular visitor who navigated to that page via the home page 32.

If at step 53 the user is determined to have visited the site before, then the visitor record is retrieved at step 56. For a scheme which restricts access to a limited number of accesses, the visitor record can include a variable representing a total count of accesses to that page. Each time the user visits a particular page via a deep linking method, the count is updated. In this embodiment a user is allowed three deep-link accesses to the site, although this limit could be set to any desired value. At step 57 the method checks whether this limit has been exceeded and, if it has been exceeded, invites the user to register with the site at step 58 by displaying a registration page such as the one shown in Figure 3. If the user has not exceeded their guest privileges of three accesses, the server returns the requested page at step 59, preferably customised from the form it would normally take.

It can be seen that with this scheme deep linking is encouraged, rather than forbidden. The web server 30 uses information about the deep link visitor to control access to the information on their website and to customise the pages returned in reply to a request. Allowing this kind of access can be a good advertisement for the organisation's website, allowing potential customers to learn about the organisation and discover the benefits of their website. This will encourage users to register formally in order to be promoted to full access privileges. If instead the website refuses to serve any information at all to a deep link viewer, a potential customer will be lost.

The embodiment shown in Figure 2 combines two aspects of this invention: allowing access to deep-linking users for a limited period of time (or number of accesses) and customising content of pages for deep-linking users. Either of these aspects can be used in isolation. For a scheme which only limits deep-linking accesses, the steps 55, 59 return normal content rather than customised content. For a scheme which only customises content, then steps 53-58 are not required.

In the embodiment shown in Figure 2 a user is restricted to a limited number of deep-link accesses to a particular page, or set of pages, on the site. An alternative to this is to restrict a user to a particular time duration of deep- link accesses to the page, or set of pages, on the site. The method of controlling the server is similar to that shown in Figure 2, except that the visitor record stores a variable indicating the first time at which the user accessed the site, and this variable is compared with the current time at step 57. When the difference between the current time and the time of first access exceeds a predefined duration (e.g. 7 days), the user is barred from accessing the requested content. In a further embodiment the limits of the restricted access can take the form of a combination of a limited number of accesses and a limited time duration. The visitor record stores variables representing both number of accesses and the time of first access. In this way, the user is barred from accessing a page when either of the limits is exceeded (e.g. 3 accesses or 7 days.)

The method shown in Figure 2 can apply to a single content page, to a group of content pages or to all content pages on the site which are accessed in a deep-linking manner. Similarly, the restriction on user access can be set on a per content page basis, with a user's access to each content page being monitored and restricted on an independent basis from other pages. Thus, a page representing a premium service offered by the site (e.g. directory enquiries) may restrict the number of deep-link user accesses, while other pages may not impose a limit, or may impose a different limit on the number of user accesses according to the their value. Alternatively, the limit can be an overall limit to deep-linking access to any of a group of content pages of the site.

In Figure 2, the content of pages returned to users who accessed the site via a deep link at steps 55, 59 is customised compared to the normal content of the page. The content can be customised based on the identity of the referring website. Figure 4 shows some of the messaging exchanged between server 20, browser 11 and server 30. A user is browsing content pages on server 20. A user requests 71 a page (e.g. page 23, Figure 1 ) and the contents of this page are downloaded to the browser 11 at step 72. Part of the downloaded data is an identity of the server (site) 20. The user then decides to select a deep link on the downloaded page 23. This causes the browser 11 to issue an HTTP GET message 74 which is sent to server 30 hosting the requested page. The parts of the GET message that are particularly relevant to this invention are: the URL of the requested page (http://bbb/pageyy), a field REMOTE-ADDR which identifies the IP address of the terminal 10 on which the browser is running and a field HTTP_REFERER which identifies the URL of the "referring page." This is the URL of the page carrying the hyperlink to the page now being requested. In this example, HTTP_REFERER is http://aaa/pagexx. At step 76 server 30 returns an HTTP message which carries the contents of the requested page. The REMOTE- ADDR and HTTP_REFERER fields in the GET message 74 can be used to determine visitor information for the purposes of controlling access and customising the HTTP message.

The content pages that are delivered by server 30 can either be prepared in advance and stored in HTML format, or generated on-the-fly using scripts such as Common Gateway Interface (CGI) scripts. Both of these techniques are well known to the skilled person and do not require further explanation. The customised versions of content pages that are returned to deep-linking visitors can be separate versions of regular pages, which are prepared in advance and stored at the server 30, or the page-generating scripts can receive an instruction which varies the content of a page depending on whether or not the visitor is a deep-linking visitor. The customisation of content pages can take various forms. Figure 5 shows an example of a simple page layout 80 comprising regular content 82 and a banner 81 carrying content which is customised according to the identity of the referring site. Banner 81 can carry advertising that is considered to target the user, based on the identity of the referring site which the user previously visited. If the requested page usually carries third party advertising, this could be replaced by an advert for the organisation's own website or an invitation of the type shown as box 62 in Figure 3 to subscribe to the site. The customisation can be more complex, with the selection of text, images and other content throughout the page being varied according to the identity of the referring server. As noted above, server 30 receives a field HTTP_REFERER which identifies the referring site and the page on the referring site. Server 30 can customise the content of a page based on just the identity of the referring site (e.g. advert A for any visitors following a deep link from site http://aaa). Alternatively, server 30 can customise the content of a page based on the identity of the page of the referring site (e.g. advert A1 for any visitors following a deep link from page http://aaa/page1 , advert A2 for any visitors following a deep link from page http://aaa/page2 etc.)

Referring again to Figure 2, step 51 of the method determines if the visitor is a deep-link visitor by inspecting the HTTP_REFERER field of the messaging 74 exchanged between the visitor's browser 11 and server 30. It is also possible to use cookies to track whether a user has visited the home page of the site. A cookie is set on the visitor's browser when a user visits the home page of the site. When a user subsequently follows a link to a page lower down the hierarchy of the site, the presence of the cookie on the user's terminal indicates that the user has visited the home page. To be sure of identifying a deep link access, a site may insist on cookies being enabled as a condition of returning content pages. There are several possible scenarios, depending on how the visitor arrived at the current page beneath the home page. Table 1 shows four possible categories of visitor.

Table 1 - identifying deep-link visitors

For category (a) visitors the HTTP_REFERER field received from the browser 11 identifies the same site. This indicates the visitor has followed a link from the same site. This is definitely not a deep-link visitor. For category (b) visitors the HTTP_REFERER field received from the browser 11 identifies another site. This is definitely a deep-link visitor. For category (c) and (d) visitors the HTTP_REFERER field is empty. This could indicate that the user is following a link stored in their browser - often called a 'bookmark' or 'favourite'. However, without additional information it is difficult to determine whether the bookmark was originally set from a deep link or not. Cookies can be used to help disambiguate this case. If server 30 operates in a manner where it instructs a visitor's browser 11 to store a cookie when the user visits the site's home page then the presence of the cookie (or a value set within the cookie) can be used to determine more accurately whether the visitor has followed a deep-link or not. If the HTTP_REFER field is blank but the visitor's machine has a cookie set to indicate that the home page has been visited, then the visitor is treated as a normal visitor. If the HTTP_REFERER field is blank and there is no cookie indicating that the home page of the site has been visited, then this is highly indicative of the visitor having followed a deep link. The way in which visitors falling into categories (iii) and (iv) are treated can be set by the owner of the site hosted by server 30. The owner may only wish to modify content of pages, or restrict access to pages, to category (ii) visitors. Alternatively, the owner may choose to modify content of pages, or restrict access to pages, to category (ii), (iii) or (iv) visitors who are, or may be, following a deep-link.

Figure 6 shows the functional blocks required to implement the invention at a server 30. The server 30 includes a controller shown generally as 95. The server 30 has a network interface 91 which receives data packets from network 15. The data packets will typically be carried as IP packets over a data link protocol used by the network 15. Higher level protocols such as TCP and HTTP or FTP control the end-to-end transmission of the packets between network entities. Requests for content pages are screened by a deep-link visitor detection function 92, which implements the method shown in Figure 2, or one of the variants of this method described above. The detection function 92 accesses a store 93 to store a visitor record for each identified visitor and to update those records as visitors return to the site. A further type of record may store a log of referring websites. Allowable requests for content pages are forwarded to a page creation/retrieval function 96. The requests specify whether a 'normal' or a 'customised' page is required. Alternatively, if a visitor has reached the limits of their restricted access, the requests may specify that the page creation/retrieval function 96 should deny access to content pages. The page creation/retrieval function 96 creates content pages using stored scripts, or retrieves previously created pages, using content retrieved from a store 98. Store 98 also stores content used in customising the pages.

There are several ways to identify a particular visitor for the purposes of detecting how many times they access the site via a deep link. The two main methods are (i) visitor's IP address and (ii) cookie-based method. Each method has it's associated advantages and disadvantages. In method (i) the server 30 stores the IP address from which the request was received. This will usually be the address of the user's terminal but in some cases, such as where the user is communicating via a proxy server, the address will not be a reliable indication of the user. An advantage of using the IP address is that browsers without cookies enabled will still be able to access the site. In method (ii) server 30 instructs the user's terminal 10 to store a cookie. By subsequently checking for the presence of the cookie on a terminal requesting access to a page, the server 30 can precisely identify a particular user. In cases where multiple viewers appear to be coming from the same IP address, such as when a proxy server is used, a combination of these methods can be employed in order to maximise the chances of being able to recognise returning visitors.

To be sure of identifying a deep link access, a site may insist on cookies being enabled as a condition of returning content pages. Cookies can also be used to track whether a user has visited the home page of the site. On accessing the home page server 30 instructs the user's machine 10 to store a cookie which carries a flag indicating that the home page has been visited. When subsequently accessing a page further down the hierarchy the server 30 checks whether the user's machine has a cookie with the flag set to indicate that the home page has been visited. If the flag is set, then the normal (non deep link) version of the page is returned. Other ways of identifying a user can be used. The choice of identification method is not important as long as it allows visitors to be recognised and monitored accurately enough for the purposes of implementing the website's own access policy.

As described above with reference to Figure 6, the deep link visitor detection function 92 can maintain a log of which sites are referring visitors to the site, with information such as visitor numbers, date and time of visit. This information can be used to negotiate an access arrangement between the owner of the site hosted by server 30 and other sites. As an example, the site hosted by server 30 may subsequently decide to allow unlimited access to visitors who reach the site via the site hosted by server 20. Alternatively, registration data could be shared between the two organisations, allowing better tracking of customers' needs leading to a better service from both organisations.

Another illustration of how referrer information can be mutually beneficial to all parties is the following scenario. Suppose a user is seeking to buy an appliance (say a food mixer). The user follows a link from a retailer's website (hosted by server 20) which is selling that appliance to a page of the site of the manufacturer of that appliance (hosted by server 30) for information regarding the appliance. The manufacturer's page 100 is shown in Figure 7. The normal content of the page for the item is shown as 102. Server 30 recognises the identity of the referring site and modifies the margins of the content page it would normally present for that item to present a set 104 of return deep links (105-108) showing other appliances from the manufacturer that can also be bought from the retailer who referred the user. It is advantageous that the owners of sites hosted by servers 20, 30 co-operate with one another in establishing a set of acceptable return links. This would ensure that the owner of the site hosted by server 20 maintains the pages that are referred to in the set 104 of return deep links. However, this co-operation is not essential. The return deep links can be created by an automatic search engine, which searches for relevant pages on the referring site to link to, or by manually finding appropriate pages. Where a large set of return links are possible (e.g. in the example above the retailer owning the site hosted by server 20 stocks many similar products produced by the manufacturer owning the site hosted by server 30) a sub-set of links can be presented to a user as set 104. The set 104 can be chosen on a random basis from the overall set of suitable links.

Where the site hosted by server 30 directly sells products, it is also possible for the site to recognise the identity of the referring site and to modify the offer price of the product so that it is cheaper than the price known to be offered by the referring retailer. In the examples described above two websites have been shown which are each hosted by a respective server 20, 30. It will be appreciated that a single server may host multiple websites, and the method will still operate under these circumstances by inspecting the URL of the referring site, since the URL will be different for each site hosted by a common sever.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words "comprising" and "including" do not exclude the presence of other elements or steps than those listed in the claim. Where the system/device/apparatus claims recite several means, several of these means can be embodied by one and the same item of hardware.

In the description above, and with reference to the Figures, there is described a server 30 which hosts a site comprising a plurality of content pages 33, 34 in a hierarchical manner beneath a main page 32. When server 30 receives a request to access a page which is at a level below the main page it determines whether the request originates from a user who has been referred from another site (a deep-link). Server 30 allows access to the requested page and modifies the content of the requested page. The page can be modified to include content based on the identity of the referring site and can include links back to pages of the referring site. Server 30 may allow restricted access to the requested page to that user for a limited period of time or a limited number of accesses.

Claims

1. A method of processing requests for content pages at a server (30) which hosts a site comprising a plurality of content pages (33, 34) arranged in a hierarchical manner beneath a main page (32), the method comprising: receiving a request to access a page which is at a level below the main page (32); determining whether the request originates from a user who has been referred from another site; and, if so, allowing access to the requested page and modifying the content of the requested page.

2. A method according to claim 1 wherein the step of modifying the content of the page comprises including an invitation to subscribe to the site.

3. A method according to claim 1 or 2 wherein the step of modifying the content of the page comprises selecting content to present in the requested page based on the identity of the referring site (20).

4. A method according to claim 3 wherein the step of modifying the content of the page comprises including a return link to a page on the referring site (20).

5. A method according to any one of the preceding claims further comprising determining the identity of the user (10) and permitting restricted access to the requested page to that user.

6. A method according to claim 5 further comprising creating a record for a new user, updating the record when the user subsequently visits the site and using the record to determine when the user has reached a limit of the restricted access.

7. A method according to claim 5 wherein the restricted access comprises permitting the user to access the requested page for a limited period of time.

8. A method according to any one of claims 5 to 7 wherein the restricted access comprises permitting the user to make a limited number of accesses to the requested page.

9. A method according to any one of claims 5 to 8 wherein the restricted access is permitted to a set of pages of the site.

10. A method according to any one of claims 5 to 9 further comprising denying access to the requested page to the user when the limit of the restricted access is reached.

1 1. A method according to any one of claims 5 to 10 further comprising inviting the user to subscribe to the site before, or after, the limit of the restricted access is reached.

12. A method according to any one of the preceding claims wherein the step of determining whether the request originates from a user who has been referred from another site includes determining whether the user has a cookie stored on their terminal which indicates that the main page of the site has been visited.

13. A method of processing requests for content pages at a server (30) which hosts a site comprising a plurality of content pages (33, 34) arranged in a hierarchical manner beneath a main page (32), the method comprising: receiving a request to access a page which is at a level below the main page (32); determining the identity of the user (10); determining whether the user (10) has been referred from another site; and, if so, permitting restricted access to the requested page to that user.

14. Instructions for causing a server to perform the method of any one of the preceding claims.

15. A computer-readable carrier storing the instructions of claim 14.

16. A controller for a server, the server being operable to store a plurality of content pages in a hierarchical manner beneath a main page and having a network interface for receiving user requests for pages from a network, the controller being operable to perform the method according to any one of claims 1 to 13.

17. A network server (30) comprising: a store (98) for storing a plurality of content pages (33, 34) in a hierarchical manner beneath a main page (32); a network interface (91 ) for receiving user requests for pages from a network (15); and, a controller (95) which is operable to control operation of the server (30), the controller (95) being operable to perform the method according to any one of claims 1 to 13.