WO2005083971A2

WO2005083971A2 - Content delivery

Info

Publication number: WO2005083971A2
Application number: PCT/GB2005/000706
Authority: WO
Inventors: Ceri Hughes; David Evans; Chris Bardsley; Mark Combellak
Original assignee: Yes Television Plc
Priority date: 2004-02-26
Filing date: 2005-02-25
Publication date: 2005-09-09
Also published as: GB0404279D0; GB0616882D0; WO2005083971A3; GB2411534A; GB2429386A

Abstract

An audio-visual content delivery system for delivering audio-visual content to a user terminal, such as a set top box, is disclosed, which comprises an object database for storing data relating to the audio-visual content, and means for accessing the audio-visual content in dependence on the data. Aspects of the invention find particular application in the area of video-on-demand and pay-per-view television systems. Methods of delivering audio-visual content to user terminals and a method of managing user access to a set of data are also described.

Description

CONTENT DELIVERY

This invention relates to content delivery and in important examples to systems for the delivery of audio-visual content. Modern audio-visual content delivery systems can often provide content delivery services that are in many ways more advanced than traditional broadcast services. Some examples of audio-visual content delivery systems include video-on-demand and pay-per-view television systems, music download services, and the like. Such systems often provide access to large amounts of audio-visual content. Managing such large amounts of content can be difficult and inefficient, since large amounts of information relating to the content must be stored and processed. Substantial or frequent changes to the content offered by the system and to the presentation of that content can be costly in terms of the time and effort involved, often requiring one or more permanent staff to maintain the system and carry out the changes. This can significantly increase the cost of providing such a system, and even make the cost of implementing such a system on a small scale - such as within a hotel or hospital - prohibitive. Maintaining the efficiency and performance of such a system can also be difficult, in particular where a central content delivery system concurrently provides services to a large number of users, in which case the system can become slow and frustrating, or even impossible, to use. Although technological limitations can sometimes be overcome by the provision of more capable hardware, this can significantly increase the overall cost of providing such a system. It is an object of certain aspects of the invention to provide improved methods and apparatus, which address some of the above and other problems. Accordingly, in a first aspect of the invention, there is provided an audio-visual content delivery system for delivering audio-visual content to a user terminal, comprising an object database storing data relating to the audio-visual content; and means for accessing the audio-visual content in dependence on the data. This can allow for more efficient management of data relating to audiovisual content. The user terminal may, for example, comprise a set top box (STB), a personal computer, a television set or other device. Object databases are also sometimes referred to as object-oriented databases. The object database preferably stores an object representing a screen display. This can improve organisation and flexibility of the system. The screen display object is preferably associated with at least one of: text data, image data, user interface definition data, and audio-visual content, and may further be associated with user interface definition data comprising link data defining a user-selectable link to a further screen display object. The screen display object may also be associated with sound data. The audio-visual content delivery system preferably further comprises means for generating screen display information in dependence on the screen display object; and means for outputting the screen display information. The means for outputting screen display information may advantageously comprise means for outputting access information for accessing an audio-visual content item. Preferably, the database further stores an object representing an audio-visual content item associated with the screen display object and comprising access information for accessing the audio-visual content item. For example, the access information may comprise a source specifier specifying the source of the audio-visual content item. By storing access information in the database, greater flexibility can be provided as to where the content item itself is stored, and the management of information in the database can be simplified. The audio-visual content item preferably comprises an audio-visual content file or an audio-visual content stream, and the source specifier specifies the source of the audio-visual content file or the audio-visual content stream. To this end, the source specifier may comprise a filename or a Uniform Resource Locator (URL). In this way, the content item can be stored separately from the database, which can improve efficiency. Advantageously, the object database stores an object representing a content asset, and the content asset object comprises information relating to the content asset and is associated with audio-visual content. The information preferably comprises at least one of: availability information, pricing information and categorisation information. A content asset is preferably a unit of audio-visual content, and optionally related information, which is to be offered for selection, purchase and/or rental to users of the system. The content asset object is preferably associated with a screen display object representing a screen display. Preferably, the audio-visual content delivery system further comprises means for receiving a request specifying the content asset; means for accessing the content asset object in response to the request; means for identifying audio-visual content associated with the object; and means for initiating delivery of the associated content. The audio-visual content delivery system may further comprise means for initiating a payment transaction in response to the request. The object database preferably stores a carousel object which is associated with a screen display object representing a screen display, and wherein the carousel object defines a sequence of audio-visual content items to be played back in the screen display. The order of the content items in the sequence may be predetermined and fixed by the carousel object, or may be specified as random, in which case the order is determined randomly, for example at the time of playback. Alternatively or in addition, the carousel object may specify content which is to be selected dynamically (at playback time) in dependence on pre-determined criteria, the criteria preferably being specified at least partially by the carousel object. The object database may further store a channel object representing a group of content assets. In this way, information in the database can be structured more effectively, which can improve the efficiency of the system. Content delivery systems, in particular video-on-demand systems are usually provided separately from regular broadcast services, despite often being accessed via the same viewing equipment. This can make it more difficult for users to obtain desired information regarding the large amount of programmes typically on offer in either kind of service. In a further aspect of the invention, there is therefore provided a method of delivering audio-visual content to a user terminal, the method comprising: retrieving asset data from a database, the asset data specifying an audio-visual content asset to be represented in a menu; receiving programme data relating to a plurality of broadcast programmes broadcast on a broadcast network; selecting data relating to one of the plurality of broadcast programmes from the programme data in dependence on predetermined criteria; generating a menu having a first menu item representing the specified asset and a second menu item representing the selected programme; and transmitting the menu to the user terminal. The asset data may specify the audio-visual content asset by referring to a specific asset, or by providing criteria using which one or more assets matching the criteria can be identified, for example by searching asset data in the database using the criteria. The programme data may comprise data specifying a programme category associated with each programme, in which case the predetermined criteria preferably include the programme category. Alternatively or in addition, the programme data may comprise data specifying a broadcast time associated with each programme, in which case the predetermined criteria preferably include the broadcast time. Other criteria may also be used, such as age restrictions, specific actors appearing in the programmes, or any other information contained in the programme data. In a typical audio-visual content delivery system, the content offered to the user changes relatively frequently. For example, in a system offering "on- demand" access to movies, new movies may be added as they are released for this form of delivery. Old movies may also be frequently removed. This can require substantial and continual effort by the service provider in updating content information stored in the system. Regular updating of the system can also lead to disruption to the system and hence the user. In a further aspect of the invention, there is therefore provided a method of delivering audio-visual content to a user terminal comprising: receiving asset data relating to an audio-visual content asset, the asset data comprising a validity date; comparing the validity date to a given date; generating a menu in dependence on the outcome of the comparison; and transmitting the menu to the user terminal. The data preferably comprises data defining a date range, and generating the menu comprises comparing a given date to the date range, and generating a menu item relating to the asset if the given date lies within the date range. The given date is preferably the present date, although other dates may also be used, for example for testing purposes. Advantageously, receiving asset data comprises receiving an asset specifier, and retrieving the asset data from a database in dependence on the asset specifier. Receiving an asset specifier may comprise receiving menu definition data comprising the asset specifier, and the method preferably further comprises generating the menu in dependence on the menu definition data. Alternatively, receiving an asset specifier may comprise receiving menu definition data comprising one or more asset criteria, and selecting an asset in dependence on the criteria. In this way, disruption caused by addition and removal of content can be reduced, and content can be added and removed ahead of time, which can improve efficiency. From time to time, the content provider may also wish to make more substantial changes to the service, for example by adding new channels, redesigning the visual appearance of a channel and so on. In some types of content delivery, such as web sites, it is common for the service to be simply taken off-line to permit such changes. In a television service, however, users expect constant availability. However, updating a service without taking it offline can lead to a variety of problems. For example, a user may find themselves in a redesigned service part way through a transaction or whilst navigating towards a particular piece of content. This will likely result in user dissatisfaction and may have content management or access issues. The option of increasing the time interval between updates so as to reduce the probability of user activity occurring during an update, would in many systems restrict the range of content that could be offered to users and also limit the rate at which improvements and modifications can be made to the system. In a further aspect of the invention, there is therefore provided a method of managing user access to a set of data, the method comprising: storing a plurality of data versions, each data version being a version of the set of data and having associated with it a time specifier specifying a validity time for the data version; receiving an access request relating to the set of data from a user; in response to the request, selecting in dependence on a predetermined criterion either the data version most recently accessed by the user or the data version having the most appropriate validity time; and providing access to the selected data version to the user. Advantageously, the method further comprises retrieving information relating to an access request previously received from the user, the predetermined criterion comprising an indication of whether the previous access request related to the same set of data as the request. Alternatively or in addition, the predetermined criterion may comprise the time elapsed since a previous access request received from the user. Other criteria may also be used, for example which data within the set of data the access request relates to. Providing access to the selected data version preferably comprises outputting a specifier specifying the selected data version. Alternatively or in addition, the specifier may specify the storage location of the selected data version. The set of data may be a service area in an information service, and the data versions may be versions of the area. Preferably, the set of data is a section, area or channel of a content delivery system, for example a channel in a content delivery system as described herein, and the data versions are versions of the section, area or channel. In a further aspect of the invention, there is provided a method of managing user access to a channel in a content delivery system (the channel preferably being one of a plurality of channels available in the content delivery system), the method comprising: storing a plurality of channel versions, each channel version being a version of the channel and having associated with it a time specifier specifying a validity time for the channel version; receiving an access request relating to the channel from a user; in response to the request, selecting in dependence on a predetermined criterion either the channel version most recently accessed by the user or the channel version having the most appropriate validity time; and providing access to the selected channel version to the user. The invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein. The invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein. The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which :-

Figure 1 illustrates the architecture of an audio-visual content delivery system; Figure 2 illustrates the basic object structure used to store information relating to audio-visual content; Figures 3, 4 and 5 are examples of menu screens displayed by the audio-visual content delivery system; Figure 6 illustrates the generation of a menu screen; Figures 7 and 8 are examples of object structures used in the audiovisual content delivery system; Figure 9 illustrates a rolling update system for managing access to and updating of information in a service; Figures 10, 11 and 12 show area mapping tables used by the rolling update system; Figures 13 and 14 illustrate the processing of access requests by the rolling update system; Figure 15 illustrates the processing of update requests by the rolling update system; Figure 16 illustrates the deletion of information from the service; and Figure 17 illustrates the use of the rolling update system in the context of the content management system.

System overview

The audio-visual content delivery system described herein provides a content delivery service in which audio-visual content is made available to users of the system. The system displays information relating to audio-visual content to users and receives requests for access to content. In response to such requests, the system carries out payment transactions (such as charging to a user account or credit card) and initiates delivery of the requested content. The audio-visual content delivery system may be deployed in a variety of contexts, for example as a local system in a hotel, hospital or the like, or as a residential system, for instance via a cable television network. It may also be implemented as an Internet-based content delivery system. The architecture of the audio-visual content delivery system will now be described in overview with reference to Figure 1. Audio-visual content delivery system 100 comprises a management server 104 for managing user and content information. Management server 104 is connected to object-oriented database 102 which provides permanent storage for the system information. Object-oriented database 102 is typically managed by an object-oriented database management system, which is here considered to form part of the database. Examples of object-oriented database management systems (OODBMS) include Versant (TM) and 02 (TM). The OODBMS manages the physical storage of, and access to the actual data. Object database 102 may reside on the same physical server computer as the management server 104, or on a separate server. The management server 104 is connected via a request server 106 to a network, in the present example an Internet Protocol (IP)-based network 120. A hybrid fibre coax (HFC) network or other type of network may also be used. The IP-based network may, for example, be the Internet. Alternatively, where the content delivery system is provided in a hotel, hospital or the like, some form of local network may be used. Also connected to IP network 120 are content server 110 and broadcast server 108. Content server 110 provides digital storage and streaming services for audio-visual content such as films and music videos. These are typically stored in a compressed format, for example in an MPEG or Windows Media (TM) format. A plurality of user terminals in the form of set top boxes (STBs) are also connected to IP network 120, of which an exemplary STB 112 is shown. STB 112 is connected to a display 114, such as a television set. The STB communicates with the management server 104 via IP network 120, over which it also receives audio-visual content streams from broadcast server 108 and content server 110 for output to display 114. The operation of the STB 112 is controlled by a user 116, for example using a remote control or keyboard. Different types of STBs can be used simultaneously within the same system (for example, STBs made by different manufacturers). In addition, the functions of an STB and its associated display may be carried out by a different device, for example a Personal Computer (PC), a Personal Digital Assistant (PDA) or a mobile telephone. In operation, STB 112 sends requests to request server 106 over IP network 120 in response to interaction with user 116. Requests may typically comprise information relating to keys on a remote control activated by user 116 in response to a menu displayed on display 114. The request is passed by the request server to management server 104, which processes the request and produces a response, typically comprising display instructions for creating a screen display to be displayed to the user. In doing so, management server 104 retrieves information from object database 102, and updates the information in the database as required. In an example, if the request relates to accessing a particular piece of content, management server 104 retrieves information relating to the piece of content and carries out other related tasks, for example checking the user's access rights and performing billing activities. The information sent back to the STB 112 comprises content access information, for example the file name of a piece of audio-visual content and its storage location on content server 110, expressed as a Uniform Resource Locator (URL). Using this information, the STB then communicates directly with content server 110 to arrange for the requested piece of content to be streamed to the STB. Alternatively, where access to a broadcast channel is required, the STB connects to the broadcast server 108 to receive the relevant broadcast stream. The elements of the system will now be described in more detail.

Object database The object database 102 stores user information and content information. User information comprises user account information and user state information. User account information includes information such as a user's address, billing information and service subscriptions. User state information describes the current state of the user's interaction with the system. This includes which screen they are currently viewing (for example a menu screen) and any content they are currently watching (for example, a film). Where a user has interrupted the watching of a particular piece of content, the user state includes an indication of the position within the piece of content at which viewing was interrupted. This enables the viewing to be resumed at a later time. Content information includes information on what content is available in the system, how to access it, and how that content in structured into channels and particular content offerings. A content offering is a particular item of content or grouping of content items presented to a user as a single unit, and which may be selected, purchased and/or viewed by the user as a whole. For example, a content offering may represent an episode of a television series, or the television series as a whole. Content offerings are also referred to as content assets, or simply assets. Channels are groupings of content assets, typically grouped thematically. For example, a sports channel may comprise sports-related content assets, whilst a movie channel contains films. The representation of content in the object database will be described in more detail below.

The management server The management server 104 manages the interaction with the user of the system. Communication between STB 112 and management server 104 is not session-based, but occurs on a request-by-request basis, with user state information being updated in object database 102 after each request to ensure correct interaction. This can be advantageous since in a content- delivery system as described, STBs are typically permanently connected to the management server, or at least connected for long periods of time. Each request handled by management server 104 therefore identifies the user making the request; and in determining how to respond to a given request, the management server makes use of the user state information stored for the given user making the request in object database 102. For example, when receiving a request relating to a key press from a user, the management server determines the last screen that was displayed to the user from the state information. This enables the management server to determine the intended meaning of the key press and the appropriate response. This may, for example, be the display of a further screen, such as a content synopsis screen, providing a synopsis of a piece of content previously selected. The new screen is then transmitted to the user, and the user state information in the object database 102 is updated accordingly. The management server is unaware of the particular type of STB used by the user. The information sent to an STB by the management server is adapted for the particular users' STB by the request server 106. The management server also receives programme data describing the programmes due to be broadcast over a certain period of time on a number of broadcast television or radio channels available to the system, from a broadcast information source 130. Typically the broadcast information is in the form of EPG (Electronic Programme Guide) data such as that used in digital broadcasting systems, and includes information such as the broadcast channels and times of programmes, programme categories, types or genres, age restrictions, programme descriptions, information on actors and directors, and the like. This information is stored in the object database 102.

Request server The request server 106 manages the communication between the

STBs and the management server 104. It passes requests received from STB 112 to management server 104. It also receives information from the management server and converts it into a format that can be displayed by the STB. Specifically, the request server converts the response from the management server 104 into an HTML page for display on the user's STB. The look and feel of the generated HTML page is defined independently of the management server's response. In this way, it is possible to take advantage of the strengths of each STB platform without limiting the management server to a particular platform. It also enables multiple types of STB to be connected to the same management server. While the information received from the management server specifies the different visual elements which are to be displayed, such as buttons, images, and text, the request server determines how and where to display these on the HTML page in dependence on the target STB platform. This process of rendering the response takes into consideration the capabilities of the STB, which tend to differ between STB platforms. Some of these differences include: • Different versions of the HTML standard. For example, a particular STB may support HTML version 3.2, while another supports HTML version 4. • Different graphics layer sizes. • Known problems or errors in the STB browser implementation • Video control code to start and stop the playback of audio-visual data tends to differ between STB platforms. The request server includes different JavaScript code in the HTML output to handle video control based on the STB type. Content server The content server 110 provides storage for the audio-visual content files, and receives and handles requests for the streaming of files. In response to a request for an audio-visual file from an STB, the content server accesses the requested file and streams it to the STB. The content server may be implemented using conventional media server and streaming technologies.

Broadcast server The broadcast server 108 receives digital broadcasts (in particular TV and radio broadcasts), for example from a digital terrestrial, cable or satellite network, and streams these to STBs on request. The broadcast server may also receive analogue broadcasts which are encoded and compressed for streaming using suitable encoding / compression technologies, such as those based on the MPEG standards.

Set top box STB 112 is a set top box capable of receiving and displaying HTML pages and audio-visual data streams over an IP-network such as the Internet.

The STB typically comprises means for connecting to TV sets, video recorders, Hi-Fi systems and the like for playback of the audio-visual material.

The set top box functionality may also be provided by a PC, for example using web browser software. In a preferred embodiment, multiple different types of STB may use the content delivery system simultaneously. In this case, the management server stores information identifying the type of STB used by a given user in the object database as part of the user account information. Using this information, the output generated by the management server is tailored to the given STB by request server 106. The different elements of the system need not be provided on physically separate server computers. For example, the request server may operate as a software process running on the management server. Generally speaking, multiple - or even all - functions may be combined in a single server computer as appropriate. Example The following describes a typical sequence of steps performed when a user presses a button on the remote control associated with their STB in order to select an option or activate a function in response to a screen displayed to the user. The example assumes that the STB is connected to the system and is displaying a screen having a number of options, for example, a menu screen, and that the management server is operational and awaiting requests from users of the system. Step 1 : The user 116 presses a button on their remote control. In response, the STB 112 sends an HTTP request to the request server 106 over the IP network 120 specifying the button pressed. Step 2: The request server 106 receives the request from the user's STB and forwards the request to the management server 104 for processing. Step 3: The management server 104 receives the request from the request server 106 and performs any necessary security checks to authenticate the user. Step 4: Once the user is identified, the request server retrieves user information for the user from the object database 102. This user information includes the following information: • The user state information, including the channel and screen that the user is currently viewing; • The account information for the user, which includes, for example, information concerning subscriptions, previous rentals, etc. Step 5: The management server 104 then processes the user's request. This involves identifying which option the user has selected in dependence on the remote control button pressed, and taking the appropriate action in response. This may include navigating to a new screen, purchasing a movie, validating a credit card or PIN, etc. Step 6: Once the appropriate action has been identified and carried out, the user's state information is updated, and the updated information is stored in object database 102. This ensures that the information is available to the management server when it next receives a request from the user's STB. Step 7: The management server 104 generates a response and transmits it to request server 106. This response contains information such as: • The type of screen that should be used to display the response, for example, the response may be in the form of a menu screen, synopsis screen, credit card screen, etc. • The text, images and buttons to display on the screen • Which buttons on the handset can be used to interact with the screen • The list of audio-visual content items that should be played on this screen • Whether transport controls (such as rewind, pause and fast forward) are enabled for each content item. Step 8: The request server 106 generates an HTML page based on the screen type and other information specified in the response. The HTML page is tailored to the type of STB used as described above. Step 9: The request server 106 transmits the HTML page to the user's STB 112. The STB displays the HTML page on the screen 114 connected to the STB. Step 10: The user's STB 112 contacts the content server 110 and requests any audio-visual content items specified in the response. The content server 110 streams the requested content items to the STB, where they are displayed on the screen 114. If transport controls are enabled for a content item being played, the user may use the controls by pressing the corresponding buttons on the remote control. Transport control requests are sent directly to the content server 110. If the user then presses another button on the remote control (apart from one related to transport controls) the process begins again from step 1.

Content information The audio-visual content available in the system is structured in such a way as to provide easier selection of and access to the content by the user. This structure is represented by a corresponding object structure in the object database. The basic structure is illustrated in Figure 2 in terms of the five main object classes used in the system: channels, assets, screens, carousels, and content items. Content is grouped, typically thematically, into a number of channels, represented by channel objects CH1 to CHn. For example, feature films may be grouped into a "Movies" channel, whilst music videos are available within a

"Music" channel. This can enable easier navigation of the service and make it easier to find a specific piece of content. Although the fundamental unit of audio-visual content managed by the system is the individual audio / video data file, from the user's perspective, the basic unit of content is a content asset. A content asset represents an audiovisual content offering, that is to say, a unit of audio-visual content which is offered to a user and which may be individually selected, viewed, rented or purchased as appropriate. Typical examples of assets include a film, a music video, an episode of a TV series, a football match and a song. Each asset is represented by a content asset object comprising information relating to the asset. This information may, for example, include availability information, pricing information and categorisation or classification information. The asset object also comprises information defining the validity period of the asset, that is to say, the time period during which the asset is available to users. This period is defined by a start and end date and time, and is used in the generation of menus as will be described below. Further examples of information that may be stored in asset objects include asset descriptions, names of actors and directors, age restrictions and running times. Each channel object is associated with a number of such content asset objects, which represent the assets available for purchase on that channel. In the example shown, channel object CH2 is associated with asset objects A1 to An. The presentation of asset information and the user's interaction with an asset - for example, viewing information relating to the asset, renting the asset and viewing the asset - is managed by way of one or more screens associated with the asset. Each screen defines an aspect of the user interface associated with the asset, and may display information stored in the asset object in a defined way. For example, a film may typically be associated with a synopsis screen displaying a film summary and pricing information, a purchase screen where the user can authorise payment to buy access to the film, and a playback screen, which provides for the playback of the content itself. Each screen is represented by a screen display object defining the information intended to be displayed on that screen. In the example shown, asset object A2 is associated with screen objects S1 to Sn. One of the screens associated with each asset is identified as being the asset's default screen. An asset consists of one or more audio-visual content items, i.e. one or more individual data files. For example, a film may be preceded by a selection of trailers advertising other assets of potential interest to the user. In this case, each of the trailers and the film will be stored in separate audio-visual data files, but will be represented as a whole by an asset. The user is therefore not able to select and view the film on its own without the trailers. A further example is a sponsorship message displayed before and/or after a given programme. The sequence of audio-visual content items to be played back when an asset is viewed is represented by a carousel object associated with a screen of the relevant asset. In the example shown, screen object S2 is associated with carousel object CA. A carousel object defines a sequence of content items which are to be played in either a fixed or random order. In a fixed order carousel, items are played in the order specified by the carousel object. In a random order carousel, the items are played back in a random order. This order may be determined, for example, at the time of playback. In the example, carousel object CA defines a sequence of content items represented by content item objects 11 to In. Instead of pre-defined content items, a carousel may also specify criteria for the selection of dynamic content, with the specific content being chosen at run time from the content available in the system. For example, a carousel may specify that movie trailers of a particular film genre should be played. At run time, the system then dynamically selects the trailers to be played from the trailers that are stored in the system. The content in the system may therefore change without affecting the definition of the carousel. A content item object represents an actual playable audio-visual content item such as an audio-visual data file. However, the content item object in the database does not contain the audio-visual data itself, but only such information as is necessary to enable the STB to send a request for the item to the content server (110). This content access information typically includes the filename and storage location of the audio-visual data file on the content server, for example in the form of a URL. The content access information could also comprise a URL of a content file or stream available from an external source, such as a web site. In operation, when management server 104 receives a request specifying a content asset from a user, it accesses the corresponding content asset object in the database and displays the default screen associated with the content asset object. If the default screen is a playback screen or the user subsequently initiates playback by navigating to a playback screen, the management server then identifies audio-visual content associated with the screen (and hence the content asset), as defined by the relevant carousel and content item objects. It then initiates delivery of the associated content by sending the access information, such as the URL, to the user's set top box. If there is a price associated with the asset (as defined by pricing information stored in the asset object), the system also initiates a payment transaction, for example by making a charge to the user's account or a specified credit card.

Screens Screens define the user interface of the content delivery service. Screens are represented in the database by screen display objects (also referred to as screen objects) which define the information that is to be displayed to a user at any given time. Each asset object has at least one such screen display object associated with it. For example, a film may have associated with it a synopsis screen giving information such as running time and rental price, a purchase screen for providing authentication information and initiating a purchase transaction, and a playback screen for playback of the actual audio-visual content. Each asset specifies one of its screens as the default screen. The default screen is the first screen displayed to a user when an asset is selected. For example, in the case of a film, the default screen may typically be the synopsis screen. Screens are typically associated with text data, image data, user interface definition data and/or audio-visual content. This data represents text and images to be displayed on a screen, as well as user interface elements such as entry fields and buttons / links, and content to be played. To enable navigation around the service, screens may define links to any other screens or assets in the service. These links correspond to buttons in conventional graphical user interfaces and are typically represented graphically on the screen (though they need not necessarily have a graphical or even a visible representation). Activation of a link by the user causes the linked screen to be displayed. Where the system is intended to be operated primarily using a remote control associated with a set top box, a link is typically represented by a graphical representation of one of the keys on the remote control. Activation of a link is then achieved by pressing that key. Different types of screen display objects are used to display different kinds of information and carry out different user interface tasks. To represent the different types of screen, different sub-classes of the screen display object class are provided in the database. The following are examples of screen types used: Static menu screen: This screen displays a fixed list of menu items from which the user may select. This is typically used as one of the main elements of channel navigation. Dynamic menu screen: This screen is used to display dynamic and/or large amounts of data, such as search results or menus having more options than can be displayed on a single screen. The dynamic menu screen splits the available results or options into a number of ranges, typically alphabetical ranges, which are displayed to the user. When the user selects a range, the results or options in that range are then displayed (or further sub ranges if there are still too many to display). Search screen: This screen is used to search for assets that meet specified requirements. For example, a user may search for all assets listing a specific actor. Personal Screen: This screen is used to maintain a menu of the assets currently rented by a user. As a new asset is rented, it appears on the personal menu screen. Once the rental period of the asset has expired, it is removed from the personal menu screen. Synopsis screen: This screen displays information about an asset that a user may wish to view or rent. It typically contains information such as a title, description, duration, age restriction and price, as well as links to further screens for renting the asset or viewing a preview of the asset (for example, a movie trailer). Once a user has rented an asset, the synopsis screen may change to show the rental duration or expiry time in place of the pricing information. Credit Card Screen: This screen is used to obtain credit card details so that a user can purchase access to an asset using their credit card. Billable PIN screen: This screen is used to identify a user wishing to rent an asset, especially where age verification is required. In a household where multiple users access the same STB, each user is provided with a unique PIN which they are required to enter to confirm the purchase and perform an age check. Access Control PIN screen: This is similar to the billable PIN screen, except that the user does not get billed. It is generally used to restrict access to channels such as adult channels. Play Content screen: This screen is used to play a particular asset and typically provides transport controls to allow the user to pause, fast forward, rewind and stop the content playback (other screens may also provide transport controls if appropriate). Bookmark screen: This screen is used to record the point at which the user interrupted playback of an asset and to enable the user to resume or restart playback of the asset. Broadcast Screen: This is a screen that provides access to conventional broadcast television channels in a way that resembles conventional television viewing, for example by enabling a user to switch up and down between available broadcast channels. Menus Menu screens provide the basic user interface of the content delivery system. Typically, a "home screen", being the first screen presented to the user when accessing the service, is provided that lists the channels available in the system. An example of such a home screen is shown in Figure 3, which shows a screen display providing a menu of video-on demand channels, broadcast television and application-specific services - in this case, guest services in a hotel. Each menu option is displayed with a symbol representing a key on the remote control with which the option can be selected (e.g. keys "1" to "4"). Each channel typically comprises one or more menu screens listing assets available for purchase on the channel. An example is shown in Figure 4. The example is that of a menu screen listing movies available for viewing on a "Movies" channel, with the final menu option providing a link to a further menu screen. Each menu screen is represented by a menu screen object in the object database, which stores menu definition data specifying the assets to be listed in the menu. This menu definition data is used to generate the menu screen, taking into account the validity periods of the assets in question. For each asset listed in the menu definition, the validity dates of the asset are retrieved from the database and compared to the current date. If the current date falls within the validity period, then the asset is considered valid and included in the generated menu. If the current date lies outside the validity period of the asset, then the asset is not included in the generated menu. This can enable easier management of the content information in the object database by the system operator, since items can be added to menus before they are intended to be available to users. The menus seen by the users then change automatically depending on which content is valid at any given time. Also, where the service provider acquires the right to provide a piece of content for a specific period of time (for example, the right to show a certain film for a period of one month), assigning appropriate validity dates to the assets ensures that the period is not exceeded, without needing to constantly monitor the available assets and remove items when the relevant rights expire. This can reduce the burden of managing a large content delivery system having many content assets, each with different validity periods. Instead of displaying a list of predefined assets, a dynamic menu screen may be used which searches the database for relevant assets based on given criteria and asset validity dates, and compiles a menu from the results of the search. For example, a "Movies" channel may comprise a dynamic menu which finds and lists all assets which are films, and which are currently valid according to their validity dates. A channel may of course have both pre-defined and dynamic menus associated with it. For example, a pre- defined menu may list specific assets to which the service provider wishes to draw the user's attention, whilst a dynamic menu is used to allow the user to find any other assets available on the channel. In addition to providing access to video-on-demand (VOD) content assets, dynamic menu screens may be used to display information relating to broadcast television programmes that are of possible interest to a user. For example, a dynamic menu screen may comprise a video-on-demand portion listing a pre-defined or dynamically generated menu of video-on-demand assets and a broadcast portion listing relevant broadcast television programmes which meet certain criteria. As an example, a screen presenting a menu of football-related assets - which may be part of a "Sports" channel - may list a number of VOD assets, such as classic matches and documentaries on sports personalities, whilst the broadcast portion of the menu lists live football matches which are currently being broadcast or are due to be broadcast soon. The broadcast menu is generated by searching the EPG data received from broadcast information source 130 and stored in object database 102 (both shown in Figure 1 ) for programmes matching certain criteria. The criteria may, for example, include content type classifications and the programme start times. In a further example, a menu of science fiction programmes within a

"Sci-Fi" channel may list a number of science fiction films which are offered as video-on-demand content assets by the system, as well as any science fiction programmes which happen to be scheduled for broadcast on a broadcast service or network. An example screen display of such a menu is shown in Figure 5. In this example, menu screen 500 lists a number of video-on- demand content assets in a VOD portion 502. Each menu item is associated with a keypad key and links to the synopsis screen of the relevant asset, from where the asset may be purchased. A broadcast portion 504 lists a selection of broadcast television programmes which fulfil the given criteria, in this case being a programme in the science fiction genre. They are listed with information such as the television channel and transmission time. The screen may be configured to only show broadcast programmes within a certain time period, for example only those programmes due to be broadcast that day. Additionally, the screen may list programmes in start time order. Given the limited space, it is possible that not all relevant programmes can be listed. In this case, the screen may list only the next few programmes, as shown in this example. Links (designated by key icons "4" and "7" respectively) are provided to further menu screens to allow a more comprehensive menu to be displayed. The generation of such a menu will now be described with reference to Figure 6. Menu generator 510 obtains menu definition data relating to the VOD part (502) of the menu from the screen display object 512 in object database 102, along with the broadcast menu criteria. The menu definition data specifies either a fixed list of assets, or search criteria for selecting assets from the database. The VOD part (502) of the menu is generated from this menu definition data as previously described. The broadcast menu criteria may include, for example, a programme category (such as programme type or genre), broadcast channel or age restriction. As has already been mentioned, the object database also stores broadcast data (such as EPG data), shown here as broadcast data 514, which is periodically updated from broadcast information source 130, and which describes programmes due to be broadcast on a number of broadcast channels. Using the broadcast menu criteria, the menu generator 510 searches this broadcast data and identifies broadcast programmes which fulfil the criteria, as well as having a start time within a specified period (for example, "today"). The earliest broadcast programmes are then selected, and added to the menu. Activation keys are associated with each menu option. In the case of the VOD part (502) of the menu, these link to the relevant assets. In the case of the broadcast part (504) of the menu, they link to screens or assets representing the relevant broadcast channels. The user state information 516 in the object database is then updated to include information relating to the generated menu, including the menu options and associated activation keys selected. This ensures that, when a user later activates a given link, the correct asset or broadcast channel can be displayed. Finally, the generated menu screen is transmitted to STB 112 via the request server 106. Although the menu generator has been described as a separate entity, it may in fact be implemented as an operation or method of the screen display object itself.

Object structure example Although asset and channel objects are generally used to represent actual audio-visual assets and channels available in the content delivery system, they may also be used in a more abstract way to define the structure and user interface of the service, as will now be described. Figures 7 and 8 show examples of object structures representing parts of a content delivery service. In the diagrams, each object is represented as a box labelled with the object name and object class separated by a colon. The user's starting point within the content delivery service is defined by a special "Home" channel, represented by channel object 600 containing a single asset 602, also named "Home", which in turn contains the top-level menu of the content delivery service in the form of a menu screen object (class "MenuScreen") named "HomeMenu" (604). This home menu is displayed to the user when first connecting to ^'the service. In the present example, it contains links to two further menus, represented respectively by the "BroadcastMenu" asset object 620 having a menu screen object 622, and the "ChannelMenu" asset object 640 having a menu screen object 642, as well as to a personal screen and search screen as will be described below. Menu screen object 622 ("BroadcastMenu") lists the regular television broadcast channels available to the user through the content delivery system, and provides links to corresponding assets 624, 628 and 632. Each of those assets in turn comprises a broadcast screen, represented by broadcast screen objects 626, 630 and 634, which provide the actual playback of the relevant broadcast television channel on the user's set top box (by instructing the STB to receive the relevant stream from broadcast server 108, as shown in Figure 1), and allow the user to switch up and down through the available television channels in a defined sequence, thus replicating the conventional television viewing experience within the content delivery service. Menu screen object 642 ("ChannelMenu") lists the video-on-demand channels available to the user through the content delivery system, and provides links to corresponding channel objects 650, 652 and 654, thereby allowing the user to select a desired channel. The channel menu could be predefined, or could be dynamically generated from the channel information stored in the database. The home menu and the channel menu may also be combined to provide a single menu, whereby the available channels are displayed directly on the home menu, as shown, for example, in Figure 3. The home menu (menu screen object 604) further provides links to a personal section and a search section, represented respectively by asset objects 660 and 664. Asset object 660 is associated with a personal screen object 662 providing a list of the assets currently rented by the user as previously described. Asset object 664 is associated with a search screen object 666 defining a search screen for finding particular assets as previously described. Figure 8 shows an example of the object structure representing one of the video-on-demand channels, namely the "Movies" channel. The channel is represented by channel object 650, having a number of content asset objects associated with it, of which asset objects 674 and 676 are shown. A special asset 670 ("MoviesMenu") is associated with a menu screen object 672 defining a menu of the films available for viewing on the channel, as shown, for example, in Figure 4, and providing links to the relevant assets. Alternatively, a dynamic menu screen could be used listing a combination of video-on-demand assets and relevant broadcast television programmes as described above and shown, for example, in Figure 5. Asset object 674 represents the feature film "Armageddon", which is available for viewing on the channel. Similarly, asset object 676 represents the feature film "Solaris". In this example, three screen display objects are associated with asset object 674. Synopsis screen object 680 ("Synopsis") defines the synopsis screen for the film, providing, for example, a film summary and the rental price as previously described. A credit card screen object 682 ("Purchase") defines a screen allowing the user to purchase the film. A play content screen object 684 ("Play") defines the screen which provides the playback of the actual audio-visual content on the user's STB. Links are provided between the synopsis screen and the credit card screen, and between the credit card screen and the play content screen. When viewing the synopsis screen, the user may select the relevant link (labelled, for example, "Rent") to display the credit card screen. After entering credit card details and selecting a further link (labelled, for example, "Proceed"), the details are processed, and the user is taken to the play content screen. Associated with the play content screen object 684 is a carousel object 690, which defines the sequence of audio-visual content items which make up the "Armageddon" asset. In this case, carousel object 690 defines a sequence of three content items represented by corresponding content item objects: Content item object 692 represents an advert; content item object 694 represents a trailer for another film available in the service (in the example, "Solaris"), and content item object 696 represents the film "Armageddon" itself. Each content item object provides the location and filename of the corresponding audio-visual content file on content server 110 (shown in Figure 1), for example in the form of a URL. This allows the STB to independently communicate with the content server 110 to initiate the streaming of the relevant file. Although in this example, only the play content screen 684 has a carousel object and content item objects associated with it, other screens may also provide content playback. For example, a menu screen may display a sequence of trailers or adverts (defined in a corresponding carousel object) in a corner of the screen, or in the background with the menu text superimposed. The structures provided by the content delivery system can give greater flexibility to the service provider in defining the content delivery service. In one example of this, an asset may be defined which represents a package of other assets, which can then be rented as a whole. For example, a content delivery service may comprise multiple episodes of a television series as individually rentable assets. However, the service provider may also define an asset representing the TV series as a whole, allowing the entire series to be selected and rented by the user. As a further example, a film may be packaged with related content, such as a "Making of..." documentary, to provide a content package similar to a DVD.

Content management Audio-visual content delivery systems according to certain embodiments of this invention use a rolling update system to provide seamless updating of the content-related information without disruption to the user. This rolling update system is not limited in its application to audio-visual content delivery systems but may also be used in other contexts - such as web sites. In the application of this aspect of the invention to a generic information service, the service may be defined by an amount of stored service information, and the service is updated by updating that service information. The service is split into a number of service areas, which may be updated independently of each other without affecting the remainder of the service. As an example, when applied to an audio-visual content delivery system, the service areas would be the channels, and the service information would be the content information defining the assets and screens available in those channels. This particular example will, of course, be described in more detail below. Another example of a service to which the present system could be applied is a web site. In this example, the service information would typically be the actual HTML documents, images, and so on, which make up the web site. The service areas might, for example, be different sections of the web site. As a further example, the service might be a computer program provided in the form of a number of program modules (as service areas), with the service information being the program code itself, enabling the program modules to be updated individually, whilst the computer program is being used. Seamless updating of individual service areas is achieved in accordance with various forms of this invention by storing multiple concurrent versions of those service areas, and controlling which version of a given area a user accesses at any given time. Typically, each area has, at any one time, a "live" version associated with it, this being the version of the area which is currently considered to be the valid version. Furthermore, one or more old versions of the same area may exist concurrently with the live version to avoid disruption to users still accessing those old versions when a new version is added. Finally, a service area may also have one or more future versions associated with it. These are versions which have been added to the system ahead of the time at which they are intended to become the "live" or valid versions. These future versions are typically not accessible to users until that time has been reached. The rolling update system will now be described in overview with reference to Figure 9. The service comprises service information storage 820, in which the service information is stored. As previously mentioned, the service information is divided into a number of service areas. Of each service area, one or more area versions may be stored concurrently in the service information storage. Area manager 800 is provided for managing access to, and updating of, the service information in storage 820. Requesting process 830 is shown, by way of example, to represent a process wishing to access the service information. Similarly, an exemplary update process 840 is shown representing a process wishing to update the service information. Requesting process 830, which is associated with a particular user of the system, requests access to an area of the service from area manager 800, which identifies the appropriate version of that area and returns to the requesting process information identifying the relevant area version. Using this information, the requesting process 830 then accesses the area version in service information storage 820 and retrieves the required service information. Updating process 840 creates a new area version (for example a new channel in the content delivery system, or a new section of a web site) in service information storage 820. It then instructs area manager 800 to add the area version to the system so that future access requests may access the new version. To perform these functions, area manager 800 comprises area mapping tables 808, access request manager 802, deletion manager 804 and update manager 806. These will now be described in detail.

The area mapping tables Area mapping tables 808 store information relating to the service areas and area versions currently existing in the service, and relating to which areas, and which versions of those areas, users of the service are currently accessing. The mapping tables allow the correct area version to be identified in response to an area access request. Each area of the service is referenced by an area name. However, since different versions of an area may exist, the area name alone is not sufficient to enable access to the area. Therefore, a unique identifier (ID) is also assigned to each area version. A representation of each area version is stored in the area mapping tables. This representation is in the form of a data structure storing the area name and the unique area version identifier. Depending on the application, further information relating to each area version may also be stored. For example, a location specifier may be provided for each area version, which specifies the location of the area version in storage 820, thus allowing it to be located and accessed. Where the service is a web site, the location specifier might, for instance, be the URL of a directory in a file system where the relevant version of a given web site section is stored. In some applications, the implementation details may be chosen in such a way that the unique version identifier provides sufficient information for locating the version in storage 820, in which case no separate location specifier is required. For example, where storage 820 is an object database, the object identifier of an object representing an area version may also be used as the version identifier. In addition to the location specifier, other application dependent information relating to area versions may also be stored. Area mapping tables 808 further comprise an area lookup table, a user lookup table and a live area lookup table. These will now be described in detail with reference to Figures 10 to 12. The area lookup table - The area lookup table provides a complete list of all area versions currently available in the service - both live and otherwise.

The area lookup table is accessed using the unique identifier of the area version, and each entry in the table points to the representation of the area version. An example of an area lookup table is shown in Figure 10. In the example, area lookup table 850 lists a number of area versions with their identifiers (ID) and a reference to the area information of the corresponding area versions. Area versions 852 and 854 are shown by way of example. The user lookup table - The user lookup table provides a list of all users currently using the system, along with the area name and version identifier of the area and area version they are currently using. An example of a user lookup table is shown in Figure 11 , showing user lookup table 860. The live area lookup table - The live area lookup table lists, for each area, the area versions which exist for that area, along with the versions' respective validity dates. The table is accessed using the area name, and refers for each area name to a data structure comprising a list of area versions, giving for each area version the version identifier and the validity date. The validity date defines from when the given area version becomes the live version of that area - in other words, the date when the version "goes live". For efficiency, this list is stored in date order. This structure enables new area versions to be added ahead of their intended validity date. An example of a live area lookup table is shown in Figure 12. In the example shown, the live area lookup table 870 lists areas "areal" to "area4", with area names and lists of area versions. For example, entry 872 for "area4" comprises version list 874 listing five area versions, including area versions 876 and 878. The version information in each case comprises the version identifier ("ID") and the validity date ("GoLive").

The access request manager The operation of access request manager 802 will now be described with reference to Figures 13 and 14. Access request manager 802 receives area access requests from requesting process 830. Each request specifies the required service area. In response to a request, access request manager 802 uses the information stored in the area mapping tables 808 to look up which version of the requested area to return to the requesting process. Area requests may take one of the following two forms: 1 ) Area access request by area name - this method is used when a user accesses an area either for the first time, or from another distinct area of the service. 2) Area access request by area version ID - this method is used to return a specific version of an area - typically the last area that the user was accessing. This can be especially useful in stateless systems, where large amounts of data cannot be retained during transactions. The steps performed by the access request manager 802 in response to an area access request by area name are illustrated in Figure 13, and are listed below, by way of an example: a) Access request manager 802 receives a request for access to an area from a requesting process associated with a given user (in the example, user "2"). The request specifies the name of the required area ("area4"). b) The access request manager uses the user lookup table 860 to determine which area the user is currently accessing. In this case, the user is currently accessing a different area ("areal"), so accessing the requested area involves crossing an area boundary. If the user were already in "area4", the access request manager would simply retrieve the version identifier of the area version the user is currently accessing and the process would continue at step d). c) The access request manager looks up the requested area ("area 4") in the live area lookup table 870 and searches the version list associated with that area, in this case version list 874, in order to find the version with the most recent validity date, which is the live version. In this case, version 878 dated 01/12/2001 is the most recent, as no versions currently exist after it. The version ID ("00032951") of this area version is noted. d) The access request manager uses the version ID obtained above ("00032951") to locate the area version in area lookup table 850. e) The user lookup table is updated with the version ID of the area version that the user is now accessing, and the name of that area. f) The area/version information is returned to the requesting process. The steps performed by the access request manager 802 in response to an area access request by area version ID are illustrated in Figure 14, and are listed below: a) Access request manager 802 receives a request to access an area version specified by its version ID (in this example, "00032951"). This may, for example, have previously been obtained from the user lookup table. b) The access request manager uses the version ID ("00032951") to locate the area version 854 in the area lookup table 850. c) The area/version information is returned to the requesting process.

The update manager The operation of update manager 806 will now be described with reference to Figures 9 and 15. Update manager 806 receives update requests from update process 840. An update request provides information on a new area version which has been created in service information storage 820. In response to the request, update manager 806 updates the relevant area mapping tables 808 to enable the new version to be accessed. Since adding area version involves modifying the area mapping tables - specifically, the area lookup table and the live area lookup table - a locking mechanism is employed to ensure that only one updating process can modify the tables at a time, and to prevent requesting processes from reading the tables while the update is taking place. Any access requests can be queued up and executed as soon as the relevant locks are released. The steps carried out by the update manager 806 in response to an update request are illustrated in Figure 15, and are listed below, again by way of an example: a) Update manager 806 receives a request to add a new area version. The request includes information on the area version to be added (in the example, a new version of "area4"), including the name of the area and the validity date of the new version, which is the date when this new version should become the live version ("01/12/2002"). For the purposes of this example, it is assumed that this date lies in the future. Other, application- specific information may also be supplied (for example, a location specifier as discussed above). b) First, area lookup table 850 is locked, and a new version ID is generated for the new area version ("00034588") by the update manager. A new entry 856 is then inserted into the area lookup table for the new area version. The area lookup table is then unlocked. c) Next, live area lookup table 870 is locked. A validity date / version ID pair 879 is created from the newly generated version ID and the date and time at which the new area version is intended to go live. This is then inserted into the list 874 of date/ID pairs associated with the relevant area entry 872, while maintaining the list in ascending validity date order. To prevent there being more than one live version of any area at any one time, if the new date/ID pair has exactly the same date and time as an existing pair, the existing pair is removed and replaced with the new pair. A clean-up operation is then performed to remove any redundant date/ID pairs. This is achieved by identifying the live version of the area and removing all versions with an earlier validity date. In this example, the version dated "01/12/2001" is still the live version, as "01/12/2002" (the newly added version) is in the future. All versions before the live version can be removed. For any versions that are removed at this stage, the version IDs are passed to deletion manager 804 for later deletion as will be described below. Once this clean-up operation has been completed, the live area lookup table 870 is unlocked.

The deletion manager The deletion manager will now be described with reference to Figure 16. The function of deletion manager 804 is to remove area versions that are no longer needed from the system. During the update process (as described above), the update manager passes version IDs of redundant area versions to deletion manager 804 for deletion of the corresponding area versions. However, when the deletion manager receives the version ID of an area version which is in principle no longer needed (it no longer being the live version of the area), it is not instantly deleted, since some users may still be accessing the version. Instead, the deletion manager determines a deletion date, which is a date and time after which it is considered safe to delete the area version. The deletion manager stores this deletion date together with the version ID of the area version that is to be deleted. The deletion date is calculated as a fixed delay from the time at which the version ID is received for deletion. The delay may, for example, be 24 hours. The actual delay before deletion will depend on the specific application, but should generally be large enough to ensure with reasonable certainty that, at the deletion time, there will no longer be any users accessing the area version in question. Figure 16 shows an example of this process. Here, live area lookup table 870 is updated by update manager 806 as described above with reference to Figure 15, by addition of a new area version 879 of area "area4", to produce updated live area lookup table 870'. During the update procedure, the update manager determines that the versions listed in version list 874 with validity dates earlier than that of the live version 878 are no longer needed and can be deleted. Accordingly, the relevant version IDs are passed to deletion manager 804 where they are stored together with a deletion date, calculated as described above. Once the deletion date for a given version has passed, it is then deleted. This may be performed directly by the deletion manager, or by a separate process. Specifically, once the deletion date has passed for a particular area version, the deletion manager looks up the area version in the area lookup table 850. Using the information stored there, the area version is located in storage 820, from where it is then deleted. Then, the relevant entry itself in area lookup table 850 is deleted. Since all these operations involve updating data, a locking strategy is employed to keep the data consistent. The process that actually performs the deletion can either be a background process that is triggered periodically (for example every 24 hours), or a manual process that is run by an operator when storage space in storage 820 is running low. Optionally, the deletion manager may also delete an area version scheduled for deletion before its deletion date if no users are registered as using the version. To achieve this, the deletion manager may periodically search the user lookup table 860 and compare the version IDs of the versions scheduled for deletion against those recorded in the table. If any version is not referenced in the user lookup table, it is no longer being used and can be safely deleted. An example of the operation of the rolling update system will now be given, in which the service is a web site, having a number of distinct sections, which are the service areas. Each section may comprise several web pages. In this example, the web site comprises a "News" page and a "Reports" page in one area of the web site ("areal"), and a "Download" page in a separate area of the web site ("area2"). To ensure correct navigation between areas, all requests for access to individual web pages are made through the area manager 800 (specifically the access request manager component 802 of the area manager) by area name. If, for example, the user is currently accessing the "News" page in a given version of "areal", and wants to request the "Reports" page in the same area, a request is therefore sent to the area manager for "areal". The area manager determines that the user is already accessing "areal" and simply returns the version of the area that the user was previously accessing. In contrast, if the user then requests the "Downloads" page in "area2", the area manager detects that an area boundary is being crossed, and returns the live version of "area2". If the user then decides to return to the "News" page in "areal", this again involves crossing an area boundary. This time, therefore, the access request manager returns the live version of "areal", which may not necessarily be the version the user was accessing before if a new version has since been added. In this way, for example, the "News" page can be updated, and the updated version added to the system, without disruption to the user. If, at the time when the updated version of "areal" goes live (as determined by its validity date), any users are accessing the previous version, they continue to see that version, until they leave that area of the web site. If and when they return to that area, they will then be redirected to the most current version of the area. In some applications, it may be necessary to ensure that certain interrelationships or interfaces between the different areas of the service remain unchanged between versions. For example, where the service is a computer program, and the service areas are program modules, an update involving a change to an interface between modules could cause problems where an old version of one module attempts to communicate with a newer version of another module having an updated interface. The incompatibility between the interfaces could then cause the system to fail. The rolling update system has been described above in the context of services which are split into multiple areas. The system as described only moves users into new versions of an area when an area boundary is crossed.

However, the system can also be applied to a service defined as one single area. In this case, it is, of course, not possible to cross area boundaries, and so, using a system as described above, users would effectively be trapped in one version of an area and would be unable to ever see any new versions. To overcome this problem, a special circumstance can be introduced under which the area manager always returns the live version of an area. This could be done, for example, when the user accesses the system after a period of inactivity, or, in the case of a website, when the home page of the web site is accessed. The rolling update system as described can have the following advantages:

1) Updates can be performed seamlessly; the service does not need to be shut down while an update is in progress; 2) Any users who are using the service while an update is performed will not see the change until they leave the area of the service they are currently accessing. As such, there is no danger of a user crossing from the old version to the new version of an area whilst in the middle of a process or transaction. 3) The old and new versions can exist side-by-side; the rolling update system has the ability to remove old versions automatically. 4) New versions of areas of the service can be added to the service in advance of the time when they are actually required, and a date and time can be specified for when a version should become the live version. Users will then automatically be directed to these new versions if they access the updated area of the service after the specified date and time. The application of the rolling update system to an audio-visual content delivery service will now be described. In this specific application, the service areas used by the rolling update system are the channels of the content delivery service, and the service information is the asset, screen and other information associated with the channels. The content delivery system therefore maintains multiple concurrent versions of a channel in the form of multiple channel objects representing the different versions, along with multiple versions of the channel object's associated substructures (such as asset and screen objects). The rolling update system manages access to the different versions of the channels as previously described. Using the rolling update system, channels can be updated without causing disruption to users of the content delivery system. In particular, as described above in general terms, whenever a user starts to access a channel within the service, they are associated with the live version of the channel. The user continues to use the allocated version of the channel until they request a different channel, even if a later version of the channel becomes available whilst they are using the old one. This provides the user with a consistent experience. The management of the content delivery service using a rolling update system as presented above will now be described with reference to Figure 17. The content delivery service is defined by the overall structure of the service (in terms of channels), the visual presentation of the service, and the audio-visual content offered by the service. These may be changed independently, since the service structure and visual appearance are typically changed far less frequently than the content on offer. It is, for example, conceivable that new content, such as films, may be added to the service on a weekly or even daily basis. The structure of the content delivery service is defined by a data builder 902, who specifies the channel structure of the service by way of a data build XML document 908. The visual appearance of the various screens provided by the system is separately defined in a number of JSP (Java Server Page) Styles 910. The content of a given channel is defined and updated by content administrator 904 using content administration tools 906, which output a content XML document 912. This document defines the assets and associated synopsis, PIN, bookmark and playback screens for all the content available on the channel. Whenever a channel has been updated (usually by changing the content, but less frequently by changing the structure or visual styling), the channel information from all three sources (data build XML document 908, JSP styles 910, and content XML document 912) is compiled by channel compiler 914 into compiled channel 916, which is in a form suitable for storage in object database 102. The compilation process checks for errors in the XML documents and ensures that all cross-references between structure, content and styles are resolved. The compiled channel 916 is then passed to roll manager 920. Roll manager 920 performs the functions of the update process 840 and the update manager 806 as described above with reference to Figure 9 by storing the newly compiled channel 916 in the object database 102 as a new version of the channel, and configuring the area manager 800 (whose remaining functionality is here incorporated in management server 104) to allow access to the new version. The new channel version is then available for access by a user through area manager 800 incorporated in management server 104. It will be understood that the present invention has been described above purely by way of example, and modification of detail can be made within the scope of the invention. For example, alternative object structures may be used in place of the specific object structure described. Carousel objects or content item objects may be associated directly with the relevant asset object, with screens being defined separately from the assets. In some systems, interaction with assets may occur in a fixed way via a pre-defined set of screen displays, in which case screen display objects in the form described may not be needed. As a further example, content may be structured in a different way, not using the channel / asset structure described. Modifications may also be made to the architecture of the system. As one example, rather than providing a content server separate from the management server, content may be stored directly on the management server, or even in the object database itself (the object database may of course be stored on the management server in any case). For example, audio-visual content data could be stored within a content item object, or an associated object. In such a system, instead of outputting access information to enable a set top box to access the content, the system would typically output the content itself by streaming it to the set top box. Although in the application of the rolling update system to the content delivery system as described, the individually updateable service areas are the channels, the update system may be applied differently. For example, each asset might be considered a service area. The exact details of the application of the rolling update system will depend on the specific purpose and structure of the content delivery service being provided. In the system described, delivery of content is initiated by receiving a request for playback of a given content asset from a user. However, an automated system, in which content is selected by the delivery system (for example based on user preferences, the service provider's requirements or other criteria) and streamed to the set top box without interaction by a user, could also be implemented. In this way, a music / video jukebox or advertising system might be implemented. Automatic streaming of content may also be combined with a user-driven system as described, for example, to provide streaming of advertisements or other content during times when a set top box is not being actively used. Although the system has been described largely as a video-on-demand system where content is streamed to users, other forms of content delivery service may also be provided by such a system. For example, content download services may be provided, in which users download (usually for a fee) audiovisual content to be stored indefinitely on their own terminals (typically personal computers), from where they may also be transferred to portable media players and permanent storage media (for example, MP3 players and CD-R/RW disks). In addition to these various examples, many other modifications to the systems and methods described can be made. Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Claims

1. An audio-visual content delivery system for delivering audio-visual content to a user terminal, comprising an object database storing data relating to the audio-visual content; and means for accessing the audio-visual content in dependence on the data.

2. An audio-visual content delivery system according to Claim 1, wherein the object database stores an object representing a screen display.

3. An audio-visual content delivery system according to Claim 2, wherein the screen display object is associated with at least one of: text data, image data, user interface definition data, and audio-visual content.

4. An audio-visual content delivery system according to Claim 2 or 3, wherein the screen display object is associated with user interface definition data comprising link data defining a user-selectable link to a further screen display object.

5. An audio-visual content delivery system according to any of Claims 2 to 4 further comprising means for generating screen display information in dependence on the screen display object; and means for outputting the screen display information.

6. An audio-visual content delivery system according to Claim 5, wherein the means for outputting screen display information comprises means for outputting access information for accessing an audio-visual content item.

7. An audio-visual content delivery system according to any of Claims 2 to 6, wherein the database stores an object representing an audio-visual content item associated with the screen display object and comprising access information for accessing the audio-visual content item.

8. An audio-visual content delivery system according to Claim 6 or 7, wherein the access information comprises a source specifier specifying the source of the audio-visual content item.

9. An audio-visual content delivery system according to Claim 8, wherein the audio-visual content item comprises an audio-visual content file or an audio-visual content stream, and wherein the source specifier specifies the source of the audio-visual content file or the audio-visual content stream.

10. An audio-visual content delivery system according to Claim 8 or 9, wherein the source specifier comprises a filename or a Uniform Resource Locator (URL).

11. An audio-visual content delivery system according to any of the preceding claims, wherein the object database stores an object representing a content asset, and wherein said content asset object comprises information relating to the content asset and is associated with audio-visual content.

12. An audio-visual content delivery system according to Claim 11 , wherein the information comprises at least one of: availability information, pricing information and categorisation information.

13. An audio-visual content delivery system according to Claim 11 or 12, wherein the content asset object is associated with a screen display object representing a screen display.

14. An audio-visual content delivery system according to any of Claims 11 to 13, further comprising means for receiving a request specifying the content asset; means for accessing the content asset object in response to the request; means for identifying audio-visual content associated with the object; and means for initiating delivery of the associated content.

15. An audio-visual content delivery system according to Claim 14, further comprising means for initiating a payment transaction in response to the request.

16. An audio-visual content delivery system according to any of the preceding claims, wherein the object database stores a carousel object which is associated with a screen display object representing a screen display, and wherein the carousel object defines a sequence of audio-visual content items to be played back in the screen display.

17. An audio-visual content delivery system according to any of the preceding claims, wherein the object database stores a channel object representing a group of content assets.

18. A method of delivering audio-visual content to a user terminal, the method comprising; retrieving asset data from a database, the asset data specifying an audio-visual content asset to be represented in a menu; receiving programme data relating to a plurality of broadcast programmes broadcast on a broadcast network; selecting data relating to one of the plurality of broadcast programmes from the programme data in dependence on predetermined criteria; generating a menu having a first menu item representing the specified asset and a second menu item representing the selected programme; and transmitting the menu to the user terminal.

19. A method according to Claim 18, wherein the programme data comprises data specifying a programme category associated with each programme, and the predetermined criteria includes the programme category.

20. A method according to Claim 18 or 19, wherein the programme data comprises data specifying a broadcast time associated with each programme, and the predetermined criteria includes the broadcast time.

21. A method of delivering audio-visual content to a user terminal comprising: receiving asset data relating to an audio-visual content asset, the asset data comprising a validity date; comparing the validity date to a given date; generating a menu in dependence on the outcome of the comparison; and transmitting the menu to the user terminal.

22. A method according to Claim 21 , wherein the data comprises data defining a date range, and wherein generating the menu comprises comparing a given date to the date range, and generating a menu item relating to the asset if the given date lies within the date range.

23. A method according to Claim 21 or 22, wherein the given date is the present date.

24. A method according to any of Claims 21 to 23, wherein receiving asset data comprises receiving an asset specifier, and retrieving the asset data from a database in dependence on the asset specifier.

25. A method according to Claim 24, wherein receiving an asset specifier comprises receiving menu definition data comprising the asset specifier, further comprising generating the menu in dependence on the menu definition data.

26. A method of managing user access to a set of data, the method comprising: storing a plurality of data versions, each data version being a version of the set of data and having associated with it a time specifier specifying a validity time for the data version; receiving an access request relating to the set of data from a user; in response to the request, selecting in dependence on a predetermined criterion either the data version most recently accesseό by the user or the data version having the most appropriate validity time; and providing access to the selected data version to the user.

27. A method according to Claim 26, further comprising retrieving information relating to an access request previously received from the user, the predetermined criterion comprising an indication of whether the previous access request related to the same set of data as the request.

28. A method according to Claim 26 or 27, wherein the predetermined criterion comprises the time elapsed since a previous access request received from the user.

29. A method according to any of Claims 26 to 28, wherein providing access to the selected data version comprises outputting a specifier specifying the selected data version.

30. A method of delivering audio-visual content to a user terminal, comprising storing data relating to the audio-visual content in an object database; and accessing the audio-visual content in dependence on the data.

31. An audio-visual content delivery system for delivering audio-visual content to a user terminal, comprising: means for retrieving asset data from a database, the asset data specifying an audio-visual content asset to be represented in a menu; means for receiving programme data relating to a plurality of broadcast programmes broadcast on a broadcast network; means for selecting data relating to one of the plurality of broadcast programmes from the programme data in dependence on predetermined criteria; means for generating a menu having a first menu item representing the specified asset and a second menu item representing the selected programme; and means for transmitting the menu to the user terminal.

32. An audio-visual content delivery system according to Claim 31 , further comprising means for performing a method as claimed in Claim 19 or 20.

33. An audio-visual content delivery system for delivering audio-visual content to a user terminal comprising: means for receiving asset data relating to an audio-visual content asset, the asset data comprising a validity date; means for comparing the validity date to a given date; means for generating a menu in dependence on the outcome of the comparison; and means for transmitting the menu to the user terminal.

34. An audio-visual content delivery system according to Claim 33, further comprising means for performing a method as claimed in any of Claims 22 to 25.

35. A system for managing user access to a set of data, the system comprising: means for storing a plurality of data versions, each data version being a version of the set of data and having associated with it a time specifier specifying a validity time for the data version; means for receiving an access request relating to the set of data from a user; means for, in response to the request, selecting in dependence on a predetermined criterion either the data version most recently accessed by the user or the data version having the most appropriate validity time; and means for providing access to the selected data version to the user.

36. A system according to Claim 35, further comprising means for performing a method as claimed in any of Claims 27 to 29.

37. A system for managing user access to a channel in a content delivery system, the channel being one of a plurality of channels available in the content delivery system, the system comprising: means for storing a plurality of channel versions, each channel version being a version of the channel and having associated with it a time specifier specifying a validity time for the channel version; means for receiving an access request relating to the channel from a user; means for, in response to the request, selecting in dependence on a predetermined criterion either the channel version most recently accessed by the user or the channel version having the most appropriate validity time; and means for providing access to the selected channel version to the user.

38. A computer program or computer program product comprising software code adapted, when executed on a data processing apparatus, to perform a method as claimed in any of Claims 18 to 30.