GB2396444A

GB2396444A - A Method of Announcing Sessions

Info

Publication number: GB2396444A
Application number: GB0229477A
Authority: GB
Inventors: Juha-Pekka Luoma; Dominique Mueller; Toni Paila
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2002-12-18
Filing date: 2002-12-18
Publication date: 2004-06-23
Also published as: CN1799255A; GB0229477D0

Abstract

An electronic service guide (ESG) is provided by transmitting announcements describing multimedia sessions, such video streams. Sessions are organised into a session directory (28) which is split into two parts: a full session directory (291) and an updated session directory (292). A first kind of announcement describes all sessions in the full session directory. A second kind of announcement describes sessions in the updated session directory. Once a client has received a description of the full session directory, it need only listen to announcements of the second type so as to learn of any updates to sessions.

Description

< 1 2396444

Method of announcing sessions Description

The present invention relates to a method of announcing sessions particularly, 5 although not exclusively to a method of announcing multimedia service sessions through a multicast network.

Audio, video and other types of data may be transmitted through a variety of types of network according to many different protocols. For example, data can be 10 transmitted through a collection of networks usually referred to as the "Internet" using protocols of the Internet protocol suite, such as Internet Protocol (IP) and User Datagram Protocol (UDP).

Data is often transmitted through the Internet addressed to a single user. However, 15 it can be addressed to a group of users. This is known as "multicasting".

One way of multicasting data is to use an IP datacasting network, similar to a terrestrial digital video broadcasting (DVB-T) network. Through such an IP-based broadcasting network, one or more service providers can supply different types of 20 IP services including on-line newspapers, radio, television and download of music songs, videos, pictures and software. These IP services are organised into sessions, each session composing one or more media streams in the form of audio, video and/or other types of data.

25 To determine when and where these sessions occur, users refer to an electronic service guide (ESG), similar to an electronic program guide (EPG) used in DVB.

Ihe electronic service guide is usually divided up into parts and transmitted to users. 30 This approach, however, has several drawbacks. On the one hand, if any sessions are updated, then the user usually has to wait until a new version of the service guide has been received before they receive notification of updated sessions. On the other hand, few sessions are usually updated. Therefore, much of the data

- : - 2 received by the user is superfluous. This is wasteful both in terms of processing power and electrical power, both of which tend to be in short supply in battery-

powered mobile terminals.

s The present invention seeks to provide an improved method of announcing sessions transmitted through a network.

According to a first aspect of the present invention there is provided a method of announcing sessions transmitted through a network, the method comprising 10 providing a first set of announcements describing a plurality of sessions and providing a second set of announcements describing at least one updated session.

This has the advantage that it is possible to choose whether to be provided with the first set of announcements describing the plurality of sessions or to be provided 15 with the second set of announcements describing any updated sessions. This allows updated sessions to be announced more quickly and efficiently.

An updated session may be a new session which Is added to the plurality of sessions, a one of the plurality of sessions in which content is added, changed or 20 delete or a session which is deleted from the plurality of sessions.

Providing the first set of announcements and providing the second set of announcements may comprises providing the first set of announcements through a first channel and providing the second set of announcements through a second, 25 different channel.

Providing the first set of announcements and providing the second set of announcements may comprise providing the first set of announcements through a first address, preferably a destination address, such as a first multicast IF address, 30 and providing the second set of announcements through a second, different address, preferably a destination address, for example a second, different multicast IP address, respectively.

(I - 3

Providing the first set of announcements and providing the second set of announcements may comprise providing the first set of announcements through a first port number and providing the second set of announcements through a second, different port number respectively.

s Providing the first set of announcements and providing the second set of announcements may comprise providing the first set of announcements through a first logical channel and providing the second set of announcements through a second, different logical channel respectively.

o Providing the first set of announcements and providing the second set of announcements may comprise including in each announcement of the first set of announcements data for identifying the announcement as an announcement which describes a one of the plurality of sessions and in each announcement of the second 15 set of announcements data for identifying the announcement as an announcement which describes a one of the at least one updated session.

1G Providing the first set of announcements and providing the second set of announcements may comprise including in each announcement of the first set of 20 announcements respective data for specifying a position of a corresponding session within a first portion of a session directory and including in each announcement of the second set of announcements respective data for specifying a position of a corresponding session within a second portion of the session directory.

25 Providing the first set of announcements and providing the second set of announcements may comprise providing the first set of announcements through a first physical channel and providing the second set of announcements through a second, different physical channel respectively.

30 Providmg the first set of announcements and providing the second set of announcements may comprise providing the first set of announcements through a first network and providing the second set of announcements through a second, different network respectively.

() -4 The method may further comprise providing a third set of announcements describing another plurality of sessions including the at least one updated session.

s The method may comprise providing the first set of announcements through a first channel, providing the second set of announcements describing at least one updated session through a second, different channel and providing a third set of announcements describing another plurality of sessions including the at least one updated session through the first channel.

The method may comprise arranging the providing of said second set of announcements after the providing of said first set of announcements.

The method may comprise arranging the providing of said first set of 15 announcements and the providing of said third set of announcements at substantially during an overlapping or same time periods.

Providing the first set of announcements and providing the second set of announcements may comprise transmitting the first set of announcements through 20 the first channel and transmitting the second set of announcements through the second, different channel.

The method may comprise transmitting the first set of announcements according to a session announcement protocol (SAP), unidirectional hypertext transfer protocol 25 (UHTTP), asynchronous layered codmg (ALC) protocol or similar unidirectional protocol based on user datagram protocol (UDP). The method may comprise including a description of a corresponding session in each announcement, for

example arranged according to session description protocol (SDP).

30 The method may comprise providing means for determining whether all of the first set of announcements have been provided, for example by providing the first set of announcements as a series of linked messages.

(I - 5

The method may comprise providing the first set of announcements in a first set of time slots and providing the second set of announcements in a second set of time slots, each t1meslot of the first set of timeslots being provided at a different time from each timeslot of the second set of timeslots. The method may comprise s multiplexing the first and second sets of announcements.

According to a second aspect of the present invention there is provided a computer program which, when executed by data processing apparatus, causes the data processing apparatus to perform a method of announcing sessions transmitted 10 through a network.

According to a third aspect of the present invention there is provided a method of accessing sessions transmitted through a network, the method comprising selectively receiving a first set of announcements describing a plurality of sessions; 5 and selectively receiving a second set of announcements describing at least one updated session.

The method may further comprise determining whether all of said first set of announcements have been received. The method may further comprise selecting 20 not to receive further said first set of announcements and selecting to receive said second set of announcements. The method may further comprise selecting not to receive a third set of announcements describing another plurality of sessions mclud1ng said at least one updated session. The method may further compose selecting to receive a fourth set of announcements describing at least one further 25 updated session.

According to a fourth aspect of the present invention there is provided a method of accessing sessions transmitted through a network, the method comprising listening to a first set of announcements describing a plurality of sessions, determining 30 whether said first set of announcements have been received; if said first set of announcements have been received, then stopping listening to said first set of announcements and listening to a second set of announcements describing at least one updated session.

t - 6 The method may further comprise stopping listening to a third set of announcements describing a further plurality of sessions including said at least one updated session.

According to a fifth aspect of the present invention there IS provided apparatus for announcing sessions transmitted through a network, the apparatus comprising means for providing a first set of announcements describing a plurality of sessions and means for providing a second set of announcements describing at least one TO updated session.

According to a sixth aspect of the present invention there is provided apparatus for performing the method.

15 According to a seventh aspect of the present invention there is provided apparatus for announcing sessions transmitted through a network, the apparatus comprising a first transmitter for providing a first set of announcements describing a plurality of sessions and a second transmitter for providing a second set of announcements describing at least one updated session.

The apparatus may comprise means for managing an electronic service guide for announcing sessions to be transmitted through the network, means for managing content of sessions to be transmitted through the network, means for storing and electronic service guide for announcing sessions to be transmitted through the 25 network, means for storing content of sessions to be transmitted through the network, means for determining changes to an electronic service guide, the changes corresponding to updated sessions to be transmitted through the network, a server for providing information relating to changes to an electronic service guide, the changes corresponding to updated sessions to be transmitted through the network, a 30 server for providing content and/or means for transmitting data.

According to an eighth aspect of the present invention there is provided apparatus for accessing sessions transmitted through a network, the apparatus comprising

(I - 7

means for selectively receiving a first set of announcements describing a plurality of sessions and means for selectively receiving a second set of announcements describing at least one updated session.

5 The apparatus may comprise means for determining whether said first set of announcements has been received the apparatus being configured such that if the determining means determines that the first set of announcements has been received, then the means for selectively receiving said second set of announcements is configured to receive the second set of announcements.

The apparatus may comprise means for selectively receiving a third set of announcements describing another plurality of session including the at least one updated session, the apparatus being configured such that if said determining means determines that the first set of announcements has been received, then the means 15 for selectively receiving the third set of announcements is configured not to receive or not to forward the third set of announcements The apparatus may comprise means for receiving data, means for filtering an electronic service guide for announcing sessions to be transmitted through the 20 network, means for storing an electronic service guide for announcing sessions to be transmitted through the network, means for browsing an electronic service guide for announcing sessions to be transmitted through the network, means for filtering content, means for storing content and/or means for browsing content.

25 The apparatus may be a mobile communications device.

According to a ninth aspect of the present invention there is provided a system for presenting program schedule data on a display, said system comprising at least two announcements, the schedule data being organized at least partly from a first set of 30 announcements describing at least partly a plurality of sessions and at least partly from a second set of announcements describing at least one at least partly updated session.

(of) - 8 According to an tenth aspect of the present invention there is provided a system for presenting program schedule data on a display, said system comprising at least two announcements, the schedule data being organized at least partly from a first set of repeatable announcements describing a plurality of sessions, at least partly from a s second set of repeatable announcements describing at least one at least partly updated session and at least session descriptions of at least one of the repeatable

announcements for defining whether the at least one of the first and second announcements is received or not.

0 According to a eleventh aspect of the present invention there is provided a system for delivering program schedule data to end-user terminals, said system composing two sets of announcements, each set comprising at least one announcement, the schedule data being organized at least partly from a first set of announcements describing at least partly a plurality of sessions and at least partly from a second set 5 of announcements describing at least one at least partly updated session.

According to a twelfth aspect of the present invention there is provided a system for presenting program schedule data to end-user terminals, said system comprising at least two set of announcements, each set comprising at least one announcement, 20 the schedule data being organized at least partly from a first set of repeatable announcements describing a plurality of sessions, at least partly from a second set of repeatable announcements describing at least one at least partly updated session and at least session descriptions of at least one of the repeatable announcements for

defining whether the at least one of the first and second announcements is received 25 or not.

The second set of announcements may include a version number of each updated session for allowing a client to detect if they have missed an earlier update. If a client detects it has missed an earlier update and IS not currently receiving the first 30 set of announcements, the client may start receiving the first set of announcements until it has received a full and latest version of the program schedule data. If the client detects that it has received a full and latest version of the program schedule data, it may stop receiving the first set of announcements and continues receiving

only the second set of announcements. If the client detects it has missed an earlier update, it may fetch a full and latest version of the program schedule data over an interactive network. Each set of repeatable announcements may be divided into segments before transmission and a location of each segment within a whole s transfer may be indicated in a framing field of each respective segment; the

indicated location may enable clients to determine whether they have received all segments that constitute a given set or whether they need to wait for receiving more segments. 10 The program schedule data may be viewed either directly by a human end-user or automatically used by a software application. The program schedule data may be presented progressively to a human end-user or made progressively available to an automatic software application as the said data is being received. The program schedule data may be viewed by a human end-user via a graphical user interface.

15 The program schedule data may be used by a personal video recorder.

Embodiments of the present invention will now be described by way of example with reference to the accompanying drawings in which: Figure 1 is a schematic diagram of a multicasting system 1; 20 Figure 2 shows content stored in a content database; Figure 3 shows a session directory; Figure 4 shows electronic service guide data stored in an electronic service guide database; Figure 5 shows updated content stored m a content database; 25 Figure 6 shows an updated session directory; Figure 7 shows updated electronic service guide data stored in an in an electronic service guide database; Figure 8 shows a first example of an improved session directory before an update; Figure 9 shows the session directory shown in Figure 8 after the update; 30 Figure 10 shows electronic service guide data before an update; Figure 11 shows electronic service guide data after an update; Figure 12 shows a session announcement message using SAP and SDP protocols;

() - 1 0

Figure 13 illustrates transmission of a description of an improved session directory

using session announcement messages shown in Figure 12; Figure 14 is a process flow of a method of operating a datacast service system; Figure 15 is a process flow of a method of operating a datacast client; s Figure 16 shows a second example of an improved session directory after an update; Figure 17 shows splitting electronic service guide data into data segments; Figure 18 another session announcement message using UDP and UHTTP protocols; Figure 19 illustrates transmission of a description of an improved session directory

10 using session announcement messages shown in Figure 18; Figure 20 shows transmission of a description of an improved session directory

using session announcement messages using time division multiplexing; Figure 21 shows a schematic diagram of a terminal used to receive multicast data and 15 Figure 22 shows an electronic service guide browser.

MnIticasting system 1 Referring to Figure 1, a multicasting system I is shown. In this example, the multlcasting system I is an internet protocol (IP) datacast system. The multicastmg 20 system 1 includes a datacast service system 2, a datacaster 3, a datacast network 4 and a plurality of clients 5. For clarity, only one client 5 is shown.

An administrator 6 provides content, such as audio, video and/or other types of data, for datacasting to clients 5 and provides metadata for describing the content.

25 The metadata includes information regarding transmission of content.

The datacast service system 2 generates IP streams Carrying content items and related metadata for datacasting to clients 5. The datacaster 3 receives IP streams from the datacast service system 2, provides Layer 2 encapsulation and modulation 30 and transmits the IP data to clients 5 over the datacast network 4. The datacast network 4 is a point-tomultipoint network for delivering IP-based data. Typically, the datacast network 4 supports a plurality of simultaneous datacasts to clients 5. In this example, the datacast network 4 does not provide a return data path from the

- 11 client 5 to the datacaster 3. The datacast network 5 may be for example a Digital Video Broadcasting (DVB) network, a Digital Audio Broadcasting (DAB) network, an Advanced Television Systems Committee (ATSC) network, an Integrated Services Digital Broadcastmg (ISDB) network or a Wireless Local Area Network 5 (WLAN). The client 5 comprises a terminal for receiving content and content descriptions over the datacast network 4 and presenting them to an end-user 7. The

terminal may be fixed, such as a desk-top personal computer or a television set-top box, or portable, for instance a lap-top or notebook personal computer, personal digital assistant or mobile telephone handset.

The datacast service system 2 includes an electronic service guide (ESG) management module 8, a content management module 9, an ESG database 10 for storing metadata for the electronic service guide, a contents database 11 for storing content for datacasting, a service discovery server 12 and a content server 13.

The ESG management module 8 allows the administrator 6 to control metadata for describing datacast content. Content items can be grouped into IP services and IP sessions. Content items can be allocated (or deallocated) time slots for transmission. Thus, the metadata describes the structure of content items as a 20 hierarchy of IP services and IP sessions. The metadata may also include information on the transmission schedule of IP sessions and individual content items within IP sessions.

The content management module 11 allows the administrator 6 to add, replace and 25 delete content items in the content database 12.

The service discovery server 10 generates announcements of IP services and IP sessions based on the metadata found in the ESG database 9. The announcements are sent to the datacaster 3 for transmission over the datacast network 4.

As will be explained in more detail later, two kinds of announcements are generated.

A first kind of announcement describes a full IP service directory and a second kind of announcement describes updates to the IP service directory.

- 12 The content server 13 retrieves scheduling information from the ESG database 9 and, based on the scheduling information, retrieves content from the content database 11 and sends it to the datacaster 3 for transmission over the datacast 5 network 4.

The client 5 includes a datacast receiver 14, a service discovery client 15, an ESG database 16 for storing metadata for the electronic service guide, an ESG browser 17, a content filtering application 18, a content database 19 and a content browser 10 20.

The datacast receiver 14 receives data over the datacast network 4 whereupon it demodulates and decapsulates the data. In this case, the datacast receiver 14 forwards the demodulated and decapsulated data to an IP stack (not shown). The 15 demodulated and decapsulated data comprises IP packets carrying content streams or metadata describing content. The IP packets are forwarded from the stack (not shown) to IP-based applications 15, 18 running on the client 5.

The service discovery client 15 receives the IP packets on one or more given 20 addresses and one or more given ports for carrying IP service announcements. As will be explained in more detail later, the service discovery client 15 can receive announcements of the first type describing the full service directory and, either alternatively or additionally, announcements of the second type describing updates to service directory. The IP packets carry metadata which can be stored in the ESG 25 database 16 or forwarded directly to the ESG browser 17.

The ESG database 16 has an information structure very similar to the server-side ESG database 9. The ESG database 16 is imtially empty, for example when the client 5 is first switched on, but fills up and is updated as IP session announcements 30 are received from the datacast service system 2.

The ESG browser 17 allows the end-user 7 to view schedules and descriptions of IP

services, sessions and content items available from the datacaster service system 2.

(A - 13

The ESG browser 17 can retrieve metadata from the ESG database 16 or receive metadata directly from the service discovery client 15.

The content filtering application 18 receives the IP packets on one or more given s addresses and one or more given ports configured by the content browser 20 or other applications running on the client. The IP packets carry content which can be stored m the content database 19 or forwarded directly to the content browser 20.

The content browser 201S loaded and run when the end-user 7 has selected a TO particular datacast content item for consumption. The content item can be received in real time or retrieved from the content database 19. The content browser 20 can be for example a Web browser, an MP3 player or a streaming video client.

The multicasting system 1 may allow automatic content uploading by external 15 content providers (not shown) and forwarding of Internetbased content. The datacaster 3 can also deliver content to a plurality of datacast networks (not shown), each datacast network comprising one or more transponders.

Sessions 20 Referring to Figure 2, content 21 is shown which is stored in the content database 11 and which includes first, second, third and fourth sessions 221, 222, 223, 234. The first, second and third sessions 22, 222, 223 comprise data relating to soccer. For example, the first session 221 may include text relating a game, the second session 222 include video streaming and the third session may include audio streaming 223.

2s The fourth session 224 comprises data relating to hockey. A session 221, 222, 223, 234 may comprise a single IP stream or a plurality of IP streams.

Session Directory Referring to Figure 3, a session directory 23 is shown according to which the 30 sessions 221, 222, 223, 224 are organised. The session directory 23 includes, at a first level, categories such as sports 241. Further examples of categories include arts, business, computers, games, news and shopping and other categories which are commonly found on web portal sites. Each category includes, at a second level,

(I) - 14

sub-categories, such as soccer 25, and hockey 252. Each sub-category may be further sub-divided. For instance, the soccer sub-category 25, can be divided into soccer leagues, each of which may be divided into league divisions and each of which in turn may be divided into players.

s Each category, sub-category or further sub-category may include one or more sessions. For example, the soccer sub-category 25 includes the first, second and third sessions 22, 222, 223, while the hockey sub-category category 252 includes the fourth session 224.

Referring to Figure 4, ESG data 26 is shown which is stored in the ESG database 9.

The electromc service guide data 26 includes first, second, third and fourth sets of metadata 271, 272, 273, 274 for describing the first, second, third and fourth sessions 22, 222, 223, 224 respectively. The ESG data 26 reflects the structure of the session 15 directory 22.

The ESG data 26 is transmitted to clients 5 so as to provide an ESG for users.

However, there is a problem if the ESG data 26 needs to be updated, as will now be explained: Referring to Figures 1, 2, 3 and 4, initially, ESG data 26 is transmitted from the datacast service system 2 to the client 5. The datacast service system 2 sends sets of metadata 27,, 272, 273, 274 to the datacaster 3 to be transmitted to clients 5. The client 5 begins to receive the sets of metadata 27', 272, 273, 274 and starts to fill the 25 initially empty ESG database 16. Eventually, all the sets of metadata 27,, 272, 273, 274 are received and are stored in the ESG database 16. At this point, the ESG is complete. Referring to Figure 5, the content database 12 1S updated and corresponding 30 updated content 21' is shown. The updatedcontent 21' includes an updated session 21' and a new session 215. For example, the first session 21 may be updated by replacing a match preview with a match report. The new session 215 may be a text file with a hockey fixture list.

: - 15

Referrng to Figure 6, an updated session directory 23' is shown and includes the updated session 21'and the new session 215.

s Referring to Figure 7, an updated ESG data 26' is shown including an updated first sets of metadata 271, and a new set of metadata 27s.

Referring to Figures 1, 4, 6 and 7, the updated ESG data 26' is transmitted from the datacast service system 2 to the client 5. The datacast service system 2 sends the 0 updated ESG data 26' to the datacaster 3 for transmission. The client 5 then receives updated sets of metadata 27', 272, 27, 274, 27s. However, the client 5 does not know whether each set of metadata 271', 272, 273, 274, 27s relates to existing or updated sessions. Thus, each incoming set of metadata 271', 272, 273, 274, 27s is compared with stored sets of metadata 27, 272, 273, 274 to check whether they 5 relate to an updated data session. Processing metadata in this way is wasteful.

Furthermore, there can be delay between the first session 21, being updated and the electronic service guide at the client 5 being revised.

Therefore, it is desirable to provide an improved session directory and an improved 20 ESG.

One solution to the problem is to split the session directory and divide transmission of the ESG accordingly. Description of the session directory is transmitted by

sending two types of session announcements one for describing the full session 2s directory and another for describing an updated session directory, as will now be described in more detail: Split Session Direoy First Example Refernng to Figures 8 and 9, a first example of an improved session directory 28, 30 28' is shown before and after an update respectively.

The session directory 28, 28' is split into two parts at a relatively high level, in this example above the category level, and the two parts are referred to as the full

() - 1 6

session directory 291 and the updated session directory 292 respectively. Later, in a second example, a session directory is described which is split at a relatively low level. s The full session directory 29 includes substantially the same categories described earlier, such as sports 241. Each category includes sub-categories, such as soccer 25 and hockey 252. Similarly, there may be further sub-categories. Each category, sub category or any further sub-category may include one or more sessions. In this case, the soccer sub-category 251 includes the first, second and third sessions 221, to 222, 223 and the hockey sub-category category 252 includes the fourth sessions 224.

The updated session directory 292 also includes categories which correspond to the categories in the full session directory, such as sports 30. Similarly, each corresponding category includes corresponding sub-categories, such as soccer 31 15 and hockey 312. Similarly, there may be corresponding further sub-categories. Each corresponding category, corresponding sub-category or any corresponding further sub-category may include, if there has been an update, one or more updated sessions. 20 Before the update, the updated session directory 292 does not list any sessions.

After the update, the updated directory 292 lists updated sessions. In this case, the soccer sub-category 31 includes the updated, first session 22' and the hockey sub-

category category 312 includes the fifth session 22s.

This configuration is used to send two types of session announcements. One type of announcement is used to describe all sessions. Another type of announcement is used to describe updated sessions.

30 Thus, the client may listen initially to announcements of the fist type so as to receive a description of all the sessions, i.e. the full session directory. Once the

client has received the description of all sessions, the client may 1lsten only to

announcements of the second type so as to learn of any updates to the sessions.

- 17 Session Announcements using SAP and SDP Referring to Figures 10 and 11, a first example of improved ESG data 32, 32' is shown before and after the update.

s The improved ESG data 32 includes first, second, third and fourth sets of metadata 33, 332, 333, 334 for describing the first, second, third and fourth sessions 22,, 222, 223, 224 respectively.

10 The updated, Improved ESG 32' includes the updated first, second, third, fourth and fifth sets of metadata 33', 332, 333, 334, 33s for describing the updated first, second, third, fourth and fifth sessions 221', 222, 223, 224, 22s respectively.

A Session Announcement Protocol (SAP) IS used to transmit sets of metadata 333, 5 331', 332, 333, 334, 33s to clients 5 and a Session Description Protocol (SDP) is used

to describe the sessions 21, 221', 222, 223, 224, 22s. Reference is made to "Session Announcement Protocol" by M. P. Maher, C. Perkins & E. Whelan, RFC 2974, IETF, October 2000 and to "Session Description Protocol" by M. Handley & V.

Jacobson, RFC 2327, IETF, April 1998.

The use of the Session Announcement Protocol and the Session Description

Protocol advantageously permits information describing the structure of session directories to be transmitted to clients 5. Reference is made to "Describing session directories in SDP" by R. Finlayson, Internet Draft, IETF, January 2001 and 25 "Towards multicast session directory services" by A. Santos, J. Macedo & V. Freltas.

Referring to Figure 12, a session announcement 34 is shown. The session announcement 34 comprises an SAP header 35 and payload in the form of an SDP description 36 of a session. The SDP description 36 includes a set of metadata 33

30 for describing a session.

Referring to Figure 13, a description of the session directory 28 is transmitted by

sending two types of session announcements 37,, 372 each describing a session

- 18 directory, in this case the full session directory 291 and the updated session directory 292 respectively.

The first type of session announcements 371 is used to send descriptions of all

5 sessions, i.e. the full session directory 291. During an earlier cycle 38, the announcements 341, 342, 343, 344 describe all sessions 221, 222, 223, 224 before the update and, during a later cycle 382, the announcements 34', 342, 343, 344, 34s describe all sessions 221', 222, 223, 224, 22s after the update.

10 The second type of announcements 372 is used only to send descriptions of sessions

that have been added, removed or changed since the transmission of announcements 34', 342, 343, 344 during the earlier cycle 381. In this example, no cycle precedes the earlier cycle 381. Thus, during the earlier cycle 381, there are no announcements of the second type 372. Durmg the later cycle 381, the 15 announcements 341', 34s describe updated sessions 221', 22s (Figure 9).

Usually, there will be more than two cycles 381, 382 of announcements.

Furthermore, more sessions may be updated. Thus, each subsequent cycle (not shown) may or may not include announcements of the second type 372. Optionally, 20 announcements of the second type 372 may be sent repeatedly during a cycle to protect against irrecoverable transmission errors.

Preferably, the structure of the session directory 28 (Figure 9) is described using a hierarchy of multicast IF addresses using SDP and SAP.

A process of describing the structure of the session directory 28 includes transmitting a first session announcement on a given multicast address. The first session announcement includes a second multicast address and other details relating to a session directory. The process includes transmitting a second session 30 announcement on the second multicast address. The second session announcement includes a third multicast address and other details relating to a session sub-

directory. Because sub-directories in turn can be used to announce a succeeding level of a session directory, the session directory hierarchy can be organized as a

: - 19

tree of any depth. In this example, a root or default session announcement (not shown) is transmitted on a widely known address, which specifies a pair of addresses for receiving announcements of the first and second types 37, 372 respectively. s One or more "category" fields may be included in the session announcements for

allowing clients 5 to filter and organize session announcements.

As described earlier, announcements of the first type 371 are transmitted on a first 10 IP address, such as 224.2.17.0.

Referring to Figure 13, the first session announcement 34, may include an SDP description 36 of the first session 221 including, for example:

15 v=0 o=jamith 2890842807 2890844525 IN IP4 10.47.16.5 c=IN IP4 224.2.17. 12/127 t=2892054126 2892399688 m=data 9875 OHTTP UDP 20 a=cat:Full.Sports. Soccer If the first session announcement 34, is updated, then the updated first session announcement 34,' map include an SDP description 36 of the updated first session

221' including, for example: v=o o=jsmith 2890842807 2890844526 IN IP4 10. 47.16.5 c=IN IP4 224.2.17.12/127 t=2892054126 2892399726 30 m=data 9875 OHTTP ODP a=cat:Full.Sports.Soccer Likewise, the second session announcement 342 may include an SDP description 36

of the second session 222 including, for example:

(A - 20

v=0 o=jamith 2890842807 2890844526 IN IP4 10.47.16.5 c=IN IP4 224.2.17. 13/127 t=2892054126 2892399726 5 m=video 9875 RTP/AVP 31 a=cat:Full. Sports.Soccer Announcements of the second type 372 are transmitted on a second IF address, such as 224.2.17.1.

Referring still to Figure 13, the updated first session announcement 341' may include an SDP description 36 of the updated hrst session 221' (Figure 9) including for

example:

15 v=0 o=jamith 2890842807 2890844526 IN IP4 10.47.16.5 c=IN IP4 224.2.17. 12/127 t=2892054126 2892399726 m=data 9875 OHTTP UDP 20 a=cat:Opdate. Sports.Soccer The updated session 221' (Figure 9) may be identified as an updated session in a number of ways: 25 Firstly, the first session announcement 341 and the updated first session announcement 34,' specify different version numbers in the "a=" field, namely

2890844525 and 2890844526 respectively. Thus, identifying an updated session may include comparing version numbers of the first and updated first session announcements 341, 341' and noting different version numbers.

Secondly, the updated first session announcement 341'is provided through a different channel, in this case a different IF address, which is reserved for announcements relating to updated sessions. Thus, identifying an updated session may include receiving an announcement on a different channel.

(A - 21

Thirdly, the updated first session announcement 341' includes a category field,

which identifies the fact that the session announcement relates to an update. Thus, identifying an updated session may include determining whether an announcement identifies itself as relating to an update and/or determining a position within a 5 session directory.

Method of operating the datacast service system 2 Referring to Figures 1 and 14, a method of operating the datacast service system 2 is shown. The ESG management module 8 identifies whether sessions have been updated in the content database 12 (step S1). If it identifies any updated sessions, then it updates corresponding sets of metadata in the ESG database (step S2). Updating may include adding or deleting metadata. Metadata is passed to the service 5 discovery server 10, which generates updated session announcements for any updated sets of metadata (step S3). The service discovery server 10 forwards a first set of announcements describing a plurality of sessions, in other words full session announcements, and a second set of announcements describing at least one updated session, in other words updated session announcements, to the datacaster 3 through 20 different channels, such as different IF addresses (steps S4 & S5). The datacaster 3 receives the announcements and transmits them over the datacast network 4 to each clients 5.

Method of operating client 5 2s Referring to Figures 1 and 15, a method of operating the client 5 is shown.

The client 5 checks whether it has received all the session announcements of the first type 37 (step T1). If not, the client 5 listens to both types of announcements 371, 372 (step T1& T2). However, if the client 5 has received all the session 30 announcements of the first type 371, then it can stop listening to announcements of the first type 37, and continue listening only to announcements of the second type 372. This has the advantage that it saves processing power and electrical power because fewer session announcements are received and/or processed.

(A - 22

The first and second types of announcements 37, 372 may include multicast addresses of announcements relating to other session directories, which in turn may include multicast addresses of announcements relating to further session directories.

Announcements of the first type 37 may be considered as relating to a session directory including sub-directories to a given depth of directory hierarchy.

Announcements of the second type 372 may likewise be considered as relating to a session directory including sub-directories to a given depth of directory hierarchy.

10 If announcements of either type 37, 372 relate to more than one session directory, then they can be used to announce the details of a different sub-tree of the IP session hierarchy. Thus, if descriptions of multiple subdirectories are transmitted

using announcements of the first type 371, then the client 5 may stop receiving announcements relating to a particular subdirectory as soon as it has received all the 15 different session descriptions of that subdirectory.

Split Session Directory - Second Example Referring to [Figure 16, a second example of an improved session directory 28" is shown. The session directory 28" is split into two parts at a relatively low level, m 20 this example above the session level, and the two parts are referred to as the full session directory 291a, 291b and the updated session directory 292a, 292b respectively.

The ESG data 32 and the updated ESG data 32' are modified to reflect the structure of the second example of an improved session directory 28".

2s Session Announcements using UHITP A drawback of using session announcements employing SAP and SDP is that it is difficult for a client 5 to establish when it has received enough announcements of the first type 37 to describe the full session directory 291. Announcements 34', 30 342, 343, 344, 34s may be lost or corrupted and these protocols do not allow such events to be detected.

: - 23

In an alternative embodiment, this problem is solved by linking together session announcements describing the full session directory 291.

A Unidirectional Hypertext Transfer Protocol (UHTTP) is used to implement a s concatenated transfer of multiple session descriptions and references are made to

the Society of Motion Picture and Television Engineers standard SMPTE 364M 2001 "Declarative Data Essence --- Unidirectional Hypertext Transport Protocol" and to "Appendix C: The Unidirectional Hypertext Transfer Protocol (UHTTP)" in Enhanced Content Specification, Advanced Television Enhancement Forum.

UHTTP supports MIME multipart/related content-type protocol, so allowing a single UHTTP transfer to comprise multiple independent MIME objects and reference is made to "The MIME Multipart/Related Content-type" by E. Levinson, RFC 2387, IETF (1998).

Referrmg to Figure 17, the ESG data 32 is considered as a single resource 39 which can be split into a plurality of data segments 40,, 402, 4O3. In this example, there are fewer data segments than there are sets of metadata. However, the number of data segments may be equal or greater than the number of sets of metadata. Redundant 20 error correction segments (not shown) may be calculated and interleaved with the data segments 40,, 402, 4O3. The updated electronic service guide data 32' is processed in the same way.

Referring to Figure 18, a user datagram protocol (UDP) packet 41 IS shown which 25 Includes a UDP header 42 and a UDP payload 43. The UDP payload 43 includes a UHTTP packet 44 which includes a UHTTP header 45 and a data segment 40,, 402, 4O3 as payload. UHTTP allows each data segment 40, 402, 4O3 to be numbered.

Referring to Figure 19, ESG data 32 is transmitted as a linked transfer and updated 30 ESG data 32'is also transmitted as a linked transfers. For the ESG data 32, first, second and third UDP packets 411, 412, 413 are transmitted. Likewise, for the updated ESG 32', fourth, fifth and sixth UDP packets 414, 415, 416 are transmitted.

In each case, if one or more UDP packet 41,, 412, 413, 414, 415, 416 is unsuccessfully

O - 24

transmitted or data segment contained therem is unsuccessfully retrieved, then corresponding UDP packets 411, 412, 413, 414, 415, 416 are retransmitted.

Descriptions of updated sessions are transmitted in a seventh UDP packet 417.

s As described earlier, a default session announcement may be used to provide details of the full and updated session directories 291, 292. An example of a default session announcement may include: 10 v= 0 o=dcaster 4289098098 4289099125 IN IP4 130.230.3.2 s=Experimental session directory service i=Full and update session directories delivered via OTTP u=https://www.datacaster.com 15 e=dcasterdatacaster.com c=IN IP4 224.2.17. 12/127 t=2873397496 2873404696 m=data 42451 udp ubttp a=X- sessiondirectory- full 20 m=data 42452 udp uhttp a=X-session-directory-updates In this example described, the full session announcements and updated session announcements are provided on different port numbers. Also in this example, 25 UHTTP is used full session announcements and updated session announcements.

However, UHTTP may be used for full session announcements, while SAP and SDP may still be used for updated session announcements.

Numbermg of data segments 4 1, 402, 4O3 allows the client 5 to detect when they 30 have received the ESG data 32. Once this occurs, the client 5 listens for updates.

The use of UHTTP has another advantage. It supports forward error correction (FEC) which can be used to increase the probability of successful transmission even if bit and burst errors occur in transmission. If, however, FEC fails to recover any 35 errors at the client-end, the client 5 waits for periodic UHTTP retransmission.

O - 25

Alternatively, if a return path is provided, then automatic repeat request (ARO) may be used.

Other protocols, such as Asynchronous Layer Coding, which provide reliable s delivery of content may be used.

Asynchronous Layer Coding (ALC) is a scalable reliable content delivery protocol for IP multicastmg and reference is made to "Asynchronous Layer Coding protocol instantiation" by M. Luby, J. Gemmell, L. Vicisano, L. Rizzo and J. Crowcroft, 0 IETF, April 2002.

Reference is also made to "Reliable Multicast Transport Building Blocks for One to-Many Bulk-Data Transfer" by B. Whetten, L. Viclsano, R. Kermode, M. Handley, S. Floyd and M. Luby, RFC 3048, IETF, January 2001.

Reference is also made to "Layered Coding Transport building block" by B. Whetten, L. Vicisano, L. Rizzo, M. Handley, S. Floyd and M. Luby, Internet Draft, IETF, February 2002.

20 Time Division Multiplexing In the embodiments described earlier, IP packets comprising portions of ESG data 32, 32' can be transmitted by the datacaster 3 to the client 5 as-and-when transmission slots become available. However, to ensure that the client 5 receives the IP packets, it is preferable that the client 5 be configured to receive data at any 2s time. This has the drawback of unnecessarily using processing and electrical power.

A solution to this problem is to employ time division multiplexing (TDM).

Referring to Figure 20, an alternative manner of transmitting a description of the

30 session directory 28 is shown. In this example, only a later cycle 382' including the two types of session announcements 37,, 372 is shown.

0 - 26

Announcements of the first type 37, for describing ESG data and announcements of the second type 372 for describing updates to ESG data are transmitted in different time slots 451, 452. For example, the announcements of the first and second types 37, 372 are transmitted in alternate time slots. However, the time s slots 451, 452 need not be adjacent. The time slots may be of variable or fixed length. Thus, if the client 5 wishes to listen for updates to ESG data, then they do not need to listen to time slots 45 during which announcements of the first type 371 are 0 transmitted, but may listen to time slots 452 during which only announcements of the second type 372 are sent. This allows the client 5 to switch off its receiver 14 (Figure 1) during time slots 451.

Datacast client 5 5 Referring to Figure 21, the datacast client 5 comprises a processor 46, input/output interface 47, memory 48, a receiver 49 and a transceiver 50 which are connected via a bus 51. The input/output interface 47 is connected to a user interface 52, a display 53, storage 54 and speaker 55.

20 The datacast client 5 may be a mobile commumcation device for use with first and second wireless communication networks. For example, the first wireless communication network may be a DVB-T or DAB network and the receiver 49 may be configured to receive and demodulate signals from a DVB-T or DAB network.

The second wireless communication network may be a UMTS network or other 3G, As 2.5G or 2G telecommunications network and the transceiver 50 may be configured to receive/transmit and demodulate/modulate signals via a UMTS or similar network. The datacast client 5 may be a set-top box connected to a television set for use with 30 first and second wired and/or wireless communication networks. For example, the first communication network may be a DVB-T network and the receiver 49 may be configured to receive and demodulate signals from a DVB-T network. The second communications network may the Internet and the transceiver 50 may include a

O - 27

modem (not shown) for connection via a public switched telephone network to an Internet Service Provider Using two networks, sessions and session announcements may be transmitted over s different networks. Alternatively, the first and second types of session announcements may be transmitted over different networks.

Computer programs (not shown) when loaded into memory 48 and run by the processor 46 cause the processor 46, in conjunction with other elements of the 10 device, to provide the service discovery client 15, the ESG browser 17, the content filtering application 18 and the content browser 20 respectively. Storage 54 is used to hold the ESG and content databases 16, 19. The user interface 52 allows the user to provide instructions to the ESG browser 17 and the content browser 20, such as instruction to select a session. The display 53 allows the user to view 5 session descriptions and session content. The speaker 54 allows the user to hear

session content.

ESG browser Referring to Figure 22, an example of an ESG browser window 56 is shown. The 20 window 57 includes a first section 58 for receiving instructions for filtering sessions, for example on the basis of date of transmission, whether a session is current being transmitted or search terms. The window 57 includes a second section 59 for displaying a list of filtered sessions and receiving instructions to select a session.

The window 57 includes a third section 60 for displaying a description of a selected

2s session and receiving instructions to access the session.

It will be appreciated that many modifications may be made to the embodiment hercinbefore described.

30 Session announcements may be unlcast, rather than multicast, to a client.

0 - 28

Sessions and session announcements may be transmitted over different networks.

For example, sessions may be transmitted over a DVB network and session announcements may be sent via a DAB network.

s The first and second types of session announcements may be transmitted over different networks. For instance, announcements of the first type may be transmitted through a DVB-T network, while announcements of the second type may be sent though a 3G network. The first and second types of session announcements may be transmitted through the same network, but over different 10 physical channels, for example at different carrier frequencies. The first and second types of session announcements may be transmitted through the same network and over the same physical channels, but over different logical channels.

Claims

<: - 29 Claims

1. A method of announcing sessions transmitted through a network, the method comprising: s providing a first set of announcements describing a plurality of sessions; and providing a second set of announcements describing at least one updated session.

2. A method according to claim 1, comprising providing said first set of 10 announcements through a first channel and providing said second set of announcements through a second, different channel.

3. A method according to claim 1 or 2, wherein providing said first set of announcements and providing said second set of announcements comprises 15 providing said first set of announcements through a first address and providing said second set of announcements through a second, different address respectively.

4. A method according to any preceding claim, wherein providing said first set of announcements and providing said second set of announcements comprises 20 providing said first set of announcements through a first destination address and providing said second set of announcements through a second, different destination address respectively.

5. A method according to any preceding claim, wherein providing said first set of 25 announcements and provldmg said second set of announcements comprises providing said first set of announcements through a first IP address and providing said second set of announcements through a second, different IP address respectively. 30

6. A method according to any preceding claim, wherein providing said first set of announcements and providing said second set of announcements comprises providing said first set of announcements through a first IP multlcast address and

O - 30

providing said second set of announcements through a second, different IF multicast address respectively.

7. A method according to any preceding claim, wherein providing said first set of s announcements and providing said second set of announcements comprises providing said first set of announcements through a first port number and providing said second set of announcements through a second, different port number respectively. 10

8. A method according to any preceding claim, wherein providing said first set of announcements and providing said second set of announcements comprises providing said first set of announcements through a first logical channel and providing said second set of announcements through a second, different logical channel respectively.

9. A method according any preceding claim, wherein providing said first set of announcements and providing said second set of announcements comprises including in each announcement of said first set of announcements data for identifying said announcement as an announcement which describes a one of said 20 plurality of sessions and in each announcement of said second set of announcements data for identifying said announcement as an announcement which describes a one of said at least one updated session.

10. A method according any preceding claim, wherein providing said first set of 25 announcements and providing said second set of announcements comprises including in each announcement of said first set of announcements respective data for specifying a position of a corresponding session within a first portion of a session directory and including in each announcement of said second set of announcements respective data for specifying a position of a corresponding session 30 within a second portion of the session directory.

11. A method according to any preceding claim, wherein providing said first set of announcements and providing said second set of announcements comprises

O - 31

providlug said first set of announcements through a first physical channel and providing said second set of announcements through a second, different physical channel respectively.

5

12. A method according to any preceding claim, wherein providing said first set of announcements and providing said second set of announcements comprises providing said first set of announcements through a first network and providing said second set of announcements through a second, different network respectively.

10

13. A method according to any preceding claim, further comprising providing a third set of announcements describing another plurality of sessions including said at least one updated session.

14. A method according to any preceding claim, comprising: 15 providing said first set of announcements through a first channel; providing said second set of announcements describing at least one updated session through a second, different channel; and providing a third set of announcements describing another plurality of sessions including said at least one updated session through said first channel.

15. A method according to any preceding claim, comprising arranging the providing of said second set of announcements after the providing of said first set of announcements.

25

16. A method according to any preceding claim, wherein providing said first set of announcements and providing said second set of announcements comprises transmitting said first set of announcements through a first channel and transmitting said second set of announcements through a second, different channel.

30

17. A method according to any preceding claim, comprising transmitting said first set of announcements according to a session announcement protocol (SAP).

O - 32

18. A method according to any preceding claim, comprising transmitting said first set of announcements according to a unidirectional transport protocol.

19. A method according to any preceding claim, comprising transmitting said first s set of announcements according to unidirectional hypertext transfer protocol (UHTTP).

20. A method according to any preceding claim, comprising transmitting said first set of announcements according to asynchronous layered coding (ALC) protocol.

21. A method according to any preceding claim, comprising transmitting said first set of announcements according to user datagram protocol (UDP).

22. A method according to any preceding claim, comprising including a 15 description of a corresponding session in each announcement.

23. A method according to any preceding claim, comprising including a description of a corresponding session arranged according to session description

protocol (SDP) in each announcement.

24. A method according to any preceding claim, comprising providing means for determining whether all of said first set of announcements have been provided.

25. A method according to any preceding claim, comprising providing said first 25 set of announcements as a series of linked messages.

26. A method according to any preceding claim, comprising providing said first set of announcements in a first set of time slots and providing said second set of announcements in a second set of time slots, each timeslot of said first set of 30 timeslots being provided at a different time from each timeslot of said second set of tlmeslots.

O - 33

27. A method according to any preceding claim, comprising multiplexing said first and second sets of announcements.

28. A method substantially as hereinbefore described with reference to Figures I s to 22 of the accompanying drawings.

29. A computer program which, when executed by data processing apparatus, causes the data processing apparatus to perform a method of announcing sessions transmitted through a network according to any preceding claim.

30. A method of accessing sessions transmitted through a network, the method compusmg: selectively receiving a first set of announcements describing a plurality of sessions; and 15 selectively receiving a second set of announcements describing at least one updated session.

31. A method according to claim 30, further comprising determining whether all of said first set of announcements have been received.

32. A method according to claim 31, further comprising selecting not to receive further said first set of announcements and selecting to receive said second set of announcements. 25

33. A method according to claim 31 or 32, further comprising selecting not to receive a third set of announcements describing another plurality of sessions including said at least one updated SeSSlOn.

34. A method according to any one of claims 31 to 33, further comprising 30 selecting to receive a fourth set of announcements describing at least one further updated session.

O - 34

35. A method of accessing Sessions transmitted through a network, the method composing: listemng to a first set of announcements describing a plurality of sessions; determining whether said first set of announcements have been received; s if said first set of announcements have been received, then stopping listening to said first set of announcements and listening to a second set of announcements desctlbmg at least one updated session. 10

36. A method according to claim 35, further comprising: stopping listening to a third set of announcements describing a further plurality of sessions including said at least one updated session.

37. Apparatus for announcing sessions transmitted through a network, the 15 apparatus comprising: means for providing a first set of announcements describing a plurality of sessions; and means for providing a second set of announcements describing at least one updated session.

38. Apparatus for performing the method according to any one of claims 1 to 28.

39. Apparatus for announcing sessions transmitted through a network substantially as hereinbefore described with reference to Figures 1 to 22 of the 25 accompanying drawings.

40. Apparatus for announcing sessions transmitted through a network, the apparatus comprising: a first transmitter for providing a first set of announcements describing a 30 plurality of sessions; and a second transmitter for providing a second set of announcements describing at least one updated session.

O - 35

41. Apparatus for accessing sessions transmitted through a network, the apparatus comprlsmg: means for selectively receiving a first set of announcements describing a plurality of sessions; and 5 means for selectively receiving a second set of announcements describing at least one updated session.

42. Apparatus according to claim 41, comprising: means for determining whether said first set of announcements has been 10 received; said apparatus being configured such that if said determining means determines that said first set of announcements has been received, then the means for selectively receiving said second set of announcements is configured to receive said second set of announcements.

43. Apparatus according to claim 42, comprising: means for selectively receiving a third set of announcements describing another plurality of session including said at least one updated session; said apparatus being configured such that if said determining means 20 determines that said first set of announcements has been received, then the means for selectively receiving said third set of announcements is configured not to receive or not to forward said third set of announcements.

44. Apparatus according to any one of claims 41 to 42 which is a mobile 25 communications device.

45. Apparatus for accessing sessions transmitted through a network substantially as hereinbefore described with reference to Figures 1 to 22 of the accompanying drawings.

46. A system for presenting program schedule data on a display, said system comprising at least two announcements, the schedule data being organized at least partly from a first set of announcements describing at least partly a plurality of

: - 36

sessions and at least partly from a second set of announcements describing at least one at least partly updated session.

47. A system for presenting program schedule data on a display, said system s comprising at least two announcements, the schedule data being organized at least partly from a first set of repeatable announcements describing a plurality of sessions, at least partly from a second set of repeatable announcements describing at least one at least partly updated session and at least session descriptions of at least

one of the repeatable announcements for defining whether the at least one of the 10 first and second announcements is received or not.

48. A system for delivering program schedule data to end-user terminals, said system comprising two sets of announcements, each set composing at least one announcement, the schedule data being organized at least partly from a first set of 15 announcements describing at least partly a plurality of sessions and at least partly from a second set of announcements describing at least one at least partly updated session.

49. A system for presenting program schedule data to end-user terminals, said 20 system comprising at least two set of announcements, each set comprising at least one announcement, the schedule data being organized at least partly from a first set of repeatable announcements describing a plurality of sessions, at least partly from a second set of repeatable announcements describing at least one at least partly updated session and at least session descriptions of at least one of the repeatable

25 announcements for defining whether the at least one of the first and second announcements is received or not.

50. A system according to any one of claims 47 to 49 claim, wherein the second set of announcements include a version number of each updated session for 30 allowing a client to detect if they have missed an earlier update.

51. A system according to claim 50, wherein if a client detects it has missed an earlier update and is not currently receiving the first set of announcements, the

Wry - 37 client starts receiving the hrst set of announcements until it has received a full and latest version of the program schedule data.

52. A system according to claim 51, wherein if the client detects that it has s received a full and latest version of the program schedule data, it stops receiving the first set of announcements and continues receiving only the second set of announcements.

53. A system according to any one of claims 50 to 52, wherein if the client detects 10 it has missed an earlier update, it fetches a full and latest version of the program schedule data over an interactive network.

54. A system according to any one of claim 47 to 53, where each set of repeatable announcements is divided into segments before transmission and a location of each 5 segment within a whole transfer is indicated in a framing field of each respective

segment; the indicated location enables clients to determine whether they have received all segments that constitute a given set or whether they need to wait for receiving more segments.

20

55. A system according to any one of claims 47 to 54, wherein the program schedule data is viewed either directly by a human end-user or automatically used by a software application.

56. A system according to any one of claims 47 to 55, wherein the program 2s schedule data is presented progressively to a human end-user or made progressively available to an automatic software application as the said data is being received.

57. A system according to claim 55 or 56, wherein the program schedule data is viewed by a human end-user via a graphical user interface.

58. A system according to claim 55 or 56, wherein the program schedule data is used by a personal video recorder.