Method and system for emulating an http server through a broadcast carousel

ES 2 379 347 T3

DESCRIPTION

Method and system to emulate an HTTP server through a broadcast carousel

Field of the invention

[0001] This invention relates generally to the field of interactive television. More specifically, it refers to a method and system for sending and receiving resources in an interactive television system.

Background of the invention

[0002] In a broadcast environment, such as interactive television, a broadcast server generally defines a set of resources to be broadcast over a broadcast path. The broadcast path is typically one-way, and the resources are broadcast to one or more receivers. An interactive television receiver commonly connects to a television or other display device, which can ultimately display resources to a user. The receiver can also communicate with the broadcast server or other devices using a point-to-point route, and the point-to-point route can be used to retrieve resources that are not available on the typically faster broadcast route.

[0003] One type of resource that can be used in an interactive television environment is a Hypertext Markup Language (HTML) resource. HTLM applications can be composed of multiple resources referenced through unique identifiers, such as a Uniform Resource Locator (URL) or a Uniform Resource Identifier (URI). These identifiers point to resources, such as a server or other computer, on which the HTLM application can be stored.

[0004] An application can be licensed in a programming language, for example HTLM and Javascript, and published to a recipient using a Hypertext Transfer Protocol (HTTP) server. A software component, such as a browser, can host the application and display the application's resources. To give an HTLM resource, the HTLM browser typically establishes a connection to the server indicated by an identifier, such as a URL (for example) and loads the resource. The communication scheme between the HTLM browser and the application server is generally a point-to-point scheme, where the HTLM browser establishes a bidirectional connection to the server. This scheme can be contrasted with the one-way broadcast path in an interactive television environment.

[0005] An example of an application that digital television has made possible is interactive television. In an interactive television service, an HTLM browser can intervene on a digital television device. An application is then restored on a screen connected to the digital television device by establishing a connection with the server that publishes the application. Although intended for television use, HTLM's browser-based digital television environment does not provide many of the benefits of a broadcast environment.

[0006] One way to provide HTTP resources in a broadcast environment is by using the Unidirectional Hypertext Transmission Protocol (UHTTP). UHTTP provides a method to broadcast and store resources locally. In UHTTP, a UHTTP server loads the receiver's local cache by sending data until the cache is full or until all data has been sent. One drawback of UHTTP is that the amount of data that can be transmitted to a receiver is limited to the local storage capacities of the receiver. Many commonly used interactive television receivers have limited memory capacity. The local cloaking strategy used for UHTTP to manipulate HTTP resources can therefore unfavorably limit the efficiency of low memory interactive television receivers.

[0007] In addition, interactive television receivers may require resources via either point-to-point or broadcast routes. UHTTP systems, however, require an application to use specific syntax for resource requests from broadcast routes. The syntax used for requests on broadcast routes differs from the syntax for resource requests on point-to-point routes. This difference in syntax can result in an interactive television receiver requesting a resource on the broadcast path that is not available on the broadcast path.

[0008] Therefore, there is a need for a new and improved system and method for sending and receiving resources in an interactive television environment.

[0009] WO00 / 62547 A1 discloses an interactive television system comprising a broadcast station for transmitting data such as web pages to a plurality of receiving stations. Higher demand data is transmitted by broadcast using a data carousel. Lower demand data is transmitted over point-to-point connections (summary ct.). Receiving stations make requests to broadcast stations via point-to-point connection (ct. page 5, line 1). The broadcast station is arranged to retrieve web pages from a web server (page 4, lines 25-30). Selects the transmission channel to receiving stations according to a number of actual or anticipated requests (ct. Page 5, last paragraph; page 4, second paragraph). The receivers are receivers of digital signals like typical personal computers, comprising a microprocessor and an operating system code (ct. page 7, lines 11-17). STBs do not take into account whether they have requested high or low demand data. Therefore, each STB has to control its tuner and its modem for the requested data (ct. Page 7, lines 22-26).

ES 2 379 347 T3

[0010] WO00 / 39947 discloses a system for broadcasting data modules in a carousel form to a digital signal decoder. A top-level data carousel carries at least one directory message that includes module names for all other modules in this or any other data carousel (ct. Page 4, I. 20-22). Directory messages are periodically received by the STB (ct. P. 7, I. 1-6). When an application running on the STB asks to retrieve a module in the data carousel, it registers this request with a director of interest in the STB who maintains a list of requested modules (ct. P. 6, I. 15-18). When a directory message is received by the STB, it verifies the registered interests and removes from the list of registered interests those that no longer exist or that have been updated (ct. Page 12, l. 1-6).

[0011] WO00 / 07361 discloses a digital television system in which HTLM web pages and a control map are transmitted using a data carousel. The control map contains the locations of the HTLM pages in the carousel (summary ct.) To allow the viewer to navigate between the HTLM pages.

Summary

In one aspect of the present invention, a method is provided for processing resource requests in an interactive television system. An interface module can be implemented in an interactive television receiver. The interface module can receive a request for a resource from an application program. The interface module can determine whether the resource is available on a transmission path or a point-to-point path, and it can convert the request received from the application program into a format used for the transmission path or the point-to-point path. The interface module can get the resource from the transmission path or the point-to-point path, and it can provide the resource to the application program.

These as well as other aspects and advantages of the present invention will become apparent to those skilled in the art upon reading the following detailed description, with appropriate reference to the accompanying drawings.

Brief description of the drawings

[0014] An exemplary embodiment of the present invention is described herein with reference to the drawings, where:

Figure 1 is an exemplary architecture for an interactive television system;

Figure 2 shows a division of an interactive television application into modules;

Figure 3 shows an exemplary order for transmitting the modules of Figure 2 to an interactive television receiver via a transmission path;

Figure 4 shows an exemplary interactive television system using a carousel manager;

Figure 5 shows the carousel manager used in the interactive television system of Figure 4;

Figure 6 is a flow chart of an exemplary process for constructing a transmission carousel;

Figure 7 shows a block diagram illustrating an interface module operating in an interactive television receiver;

Figure 8 is a flow chart of an exemplary process for obtaining a resource using the interface module of Figure 7 and Figure 9 is a flow chart of another exemplary process for obtaining a resource using the interface module of Figure 7.

Detailed description of exemplary embodiments

Interactive television architecture

[0015] Interactive television provides a way to transmit interactive content to a television. Interactive television systems can provide text, audio, video, hypertext transmission protocol (HTTP) resources, or other content to a television, and can also receive input from a television user.

[0016] Figure 1 depicts an exemplary architecture for an interactive television system 62. A transmission server 50 sends information along a transmission path 52 to an interactive television receiver 54. The transmission server 50 can be any computer or other type of server capable of sending information along a data link. Streaming server 50 preferably contains a processor and memory. The processor executes programs, which can be stored in memory. Additionally, the memory contains the content to be transmitted along transmission path 52 to interactive television receiver 54.

[0017] Transmission path 52 can be any type of data link and can carry data in a variety of different formats. In a preferred embodiment, transmission path 52 is a cable television transmission path used to transmit cable television signals from a cable television provider to a television 56. The data transmitted along the transmission path 52 can use the same signaling protocols that are used for the transmission of cable television signals along the path.

In another embodiment, transmission path 52 comprises a direct transmission satellite wireless system. A signal is sent wirelessly by a satellite to a satellite dish, or other receiver, connected to the television 56. Once received by the satellite dish, the signal can travel via a data link to the television 56 or to the interactive television receiver 54. In another embodiment, transmission path 52 may be

ES 2 379 347 T3 part of a wireless telecommunications network. For example, one or more terrestrial antennas can be used to send signals over the transmission path to the television. Of course, it may also be possible to use combinations of wired and wireless transmission methods for sending data on transmission path 52.

The interactive television receiver 54 is connected to the transmission path 52 of an interactive television system, and the interactive television system receives interactive television signals sent along the transmission path 52. The interactive television receiver 54 commonly contains a processor and memory. The interactive television receiver 54 is capable of executing programs stored in its memory, and is capable of executing the programs received along the transmission path 52 of the transmission server 50. In a preferred embodiment, the television receiver Interactive 54 includes a digital signal decoder of a type that is well known in the art, connected to television 56. However, another device connected to television 56, such as a computer, game console, or other programmable device, may function as interactive television receiver 54. While interactive television receiver 54 is illustrated as a separate component of television 56, in an alternative embodiment all or part of the functionality of interactive television receiver 54 may be integrated into television 56. In another embodiment, the functionality of the interactive television receiver 54 may be distributed across more than one component connected to the television 56.

The interactive television receiver 54 connects to the television 56 and provides an interface between the broadcast server 50 and the television 56. The interactive television receiver 54, for example, can pass cable television signals directly to the television. television 56, which would allow the common view of cable television signals. The interactive television receiver 54, however, can receive and process interactive television signals sent from the broadcast server 50.

[0021] Interactive television receiver 54, for example, can convert interactive television signals into a format understood by television 56. For example, interactive television signals sent from broadcast server 50 may need to be decompressed or decoded. . The interactive television receiver 54 can perform decoding and decompression to recover the original signals, and can perform other processing on these signals. Interactive television receiver 54 sends interactive television content that has been converted into an appropriate format for viewing to television 56 for viewing. A user can then view interactive television content displayed on television 56.

The interactive television receiver 54 may additionally contain input devices. For example, it may contain a keyboard, mouse, or other devices to allow a user to interact with the television 56 and the interactive television receiver 54. Using the input devices, the user can, for example, respond to data displayed on the screen. television 56. User selections can be used to interactively direct content displayed on television 56, thereby providing an interactive television system.

[0023] In one example, the interactive television system provides a web browsing session to a user. Interactive television receiver 54 connects to the Internet 60 through streaming server 50, and interactive television receiver 54 runs an appropriate browser. Interactive television receiver 54 receives Internet content from Internet 60 via streaming server 50. The interactive television receiver 54 then uses the browser to display Internet content on the television 56. A user can use the keyboard, mouse, or other input device, to navigate through different web pages or links, thus interacting with the television 56 .

In an interactive television system the transmission path 52 is typically unidirectional, although bidirectional transmission paths can be used in interactive television systems. Transmission path 52 may be the same route used to provide cable television services, and cable television services are generally one-way. In a cable television system, signals are sent from a cable television server to television 56. During transmission from the cable television server to television 56, cable television signals can pass through routers. , repeaters or other devices on the network. Since a cable television system does not require feedback from television 56, network elements are commonly configured to support only one-way communication. Therefore, the data cannot be sent back over the cable television lines to the broadcast server 50.

The signals in a direct satellite transmission system are transmitted from a transmission tower to a satellite and then ultimately received by a satellite dish, or other device, connected to a television 56. The satellite dish is also generally equipped to receive only satellite signals and not transmit signals to the satellite. Also, the satellite is not configured to receive signals transmitted from multiple subscribers.

[0026] To enable two-way communication in an interactive television system 62, the interactive television receiver 54 uses a point-to-point route 58, also called a return route. Point-to-point route 58 is typically different from broadcast route 52. Point-to-point route 58 can be any number of data links, but commonly point-to-point route 58 is a telephone line, cable modem, or other. bidirectional link. Point-to-point route 58 could also be a wireless link, such as an interface to a cellular network.

[0027] The point-to-point route 58 connects to the interactive television receiver 54. As shown in the figure

ES 2 379 347 T3

1, the point-to-point route 58 connects to the Internet 60. This can be done, for example, by connecting to an Internet Service Provider (ISP) via a telephone line. The ISP can successively provide connectivity to the Internet 60. Once connected to the Internet 60, the interactive television receiver 54 can access other devices also connected to the Internet 60. For example, the interactive television receiver 54 can communicate with a service provider 64 connected to the Internet 60. The interactive television receiver 54 can send a message via the point-to-point route 58 to the Internet 60, where the message is in last resort directed to service provider 64.

Likewise, the interactive television receiver 54 can communicate with the transmission server 50 via the Internet 60 or via another connected network, thus forming a two-way communication link between the transmission server 50 and the television receiver. interactive 54. Broadcast server 50 preferably sends information to interactive television receiver 54 via broadcast path 52, because the broadcast path is commonly faster than point-to-point path 58. Interactive television receiver 54 can send information to broadcast server 50 using point-to-point route 58.

While Figure 1 illustrates the point-to-point route connection 58 to the Internet 60, it can also be connected to another network or directly to the transmission server 50. Then, the interactive television receiver 54 can communicate with the other devices linked to interactive television receiver 54 via point-to-point route 58. In another embodiment, point-to-point route 58 may be the same as broadcast route 52.

Broadcast carousel

[0030] Broadcast server 50 may send interactive television content to interactive television receiver 54 via broadcast path 52 using a data stream construct hereinafter referred to as a carousel. An interactive television receiver 54 may include memory that can be used to store interactive television content sent from broadcast server 50; however, the memory may be limited in an interactive television receiver 54. Therefore, the interactive television receiver 54 may not be able to store in its memory an entire interactive television application or an entire piece of interactive television content. . Broadcast server 50 can however send interactive television content despite limited memory in interactive television receiver 54 using a carousel.

[0031] The carousel can be implemented as a divided data stream to be transmitted to the interactive television receiver 54 on regular cycles. The cyclical, or periodic, transmission of the data allows the interactive television receiver 54 to retrieve any data not usually in memory within the cycle time of the carousel. That is, the interactive television receiver 54 does not need to memorize an entire program since the parts that do not fit into the limited memory are available during the cyclical transmission of the carousel. The interactive television receiver 54 can retrieve, store, and display television content by extracting the data portions from the carousel.

[0032] In an exemplary process for forming a carousel, the broadcast server 50 first determines what data should be sent to the interactive television receiver 54. The data can be an application to be run on the interactive television receiver 54, it can be web pages for a web browsing session or may be many other types of data or content supported by the interactive television system 62. Broadcast server 50 then divides the data into modules. The modules are generally smaller pieces of data to be transmitted to the interactive television receiver 54 via the broadcast path 52. In addition to dividing the data into modules, the broadcast server 50 additionally forms a directory of the carousel 112. The directory The carousel 112 includes a listing of the carousel modules. The carousel directory 112 allows an interactive television application to determine which part of the carousel to access to obtain the resource. Carousel addresses identify the location of resources on the carousel.

The modules are sent to the interactive television receiver 54, and the interactive television receiver 54 can memorize the modules for use in the interactive television system 62. As the memory available in the interactive television receiver 54 may be limited , the modules are continuously sent to the interactive television receiver 54 in a rotary fashion. When needed, interactive television receiver 54 can retrieve a module from the broadcast path, and it can overwrite one or more previously received modules with the most recently received module.

By shipping the modules in this manner, the interactive television receiver 54 can memorize only a portion of the modules at any given time, but still have access to the other modules. When interactive television receiver 54 needs to access a module that is not in memory, it only has to wait a while before the module is sent as a part of the continuous rotary transmissions of the carousel. This can reduce the amount of memory needed in the interactive television receiver 54 to host large applications.

[0035] Figure 2 shows an exemplary division of an interactive television application into six modules 100, 102, 104, 106, 108, 110. Each module may include one or more parts of the application. Each module can support different amounts of information, and therefore the modules can differ in size. In addition to carrying part of an interactive television application, a module can contain control information, header information, or

ES 2 379 347 T3 other data. Of course, an interactive television application can be divided into a higher or lower number of modules, and an interactive television module can carry one or more partial or complete interactive television applications. In addition to the six data modules 100, 102, 104,106,108,110, a carousel directory 112 is also created. The carousel directory 112 may include a general listing of the interactive television application division into the six data modules 100, 102,104,106,108,110.

[0036] Figure 3 shows an exemplary order for transmission modules on the carousel to interactive television receiver 54 via broadcast path 52. First, carousel directory 112 is transmitted to interactive television receiver 54. Then, module_1 100 and module_2 102 are transmitted to interactive television receiver 54. Then, carousel directory 112 is retransmitted, and module_3 104 and module_4 106 are transmitted. Again, carousel directory 112 is retransmitted and modulo_5 108 and modulo_6 110 are transmitted. After transmission of modulo 6 110, the cycle begins to repeat with transmission of carousel directory 112 and modulo_1 100. The order described in Figure 3 is merely illustrative in nature, and other transmission orders may also be used. .

While the interactive television receiver 54 may have enough memory to memorize all the modules in an interactive television application, its memory time is often limited and it may only be able to memorize a part of the carousel modules. 100, 102, 104, 106, 108, 110. For example, an interactive television receiver 54 may receive the carousel described in Figure 3, and the interactive television receiver 54 may have enough memory to store only three modules simultaneously.

To accommodate the limited memory of the interactive television receiver 54, the carousel modules can be continuously transmitted to the interactive television receiver 54. When an application running on the interactive television receiver needs a module, it can obtain the carousel module. The module can then be stored in memory. Similarly, when the application needs another module, it can get the module from the carousel and memorize the module in its memory. Therefore, the modules can be obtained and stored by the interactive television receiver 54 in the order in which they are requested by the application.

Finally, the interactive television receiver 54 may obtain a module from the carousel, however, it may not have enough memory to memorize the newly obtained module. In this case, the interactive television receiver 54 can delete one or more other modules in its memory. For example, interactive television receiver 54 can delete the oldest module stored in this memory. In another example, interactive television receiver 54 may remove a module that is no longer needed by the application program. In another example, interactive television receiver 54 may use different criteria to determine which module to remove. Since the modules in the carousel can be of different sizes, the interactive television receiver 54 can remove more than one module to clear the newly obtained module. Once the interactive television receiver 54 can clear the newly received module, it can be stored in memory and accessed by the application program.

Carousel manager

[0040] Figure 4 shows an exemplary interactive television system using a carousel director. A carousel can be used to broadcast a service on an interactive television system 212. A service is generally a collection of resources. A resource can be any number of different data objects, such as a data object that can be identified by a uniform resource indicator (URI) or a uniform resource locator (URL). English). Uniform resource locators are described in more detail in Internet Engineering Task Force Request For Comment 1738, Uniform Resource Locators (URL), BernersLee et al., December 1994. Uniform resource indicators are described in more detail in IETF RFC 2396.

[0041] For example, a service can be in an online magazine. The magazine can include a variety of different resources, such as multiple articles. Each article can also include audio files, video files or other content. Articles can be stored online, for example, as Hypertext Markup Language (HTML) pages. Of course, another binding language, such as Extensible HTLM (XHTML), Website Meta Language (WML) can also be used. Other resources can be stored using different formats, such as joint photography expert group (JPEG), moving image expert group (MPEG), MP3, or any number of others. formats available. Resources can be formatted on a page, such as a web page, which can provide a collection of resources that constitutes a single, consistent space for interaction and viewing. The page can itself be a resource, and a service can include more than one page.

[0042] A service, such as the online magazine, can be accessed from, and sometimes stored by, a service provider 204. The service provider 204 can be connected to the broadcast server 50 via the Internet 60, such as shown in Figure 5. Alternatively, service provider 204 can connect to an intranet job or other network that also connects to broadcast server 50. Multiple service providers 202, 204, 206, 208 may interact with broadcast server 50 over one or more networks. Additionally, each service provider 202, 204, 206, 208 can memorize more than one service.

[0043] A carousel manager 210 preferably operates on broadcast server 50. Carousel manager 210 is

ES 2 379 347 T3 deals with generating and transmitting carousels, which are formed from services available by service providers 202, 204, 206, 208. While carousel manager 210 can handle services created using a variety of different formats In a preferred embodiment, the carousel manager 210 takes care of generating and transmitting services created in HTLM.

[0044] Figure 5 illustrates a more detailed description of the carousel manager 210, which can be used to build a broadcast carousel. The carousel manager 210 interacts with a service provider 204 via the Internet 60, although this can be done via another type of network or another type of connection. A loader 250 in the carousel manager 210 interacts with the service provider 204, and the service provider receives a service from a service provider. For example, it can receive the HTTP service from the service provider 204. The service can be, for example, the online magazine created using HTLM. Of course, the loader 250 can get other services without HTTP. For example, loader 250 can obtain resources identified by a URI or URL, or it can obtain resources through applications such as file transfer protocol (FTP). The carousel manager 210 can then form the service into a broadcast carousel using a broadcast standard. The broadcast carousel can then be transmitted to interactive television receiver 54.

[0045] Figure 6 is a flow chart of an exemplary process that can be used to build a broadcast carousel. In step 350, the carousel manager can obtain a service from a service provider. Then, in step 352, the carousel manager can obtain a broadcast policy from the service provider. The carousel manager can then create a broadcast carousel using the broadcast policy obtained from the service provider, shown in step 354. The carousel can then be broadcast to the interactive television receiver, shown in step 356.

[0046] With continued reference to Figure 5, loader 250 may also determine a broadcast policy for the service. Broadcast policy generally defines what resources will be broadcast to interactive television receiver 54 on the broadcast path and what resources will only be available to interactive television receiver 54 on point-to-point path 58. Several different factors can be considered in broadcast policy development, and broadcast policy can be formed in a variety of different ways.

[0047] Broadcast path 52 generally supports wide bandwidth, and therefore may be able to support sending large amounts of data; however, interactive television receiver 54 may have limited memory. To accommodate the limited storage of interactive television receiver 54, data is continuously sent to interactive television receiver 54 on the carousel. To obtain data that is not normally in memory, interactive television receiver 54 may wait for the carousel to cycle through the module that holds the data. By placing large amounts of data on the carousel to be sent to the interactive television receiver 54, the interactive television receiver 54 may have to wait longer for the carousel to cycle through the modules to receive a module that is not normally present. in his memory. Therefore, it may be desirable to limit the amount of data placed on the carousel and sent to interactive television receiver 54 via broadcast path 52.

[0048] The HTTP loader 250 uses broadcast policy in a variety of different ways. In an exemplary embodiment, service provider 204 may send loader 250 a broadcast policy to be used to form the carousel. For example, the service provider 204 may send the loader 250 a channel definition file, which can be used as the broadcast policy. As is known in the art, a channel definition file can be a specific format for identifying a collection of resources. The channel definition file can be created by the service provider 204, and can be associated with the service. To form the channel definition file, the service provider 204 may indicate resources that are most likely to be accessed by the interactive television receiver 54. These resources, as defined by the channel definition file, can be placed on the carousel and sent to interactive television receiver 54 via broadcast path 52. Less accessed resources, however, can be reserved for the point-to-point route 58. The channel definition file is illustrative in nature only, and other formats may be used to specify broadcast policy.

[0049] Returning to the online magazine example, the service provider 204 may specify a channel definition file that identifies particular resources to place on the carousel. These may be, for example, the online magazine index, cover headline, feature articles, or other popular resources. Less viewed resources can be reserved for point-to-point route 58. By shaping the carousel to include commonly accessed resources, the service provider 204 can limit the size of the broadcast carousel. This can increase the speed with which the interactive television receiver 154 can access the carousel resources. Additionally, a smaller carousel can reduce stress on the interactive television system that can be caused by continuously sending large amounts of data.

In another exemplary embodiment of broadcast policy use, the carousel manager 210 may store a broadcast policy file 254. The broadcast policy file 254 can be used in conjunction with the broadcast policy provided by the service provider 204 to create the carousel. Loader 250 may use broadcast policy file 254 and the service provider's broadcast policy in a variety of ways.

ES 2 379 347 T3

[0051] In one example, the broadcast policy of the service provider may specify a list of resources to be placed on the carousel. The broadcast policy file 254, however, can set a maximum limit for the size of the carousel. The size defined by broadcast policy file 254 can be a maximum number of resources, a maximum number of physical bits used for resources, or some other measure. If the service provider's broadcast policy specifications do not exceed the maximum limit set by broadcast policy file 254, then loader 250 can simply use the service provider's broadcast policy to create the carousel. However, if the service provider's broadcast policy specifies an amount of resources that exceeds the size limit set by the loader broadcast policy file 254, then the loader 250 may further limit the resources placed on the carousel. This can be done using many different methods.

[0052] In one example, the broadcast policy of the service provider may further define a priority of the resources. Loader 250 can then use this priority to determine which resources to place on the carousel. In another example, loader 250 may define a priority for resource types. For example, HTLM pages can be given a higher priority than JPEG files. Therefore, to enforce the maximum carousel size limit, uploader 250 can remove JPEG files from resources defined by the broadcast policy of the service provider. In another example, the loader 250 can arbitrarily delete content until the maximum size limits are reached. There are also other ways to enforce the maximum size limit, and these can also be used.

[0053] Broadcast policy file 254 may specify limitations or restrictions other than a maximum size. For example, the loader broadcast policy file 254 may restrict certain types of resources, such as files. For example, you could specify that no MPEG files should be placed on the carousel, or you could place similar restrictions on other types of files. Additionally, the broadcast policy file 254 may place restrictions on the size or quantities of certain types of files. Other limitations can also be used.

[0054] In another type of priority, the broadcast policy may specify cycle rates for resources on the carousel. For example, the broadcast policy may specify that certain modules should be cycled on the carousel more frequently than other resources. This can allow these modules to be accessed more quickly. Since modules would be cycled on the carousel more frequently than others, an interactive television receiver would have to wait a shorter amount of time before the carousel would cycle to the module. Therefore, the waiting time to obtain the module can be reduced.

These examples are not intended to be exhaustive. Many other factors can be considered when creating a broadcast policy. Additionally, there are many other ways for the service provider's broadcast policy and broadcast policy file 254 to interact, and these can also be used.

[0056] In addition to using a broadcast policy, loader 250 can also perform content negotiation. A resource can have multiple representations. Carousel builder 252 may perform content negotiation with service provider 204 and interactive television receiver 54 to determine an appropriate resource representation to use in building the carousel. For example, the service provider can specify an HTLM page, and this HTLM page can have multiple representations corresponding to different versions of HTLM that were used to create the page. In another example, a video or audio resource may be available in different formats. Of course, many other representations exist for resources and these can also be used to perform content negotiation.

[0057] An interactive television receiver 54 may not be able to support any of the multiple displays. Alternatively, interactive television receiver 54 may be capable of supporting one or more of the multiple displays. For example, a resource can be an image file. The image file can be stored in multiple representations, such as JPEG and bitmap. The interactive television receiver 54, however, can only support bitmap images. Therefore, the interactive television receiver 54 may not be able to properly display the JPEG representation of the image. By performing content negotiation between interactive television receiver 54 and service provider 204, carousel builder 252 can select an appropriate representation for a resource when multiple representations are available. For example, the carousel manager 210 can determine that the resource is available in both JPEG and bitmap representations. Additionally, carousel manager 210 may determine that the requesting application program supports only bitmap images. The carousel manager 210 can then obtain the bitmap representation from the service provider 204 to use in the carousel.

[0058] A method for performing content negotiation is specified in the HTTP 1.1 standard. HTTP 1.1 is described in more detail in Internet Engineering Task Force Request For Comment 2616, Hypertext Transfer Protocol HTTP / 1.1, Fielding et al., June 1999, which is incorporated herein by reference in its entirety. Of course, other methods can also be used to negotiate the content.

Once the carousel builder 252 obtains the resources to be placed on the carousel, for example by receiving them from the loader 250, the carousel builder 252 can then build the carousel. This can

ES 2 379 347 T3 performed using an appropriately supported carousel format. For example, each resource can be put into a transport module and inserted into the carousel by the carousel constructor 252. For an HTTP resource, for example, the module can preferably include the body of HTTP resources and headers of HTTP resources. The carousel can be distributed through multiple routes. As is known in the art, a pathway can be an elemental diffusion stream.

In addition to building the carousel, the carousel builder 252 can also build a carousel directory 256. The carousel directory 256 can be sent to the interactive television receiver 54 as a part of the carousel, and this can specify the available resources in the different modules of the carousel. The carousel directory 256 can specify the resources available on the carousel using a variety of different methods. In an exemplary embodiment, the carousel directory 256 may specify resources using a carousel addressing scheme. Thus, the carousel directory 256 may provide a map between a carousel module address of the resource and the physical address of the resource. Other ways can also be used to identify resources on the carousel and to identify the module that carries a particular resource.

The carousel constructor 252 can also construct a URI index 258. The URI index 258 can be, for example, a data structure that supports information about resources in the carousel. The URI index 258 may include a map between a resource carousel address and that of the resource URI or other unique identifier. For example, URI index 258 can provide a map between a URI that identified the resource and its location on the carousel. In another example, a resource can be identified using a URL, and the URI 258 can provide a map between the URL and the carousel of the resource. URI index 258 can be used to provide a map between a URI or URL resource and the carousel address of the resource. The carousel directory 256 can then be used to further resolve the carousel address to the physical address of the resource on the carousel.

[0062] Of course, the URI 258 could also provide a more direct map. For example, URI index 258 could provide a map between a resource URI and the physical address of the resource on the carousel. Similarly, the URI 258 could provide a map between a URL of the resource, or other identifier, and the physical address of the resource in the carousel. Using this direct map, a resource identified by a URI, URL, or other identifier could be directly resolved to a physical address using the URI index 258. This can eliminate the middle step of using the 256 carousel directory to resolve a module address in a physical address.

The carousel provides a set of resources to the interactive television receiver 54. The resources in the carousel may be periodically updated according to the broadcast policy for the carousel. Resources can be added to and removed from the carousel, and resources can be updated to provide interactive television receiver 54 with a more current version of the resource. Changes in carousel resources can also trigger a corresponding change in carousel 256 directory and URI 258 index. Carousel 256 directory and URI 258 index can be updated to reflect the changed composition of the carousel.

While it is possible to update the carousel directory 256 and the URI index 258 to reflect changes to the carousel, an additional URI index or additional carousel directory can also be used. The additional URI index can reflect only changes to the URI 258 index. Similarly, the carousel directory can additionally reflect only the changes to the carousel 256 directory. These smaller updates can then be used in conjunction with the carousel 256 directory and the 258 URI index to reflect the current carousel composition.

[0065] In an example of updating the resources in the carousel, a resource can be updated or removed from the carousel when the resource expires. HTTP carousel manager 210 generally broadcasts resources that have been allocated for broadcast by service provider 204 or loader 250. Loader 250 may also ensure that the carousel uses the most current resources. The service provider 204 may specify expiration information for the resources. This can be done through broadcast policy, such as by making an entry for a particular resource, or expiration information can be specified on a resource itself. For example, an HTLM page can specify expiration information.

[0066] In an exemplary embodiment, loader 250 may use the Expiration Model Specified by HTTP Server 1.1 to prevent resources in the carousel from becoming stale. Loader 250 may also use another model to determine resource expiration times. If the loader 250 determines that a resource is stale, it removes it from the carousel.

[0067] For example, an application running on interactive television receiver 54 may obtain a resource from the carousel, but the application may want to determine if it has the most current version of the resource. The application can use the carousel 256 directory to compute an age calculation header. The carousel directory 256 can be used to provide a trigger mechanism to provide real-time update information on the resources supported by the carousel, thereby determining if the application has the current version of the resource supported by the carousel.

[0068] In addition to providing an interactive television receiver application with the most current version of the resources, resource expirations can be used to keep the resources on the carousel. When a

ES 2 379 347 T3 resource expires, loader 250 can get a more current version of the resource from service provider 204. Loader 250 can provide the updated resource to carousel builder 252, which then replaces the outdated version of the resource in the carousel with the updated version. Then, as the carousel is transmitted, the interactive television receiver 54 receives the updated resource. In an alternative embodiment, the updated resource is not placed on the carousel. The interactive television receiver 54 can only get the updated resource of the point-to-point route 58.

[0069] If a more current version of the resource is not available, then the loader 250 may instruct the carousel constructor 252 to remove the resource from the carousel. The carousel constructor 252 may then therefore update the URI index 258. The resource may then no longer be available on the broadcast path 52.

Interface module

[0070] Figure 7 shows a block diagram illustrating an interface module 300 that can be used in interactive television receiver 54. The interface module can run in interactive television receiver 54, and this can serve as a interface to an application program 302 for requesting data from the interactive television system. Interface module 300 may receive a resource request from application program 302. Interface module 300 can then decide whether to get the resource from broadcast path 52 or point-to-point path 58. If the request is not already in a supported format, interface module 300 can translate the request from the broadcast program. 302 application in a format supported by the path used to get the resource.

The application program 302 may run on the interactive television receiver 54. The interactive television receiver 54 may run an interface module. The interface module may provide the application program 302 with the necessary application program interfaces (APIs) to allow the application program 302 to load a resource from the carousel or from the point-to-point path 58. As is known in the art, an APl can be a set of functions used by a program to communicate with another program, with the operating system, or with other services.

The application program 302 could obtain data directly from the carousel by sending an appropriate data request from the carousel. In response, the application program 302 could receive the requested data, which was sent on the carousel via the broadcast path 52. Alternatively, the application program 302 could obtain data by sending a request through the point-to-point path. point 58 to a service provider 64. Then, the service provider 64 may cause the data to be sent to the interactive television receiver 54 along the point-to-point route 58. However, the format for requesting data from the broadcast route 52 may differ from the format for request data from the point-to-point route 58.

[0073] Interface module 300 may run on interactive television receiver 54 and serve as an interface between application program 302 and the two data paths 52, 58. Interface module 300 may receive a request for data from the application program 302 running on interactive television receiver 54. The request for data to interface module 300 may be in a constant format that can be used to request a resource from broadcast path 52 or point-to-point path 58. Interface module 300 may process the request for program data Application 302 to determine whether to obtain the data from the broadcast path 52 or from the point-to-point path 58. Then, if necessary, interface module 300 can reformat the data request to the syntax required for broadcast path 52 or point-to-point path 58.

[0074] Figure 8 is a flow chart of an exemplary process that can be used to obtain a resource. In step 400, the interface module may receive a request for a resource from an application program. Then, in step 402, the interface module may receive a broadcast carousel, which includes an index module. The interface module can then search the index module to determine if the resource is available on the broadcast carousel, shown in step 404. If the resource is available on the broadcast carousel, it can be provided to the application program. If, however, the resource is not available on the broadcast carousel, then it can be obtained from the point-to-point route, shown in step 406.

[0075] Figure 9 is a flow chart of another exemplary process that can be used to obtain a resource. In step 450, the interface module may receive a request for a resource from an application program. In step 452, the interface module can look up an index to determine if the resource is available on the carousel. The index module can be transmitted to the interface module on the carousel. Then, in step 454, the interface module determines that the resource is not available on the carousel. In step 456, the interface module requests the resource from the point-to-point route. Then, in step 458, the interface module receives the resource from the point-to-point route. Finally, the interface module provides the resource to the requesting application program, shown in step 460.

[0076] With continued reference to Figure 7, interface module 300 receives a resource request from application program 302. The resource request may identify the resource by its URI or by another identifier. The request to interface module 300 can be in a standard format, regardless of the source of the resource. In one embodiment, the data request is formatted using the syntax to get the resource from broadcast path 52. In another embodiment, the data request is formatted using the syntax to get the resource from the point-to-point route 58. In another embodiment, the data request is formatted using another format.

ES 2 379 347 T3 understood by interface module 300.

[0077] Interface module 300 receives the request for data and determines which resource has been requested. The interface module 300 can then use the URI index 258 to determine if that resource is available through the broadcast path 52. For example, the interface module 300 can look up the URI index 258 based on the URI of the requested resource. . If the resource is available on broadcast path 52, the URI 258 can provide a map between the URI of the resource and its carousel address or physical location. Then, using the map, the interface module 300 can obtain the resource from the carousel and provide it to the application program 302.

If, however, the URI index 258 does not memorize a map between the URI and a carousel address, then the interface module 300 may determine that the resource is not available on the broadcast path 52. The module then interface 300 can request the resource from the point-to-point route 58. When requesting the resource from the point-to-point route 58, the interface module 300 can use the protocol to request resource from this route. And, this protocol may differ from the protocol used to request resources from broadcast path 52. Thus, once interface module 300 determines which path to use to request the resource, interface module 300 can use the appropriate protocol for this. route.

[0079] Interface module 300 may provide a seamless way to obtain resources from broadcast path 52 or point-to-point path 58. Application program 302 may request a resource using constant syntax, regardless of the source of the resource. . Using the single syntax to request resources can provide different benefits. In an example of a benefit, the use of the single syntax can eliminate the need for an application programmer to determine where a resource will be available. Since the application programmer uses a constant syntax to request resources, the application programmer should not differentiate in code between the possible sources of the resource. At the time of coding the application, it is not necessary to know if the resource will be available through the broadcast path 52 or through the point-to-point path 58. When the application is executed, the interface module 300 receives the request for resource. If the resource is available on broadcast path 52, interface module 300 retrieves the resource from the carousel.

However, if the resource is not available on the broadcast path 52, the interface module 300 can obtain the resource via the point-to-point path 58 using a protocol to obtain resources via the point-to-point path. point 58. Using interface module 300 to allow a requested resource to be obtained from broadcast path 52 or from point-to-point path 58 can reduce scheduling errors, which would occur when requesting a resource only from a location where it is not present. available. The interface module 300 may also necessarily reduce the use of the point-to-point route 58 (p. e.g., where the application developer is unsure if the resource will be available on broadcast path 52 and chooses to get the resource from point-to-point path 58) to obtain resources that would otherwise be available on broadcast path plus quick 52.

[0081] In another example of a benefit, the interface module 300 may also allow the carousel to be continuously updated without adversely affecting the application program 302. For example, an expired resource can be removed from the carousel. Without interface module 300, removing a resource from the carousel can cause a programming error, because the resource requested by application program 302 would no longer be available on broadcast path 52. The interface module 300, however, can take care of converting the request from broadcast syntax to peer-to-peer syntax. The request for the removed resource is sent via the point-to-point route 58 and the current version of the resource is obtained from the point-to-point route 58. This provides the application program 302 with the current version of the resource instead of the version expired that was previously in the carousel.

[0082] Interface module 300 may also monitor URI 258 to detect changes to the carousel, such as when resources are added to or removed from the carousel. In addition to controlling the URI index 258, the interface module 300 could also control the supplementary URI index 258. Supplemental URI index 258 can reflect carousel changes made after the original URI index 258 was created, and this can provide interface module 300 with a simple and efficient method of detecting carousel changes. Similarly, interface module 300 could detect carousel changes by monitoring carousel directory 256. Changes to the carousel could also be quickly and efficiently detected using the supplemental carousel directory.

[0083] In addition to handling resource requests, interface module 300 can also support resource preloading. In one type of preload, the application program 302 can access a resource, such as an HTLM page. The HTLM page can comprise a variety of other sub-resources. While the application program 302 can usually access a part of the subresources, the interface module 300 can preload the rest of the subresources that make up the HTLM page. Then, if the application program 302 later tries to access other subresources, the subresources are readily available without having to be requested from one of the transport routes.

[0084] In another type of preload, the HTLM page can include links to various other resources. The interface module 300 can preload the linked resources, thus obtaining the linked resources before they are requested by the application program 302. Once retrieved, the resources can be stored in the memory of the interactive television receiver. Then, if application program 302 asks for one of the resources in memory, it can be

ES 2 379 347 T3 retrieve from memory and provide to application program 302. The resource can be provided to application program 302 without having to spend the time to retrieve the resource from one of the transmission paths.

[0085] In an exemplary embodiment, interface module 300 only preloads linked resources that are available through broadcast path 52. Since the broadcast server 50 is periodically cycled through the carousel to send the resources to the interactive television receiver 54, and since no additional bandwidth would be used on the broadcast path 52 to obtain the resources, the interface module 300 can get those resources without slowing down the data rate on broadcast path 52. This can also be done with only a minimal amount of extra processing by the interactive television receiver 54. If the application program 302 subsequently requests the resources via a link on the HTLM page, the interface module 300 can quickly provide preloaded resources without having to wait for the carousel to cycle through the requested resources.

[0086] If the application program 302 does not request the preloaded resources, then they can be removed from memory. For example, if application program 302 navigates to a new HTLM page, interface module 300 can remove the preloaded resources from the old page. The interface module 300 can then preload resources for the new HTLM page, and the newly preloaded resources can overwrite the preloaded resources for the old page. Other processes can also be used to remove unused preloaded resources.

[0087] In another exemplary embodiment, interface module 300 may preload resources that are only available through point-to-point path 58. Resources may be requested by interface module 300, which then receives them over the point-to-point route 58. Resources can be stored by interface module 300 in interactive television receiver 54 and retrieved quickly if the application requests the resource via a link on the current HTLM page. As the resources would not commonly be sent over the point-to-point route 58, extra bandwidth is consumed to get the resources over the point-to-point route 58. This can slow down the total data transmission rate on the point-to-point route 58 and adversely affect other applications that use that route. In another embodiment, the interface module may preload resources that are available on the broadcast path 52 and the point-to-point path 58. Other variations are possible, and these can also be used.

[0088] It should be understood that the programs, processes, methods and apparatus described herein are not related to or limited to any particular type of computer or network apparatus (hardware or software), unless otherwise stated. Various types of multi-purpose or specialized computer can be used with or performed operations according to the instructions described here. While various elements of the preferred embodiments have been described as being implemented in software, in other embodiments they may be used in hardware or firmware implementations alternatively, and vice versa.

[0089] In view of the wide variety of embodiments to which the principles of the present invention can be applied, it should be understood that the illustrated embodiments are exemplary only, and should not be construed as limiting the scope of the present invention. .

[0090] For example, the steps in the flowcharts can be taken in sequences other than those described, and plus, minus, or other items can be used in the block diagrams.