Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
  • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
  • H04N21/4348—Demultiplexing of additional data and video streams
  • H04N21/4349—Demultiplexing of additional data and video streams by extracting from data carousels, e.g. extraction of software modules from a DVB carousel
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
  • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
  • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
  • H04N21/26266—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for determining content or additional data repetition rate, e.g. of a file in a DVB carousel according to its importance
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
  • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
  • H04N21/2665—Gathering content from different sources, e.g. Internet and satellite
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/47—End-user applications
  • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
  • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
  • H04N21/64—Addressing
  • H04N21/6405—Multicasting
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/81—Monomedia components thereof
  • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/81—Monomedia components thereof
  • H04N21/8146—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/81—Monomedia components thereof
  • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/81—Monomedia components thereof
  • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N7/00—Television systems
  • H04N7/16—Analogue secrecy systems; Analogue subscription systems
  • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
  • H04N7/17309—Transmission or handling of upstream communications
  • H04N7/17318—Direct or substantially direct transmission and handling of requests

Definitions

• An embodiment of the present invention relates generally to the field of electronic communications, and, more specifically, to the pushing of content in a two-way interactive television network.
• Interactive television systems operate to enhance the experience of a content consumer in a number of ways. Content producers and/or distributors are able to provide enhanced services and features to a consumer.
• interactive television systems may be capable of executing interactive television (iTV) applications that supplement and enhance the viewing experience of a user.
• iTV interactive television
• a wide range of interactive television applications may be provided to a user via an interactive television system, ranging from interactive program guides (IPGs) to games and the like.
• Interactive television applications may also be attractive to a content consumer because, such applications elevate a television viewing experience from a purely passive activity to an active, or interactive, activity.
• a shopping interactive television application may enable a user to interactively place orders for products being advertised via a television broadcast.
• An interactive television application is typically delivered from a headend of a broadcast service provider to a set-top box (STB) of a consumer as part of a broadcast transmission.
• a broadcast may include a television content portion (e.g., audio and video) and an interactive portion.
• the interactive portion may include application code and control information for an interactive television application.
• the service provider typically combines the television content and interactive portions of the broadcast into a single signal that is broadcast to a user location.
• a user device receives the broadcast, extracts the interactive portion thereof, and composes and executes one or more interactive television applications that are embodied in the interactive portion of the broadcast.
• STB set-top box
• the user device in addition to extracting and executing the interactive television application, may also be provided with a transmission capability whereby the user device can communicate from the user location back to a broadcast service provider or to other users, for example via a public network (e.g., the Internet) or a private network (e.g. a Pay TV operator intranet).
• a public network e.g., the Internet
• a private network e.g. a Pay TV operator intranet
• the broadcast service provider may then transmit the application to the individual user location. If the application is sent on a shared medium (e.g. the broadcast network), other user devices connected to the same network will ignore the requested application. Therefore, each of the other user devices must individually make a request for the application and the broadcast service provider must reply to each of these redundant requests individually.
• the network may include in effect two networks using different frequencies on the same physical link.
• One may be a broadcast network and the other may be a bi-directional network that can be used both in a point-to-point and in a broadcast mode.
• point-to-point and broadcast protocols can coexist as well.
• an apparatus and method to enable multicasting a reply, to a request for a module, to a plurality of receivers on an interactive television network requests from multiple modules may be packaged into a single request to be transmitted to a broadcast service provider.
• a request is multicast to a plurality of servers (at least the one that will serve the request) and receivers on the interactive television network and the response to the request is multicast to the plurality of servers and receivers.
• a user device may determine whether to request a module by accessing a list of modules to be multicast by the broadcast service provider within a specific time period. According to another aspect of the invention, a user device may determine whether to perform an action upon accessing a directory listing modules present in a carousel of a broadcast service provider.
• Figure IA is a diagrammatic representation of an exemplary interactive television environment within which the present invention may be deployed;
• Figure IB is a diagrammatic representation of the interactive television environment illustrating exemplary details of the source system and the receiver system;
• Figure 2 is a block diagram providing architectural details regarding a headend system and a set-top box, according to an exemplary embodiment of the present invention;
• Figure 3 is a diagrammatic representation of a data stream that may be outputted from a multiplexer of a headend system, according to one embodiment of the present invention
• Figure 4 is a flowchart illustrating a method, according to one exemplary embodiment of the present invention, to multicast a reply to a request from a module to a plurality of receiver systems in an interactive television environment;
• Figure 5 is a flowchart illustrating a method, according to one exemplary embodiment of the present invention, to package requests for multiple modules into a single request transmitted on an interactive television environment;
• Figure 6 is a flowchart illustrating a method, according to one exemplary embodiment of the present invention, to multicast a reply to a multicast request for a module in an interactive television environment
• Figure 7 is a flowchart illustrating a method, according to one exemplary embodiment of the present invention, to multicast a list of modules that are to be multicast from a source system in an interactive television environment;
• Figure 8 is a flowchart illustrating a method, according to an exemplary embodiment of the present invention, to multicast a directory of modules that will or will not be transmitted to in the future from a source system in an interactive television environment;
• Figure 9 is a block diagram illustrating a machine, in the exemplary form of a computer system, which may store and execute a set of instructions that cause the machine to perform any of the methods described herein.
• FIG. IA is a diagrammatic representation of an exemplary interactive television environment 10, in conjunction with which the present invention may be deployed.
• the interactive television environment 10 includes a source system 12 that communicates data (e.g., television content and interactive application data) via a distribution system 14 to a number of receiver systems 15, 16, and 17.
• data e.g., television content and interactive application data
• the distribution system 14 may any communication system capable of communicating data and may, for example, include a national or local Telco network or the like.
• Figure IB is a diagrammatic representation of the interactive television environment 10 illustrating exemplary details of the source system 12 and the receiver system 16.
• a headend system 18 operates to communicate the data as a broadcast transmission.
• the headend system 18 is shown to include one or more broadcast servers 20 and one or more application servers 22.
• Each of the broadcast servers 20 may operate to receive, encode, packetize, multiplex, and broadcast data from various sources and of various types. In various embodiments, data could also be transmitted from the source system 12 via a network connection to the receiver system 16. Further details regarding an exemplary broadcast server 20 are provided below with reference to Figure 2.
• Each application server 22, in one exemplary embodiment, serves to compile and provide modules to the broadcast server 20.
• the modules may include application code, data (e.g., updated statistics and scores for sporting events, news feeds, etc.), or any other data (e.g., motion picture experts group (MPEG) still pictures, etc.) utilized by an interactive television application.
• the modules of the present invention may be portable across all transmission media and, accordingly, may contain no specialization for any particular communication channel.
• a module may be signed, unsigned, compressed or uncompressed.
• An application server 22 may include multiplexing functionality to enable multiplexing of, for example, interactive television applications and associated data with audio and video signals received from various sources.
• An application server 22 may also have the capability to feed (e.g., stream) multiple interactive television applications to one or more broadcast servers 20 for distribution to the receiver system 16.
• each application server 22 may implement a so-called "carousel", whereby code and data modules are provided to a broadcast server 20 in a cyclic, repetitive manner for inclusion within a transmission from the headend system 18.
• the headend system 18 is also shown to include one or more backend servers 24, which are coupled to the application servers 22 and to a communications FO interface such as an exemplary modem pool 26.
• the modem pool 26 is coupled to receive data from the receiver systems 16 via a network 28 (e.g., the Internet) and to provide this data to backend servers 24.
• the backend servers 24 may then provide the data, received from the receiver system 16, to the application servers 22 and the broadcast servers 20.
• a network 28 and the modem pool 26 may operate as a return channel whereby a receiver system 16 is provided with interactivity with the source system 12.
• Data provided to the headend system 18 via the return channel may include, merely for example, user input to an interactive television application executed at the receiver system 16 or data that is generated by the receiver system 16 and communicated to the source system 12.
• the network 28 may also provide a channel whereby programs and applications are requested from the source system 12 to be provided to the receiver system 16 as will be further described below in conjunction with Figures 4-8.
• the headend system 18 is also shown optionally to receive data (e.g., content, code and application data) from external sources.
• Figure IB illustrates the headend system 18 as being coupled to one or more content sources 32 and one or more application sources 34 via a network 36 (e.g., the Internet).
• a content source 32 could be a provider of entertainment content (e.g., movies), or a provider of real-time dynamic data (e.g., weather information).
• An application source 34 may be a provider of any interactive television application.
• one or more application sources 34 may provide Electronic Program Guides (EPG) and navigation applications, messaging and communication applications, information applications, sports applications, and/or games and gaming applications.
• EPG Electronic Program Guides
• the distribution system 14 may, in one embodiment, support the broadcast distribution of data from the source system 12 to the receiver system 16.
• the distribution system 14 may include a satellite, cable, terrestrial or Digital Subscribers Line (DSL) network, or any combination of such networks or other networks well known to those of ordinary skill in the art.
• DSL Digital Subscribers Line
• the receiver system 16 is shown, in one exemplary embodiment, to include a set-top box (STB) 38 that receives data via the distribution system 14, a communications I/O interface such as an exemplary modem 40 for return channel communications with the headend system 18 and optionally other external systems, a user input device 43 (e.g., a keyboard, remote control, mouse etc.) and a display device 42, coupled to the set-top box 38, for the display of content received at the set-top box 38.
• the display device 42 may be a television set.
• the communications I/O interfaces may be selected dependent upon the nature of the network 28.
• the communications I/O interface 28 may include a cable return module, a DSL return module, or the like.
• the set-top box 38 may execute three layers of software, namely an operating system 44, middleware 46 and one or more interactive television applications 48.
• the middleware 46 operates to shield the interactive television application 48 from the differences of various operating systems 44 and in hardware of different set-top boxes 38.
• the middleware 46 may provide driver Application Program Interfaces (APIs) and a library to translate instructions received from an interactive television application 48 into low-level commands that may be understood by set-top box hardware (e.g., modems, interface ports, smart card readers, etc.).
• APIs Application Program Interfaces
• set-top box hardware e.g., modems, interface ports, smart card readers, etc.
• Figure 2 is a block diagram illustrating further details regarding the architecture of a headend system 18 and a set-top box 38, as may be deployed as part of an exemplary embodiment of the present invention.
• a broadcast server 20 which may support a carousel of modules, as including a number of parallel paths that provide input to a multiplexer 50, each of the parallel paths including an encoder 52 and a packetizer 54.
• Each encoder 52 may operate to receive input from one or more sources.
• the encoder 52a is shown to receive streamed code modules from an application server 22, which is in turn coupled to receive application data from one or more application sources 34.
• the application source 34 maybe internal or external to a headend system 18.
• an encoder 52b is shown coupled to receive content data from one or more content sources 32, which may again be internal or external to the headend system 18.
• each broadcast server 20 may include any number of parallel paths coupled to any number of sources (e.g., application and/or content sources 34 and 32) that provide input to the multiplexer 50.
• a headend system 18 may deploy any number of broadcast servers 20.
• Each of the encoders 52 operates to encode data utilizing any one or more of a number of compression algorithms, such as, for example, the Motion Picture Expert Group (MPEG) comparison algorithms.
• MPEG Motion Picture Expert Group
• Each of the encoders 52 may also operate to time stamp data that needs to be encoded. Time stamps may also be adjusted downstream by multiplexers. Certain data types may not be susceptible to encoding and thus, may pass through, or by-pass, the encoder 52, and be provided to a packetizer 54 in an unencoded state. In one embodiment, code and most data types may bypass the encoders 52.
• the packetizers 54 are coupled to receive data and to format this data into packets before eventual transmission via the distribution system 14 (e.g., a broadcast channel).
• the distribution system 14 e.g., a broadcast channel
• Each of the packetizers 54 provides packets to the multiplexer 50, which multiplexes the packets into a transmission signal for distribution via the distribution system 14.
• the set-top box 38 of a receiver system 16 is typically coupled to a network input (e.g., a modem), cable input, satellite dish or antenna so as to receive the transmission signal, transmitted from the headend system 18 via the distribution system 14.
• the transmission signal is then fed to an input 56 (e.g., a receiver, port, etc.).
• the input 56 may, for example, include a tuner (not shown) that operates to select a broadcast channel on which the transmitted signal is broadcast. It will be appreciated that in a DSL environment no tuner may be provided.
• the packetized transmission signal is then fed from the input 56 to a demultiplexer 58 that demultiplexes the application and content data that constitutes the transmission signal.
• the demultiplexer 58 provides the content data to an audio and video decoder 60, and the application data to a computer system 64.
• the audio and video decoder 60 decodes the content data into, for example, a television signal.
• the audio and video decoder 60 may decode the received content data into a suitable television signal such as a National Television Systems Committee (NTSC), Phase Alternation Line (PAL), or High Definition Television (HDTV) signal.
• NTSC National Television Systems Committee
• PAL Phase Alternation Line
• HDMI High Definition Television
• the computer system 64 which may include a processor and memory, reconstructs one or more interactive television applications from the application data that is provided to it by the demultiplexer 58.
• the application data may include both application code and/or application information that is used by an interactive television application 48.
• the computer system 64 in addition to reconstructing an interactive television application 48, executes such an application 48 to cause the set-top box 38 to perform one or more operations.
• the computer system 64 may output a signal to the display device 42.
• this signal from the computer system 64 may constitute an image or graphical user interface (GUI) to be overlaid on an image produced as a result of the signal provided to the display device 42 from the audio and video decoder 60.
• GUI graphical user interface
• a user input device 43 e.g., a keyboard, remote control, mouse, microphone, camera etc. is also shown to be coupled to the input 56, so as to enable a user to provide input to the set-top box 38.
• Such input may, for example, be alphanumeric, audio, video, or control (e.g., manipulation of objects presented in a user interface) input.
• the computer system 64 is also shown to be coupled to the audio and video decoder 60 so as to enable the computer system 64 to control this decoder 60.
• the computer system 64 may also receive an audio and/or video signal from the decoder 60 and combine this signal with generated signals so as to enable the computer system 64 to provide a combined signal to the display device 42.
• the computer system 64 is also shown to be coupled to an output 66 (e.g., a transmitter, output port, etc.) through which the set-top box 38 is able to provide output data, via the return channel 28, to an external system, such as for example, the headend system 18.
• the output 66 is shown to be coupled to the modem 40 of the receiver system 16.
• receiver system 16 is shown in Figures IA, IB and 2 to include a set-top box 38 coupled to a display device 42, it will readily be appreciated that the components of the receiver system 16 could be combined into a single device (e.g., a computer system), or could be distributed among a number of independent systems. For example, a separate receiver unit may provide input to a set-top box 38, which is then coupled to a display device 42.
• FIG. 3 is a diagrammatic representation of an exemplary data stream 68 that may, according to one exemplary embodiment, be outputted from each of a number of multiplexers 50 deployed in headend system 18.
• the application and content data may be presented to a broadcast server 20 as distinct modules.
• the application data may constitute directory modules 70, code modules 72 and data modules 74.
• the content information may be included within content modules 76.
• no distinction is made between code and data modules and data and code may thus be mixed.
• each of the modules 70-76 is uniquely identified as being of a particular module type.
• a directory module 70 may have a unique identifier so as to enable it to be identified within a data stream 68 without further information.
• a directory module 70 furthermore contains information constituting a directory of one or more other modules such as code modules 72 and data modules 74 that form a particular interactive television application. Accordingly, a set-top box 38 may utilize a directory module 70 to identify all code modules 72 and/or data modules 74 that are required for assembling and executing an interactive television application, hi one embodiment, the directory module 70 may be accessed and processed prior to the other modules, so as to enable the set-top box 38 to correctly identify and interpret other modules included within a data stream 68. In another embodiment, the directory module 70 is used to retrieve a list of modules as well as flags attached for each module, for example, to specify whether a module is auto-exec or auto-load module. As mentioned above, a headend system 18 may implement a carousel whereby the modules 70-76 are transmitted in a cyclic, repetitive manner.
• the receiver system 16 may transmit a request, via the network 28, for one or more modules to be transmitted by the source system 12.
• the receiver system 16 will multicast the requested module, as shown, by example, in a multicast response process flow 400 illustrated in Figure 4.
• Process flow 400 illustrates the separation of the processing on the receiver system 16 side and the source system 12 side by line 403.
• the receiver system 16 generates a request for a module from the source system 12.
• the receiver system 16 may request a module, as described with reference to Figure 3 above, which relates to an application associated with a television commercial. This code module may enable the user to receive additional information related to the product being advertised during the commercial.
• the source system 12 receives the request for the module from the receiver system 16.
• the source system 12 multicasts the request to a plurality of receivers (15, 16, 17), including the receiver system 16 that requested the module.
• the receiver systems 15 and 16 receive the requested modules. In this fashion, instead of redundantly receiving requests for and transmitting requested modules, the source system 12 can multicast modules once. Furthermore, multiple receiver systems (15, 16, 17) listening to the same multicast can acquire the same module. The receiver system 16 who requested the module will be ready to receive it, and the other receiver systems (15, 17) that desire the same module may acquire it as well.
• the other receiver systems may defer requesting a sought after module upon determining the sought after module is to be multicast within a specific time period, as illustrated below in conjunction with Figures 7 and 8.
• a receiver system may multicast a request for one or more modules to the other receivers systems on the network, whereby the other receiver systems may defer requesting a sought after module for a period of time. In this fashion, the other receiver systems may wait for the sought after module and do not send redundant requests for common modules.
• the receivers store a play list of the modules for a given application. For example, the playlist may be sent at the same time as the application. When receivers detect a module multicast on the network, they can deduce from the playlist which modules will play next.
• Timing information e.g. the time since the TV program or the application started, or a clock that is broadcast on the channel.
• the receivers can use the timing information combined with the playlist to know which modules will be transmitted next.
• multiple requests from a receiver system may be packed or grouped into a single communication.
• a single request (or packed request(s)) may include timing information that indicates when a request should be served.
• the timing information may indicate that a request should not be served earlier that an identified time, not later than an identified time, and so on.
• the source system 12 may serve each request in the plurality of requests sequentially or serve the plurality of requests all at once.
• the source system 12 extracts timing information from the request and serves the request based on the timing information.
• the timing information may indicate that the request should be served no earlier or no later than an identified time.
• the process flow 400 may reduce bandwidth utilization on the forward path because the requested module is acquired by multiple receiver systems (15, 16, 17) at the same time. Also, the bandwidth utilization may be reduced on the return path because the receiver systems (15, 16, 17) that receive a module requested by another receiver do not need to send a request for the same module. Further, receiver systems that have enough storage space can decide to pre ⁇ fetch and cache modules before they even need them.
• the process flow 400 may also reduce the load on the processor of the receiver system 16 by reducing the amount of data sent to a receiver that is not needed by that receiver. In addition, the process flow may reduce the amount of processing required on the server side, since the servers will have to process and serve fewer requests.
• an interactive television application may be divided into multiple application code modules or require specific data modules to operate. Therefore, a request for a specific module may commence additional requests for additional related modules.
• the receiver system 16 packages requests for multiple modules into a single request as shown, by example, in a package requests process flow 500 as illustrated in Figure 5.
• Process flow 500 illustrates the separation of the processing on the receiver system 16 side and the source system 12 side by line 503.
• the receiver system 16 determines the need for a module. For example, the receiver system 16 may need to request a code module from the source system 12 to perform a specific interactive function associated with a program being broadcasted.
• the receiver system 16 determines additional modules related to the requested module. Continuing the example, the receiver system 16 may identify one or more data modules that are associated with the requested code module. In one exemplary embodiment, the receiver system 16 stores an application specific list that maps related or additional modules or sequence of modules that may be required, hi one exemplary implementation the list is sent at the same time as the application (e.g. in a specific module). The list may be discarded from the receiver memory at the same time as other application code and data, for example when the application is terminated.
• the receiver system 16 generates a request for the sought after module and the related modules.
• the receiver system 16 transmits the request for the modules to the source system 12.
• the server system 12 receives the request for modules.
• the source system 12 multicasts the requested modules to a plurality of receivers (15, 16, 17) including the receiver system 16.
• the receiver systems 15 and 16 receive the requested module. It should be appreciated that process flow 500 reduces the number of sequence requests to the source system 12 on the return channel 28 and the number of responses to the sequence request to the receiver system 12 on the forward path via the distribution system 14. It may also reduce the size of the server farm required to process requests as the server farm will have fewer requests to process and serve.
• the receiver system 12 need not always determine the related modules as illustrated in block 520. Rather, in one embodiment, the source system 12 may decide to multicast one or more associated modules (e.g., a sequence of modules) when it receives a request for at least one module from at least one receiver. For example, if an application comprises a set of modules that are needed in sequence, the source system 12 can decide to multicast this sequence of modules. For example, the source system 12 can decide to multicast a sequence of modules starting at module n any time a request for module n is received.
• one or more associated modules e.g., a sequence of modules
• such a sequence of modules could be automatically generated off-line or in real-time by analyzing the carousel generated for a particular service.
• each module can be sent once or repeated.
• the optimization of traffic between a forward path bandwidth (repeating modules) and a return path bandwidth (sending requests) can be performed either off-line (e.g., producing play-lists of modules to send or analyzing carousels) or in real-time (e.g., analyzing traffic).
• This technique allows optimizing usage of forward and return path bandwidth based on criteria such as cost, saturation, and performance.
• An example of real-time optimizing techniques would be to broadcast the content that has been asked for; so that highest priority goes to explicit requests.
• the receiver system 16 may request and obtain one or modules from the other receiver systems (15, 17) on the network (e.g., a peer-to- peer network environment).
• Figure 6 illustrates one embodiment of a broadcast request process flow 600.
• Process flow 600 illustrates the separation of the processing on the side of the receiver system 16 and the side of the receiver system 17 by line 603.
• the receiver system 16 multicasts a request for a module to a plurality of receivers including the receiver system 17.
• the receiver system 17 receives the request for the module.
• the receiver system 17 may, for example, detect the requested module in its local cache. If so, at block 630, the receiver system 17 multicasts the requested module to the plurality of receiver systems (including the receiver systems 15 and 16).
• the receiver systems 15 and 16 receive the requested module.
• receivers in order to inhibit all receivers from responding to a request, receivers do not serve requests for modules that have been multicast by other receivers. As a consequence, all receivers may stop responding automatically when all modules have been served. In a combined peer to peer / client-server model, the server would apply the same strategy as the peers.
• FIG. 7 illustrates one embodiment of a module schedule for a multicast process flow 700 for transmitting a list of modules to be transmitted from the source system 12 within a specific time period.
• Process flow 700 illustrates the separation of the processing on the source system 12 and the receiver system 16 by line 703.
• the source system 12 generates a list of modules scheduled to be multicast to the plurality of receiver systems.
• the list of modules may include timing information about when specific modules will be transmitted.
• the list may be generated off-line or in real-time, for example by analyzing the carousel generated for a particular service.
• An example where the list can be generated off ⁇ line is when a TV program is a pre-recorded quiz game show.
• the application allows viewers to play along with the game show. Each question and answer pair may be transmitted in a separate module.
• the list may be generated by watching the show, writing down the time from the beginning of the show when a particular question is about to be answered.
• the receiver system 16 receives the list of modules from the source system 12.
• the receiver system 16 determines whether a sought-after module exists in the list. If the receiver system 16 determines the sought-after module is in the list of modules, control passes to block 740. If the receiver system 16 determines the sought-after module is not in the list of modules, control passes to block 750.
• the receiver system 16 determines that the sought-after module is in the list of modules and awaits the module to be multicast from the source system 12. The receiver system 16 may wait for the module to be multicast on a specific broadcast channel and/or at a specific time based on the information stored in the list.
• control may pass to block 750.
• the receiver system 16 generates and transmits a request.
• the source system 12 can multicast the list of modules it will multicast (optionally with timing information about when certain modules will be transmitted), so that other receiver systems, who need some of the modules to be transmitted, do not need to transmit requests for these modules.
• the process flow 700 reduces traffic on the network 28 and also reduces the size of the server farm required to process requests.
• the receiver system 16 may receive a directory that lists all the modules potentially present in a carousel.
• Figure 8 illustrates one embodiment of a send directory process flow 800.
• Process flow 800 illustrates the separation of the processing on the source system 12 and the receiver system 16 by line 803.
• the source system 12 generates a directory.
• the directory includes a list of modules that are currently present in the carousel, a list of modules that will be transmitted later by the carousel, or a list of modules that will not be transmitted within a specific time period.
• some carousel formats including OpenTV and DSM-CC (Digital Storage Media - Command and Control) transmit a directory that lists all the modules potentially present in the carousel.
• the source system 12 multicasts the directory to a plurality of receiver systems.
• the receiver system 16 receives the directory.
• the receiver system 16 accesses the directory to determine whether to perform a specific action. For example, in the case of an interactive advertisement over a 30 second spot, the receiver system 16 may decide not to launch an application or an application may decide to exit if a particular module has been missed, if, for example, the viewer turned to the commercial too late into the spot, hi one exemplary embodiment, lists in the process flow 700 do not necessary cover the entire life of the application. The fact that a module does not appear in the list does not mean that it will never be transmitted later.
• receiver systems can send requests to the server for modules that do not appear in the list.
• the list may cover the entire life of the application. If a module is described in the list as never to be transmitted again, or does not appear in the list, this could mean that the application should not expect to ever receive the module. As a consequence, the application could for example decide to exit if it needs a module that it knows, according to the list, will never be transmitted. Note that this methodology may also apply to receiver systems that are not connected to the return path or have not sent requests to the server.
• one embodiment of the present invention described reduces the redundant request for modules to be transmitted to the source system 12 and the number of times a module will be transmitted on a forward path to a plurality of receivers. Furthermore, one embodiment of the invention enables a receiver system to determine whether a module is to be transmitted from the source system 12 within a specific time, whereby the receiver might decide whether to wait for or request the module from the source system 12.
• Figure 9 is a block diagram illustrating a machine, in the exemplary form of a computer system 900 within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
• the machine may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
• the machine may be a server, personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
• PC personal computer
• PDA Personal Digital Assistant
• STB set-top box
• WPA Personal Digital Assistant
• a cellular telephone a web appliance
• network router switch or bridge
• the exemplary computer system 900 includes a processor 902 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 904 and a static memory 906, which communicate with each other via a bus 908.
• the computer system 900 may further include a video display unit 910 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
• the computer system 900 also includes an alphanumeric input device 912 (e.g., a keyboard), a user interface (UI) navigation device 914 (e.g., a mouse), a disk drive unit 916, a signal generation device 918 (e.g., a speaker) and a network interface device 920.
• a processor 902 e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both
• main memory 904 e.g., RAM
• static memory 906 e.g., RAM,
• the disk drive unit 916 includes a machine-readable medium 922 on which is stored one or more sets of instructions (e.g., software 924) embodying any one or more of the methodologies or functions described herein.
• code necessary to perform various functions may be embedded software stored in Flash, while application code and data may be loaded from the network into RAM.
• the software 924 may also reside, completely or at least partially, within the main memory 904 and/or within the processor 902 during execution thereof by the computer system 900, the main memory 904 and the processor 902 also constituting machine-readable media (executed directly or indirectly by the machine).
• the software 924 may further be transmitted or received over a network 926 via the network interface device 920.
• machine-readable medium 992 is shown in an exemplary embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
• the term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention.

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• Databases & Information Systems (AREA)
• Computer Graphics (AREA)
• Human Computer Interaction (AREA)
• Physics & Mathematics (AREA)
• Astronomy & Astrophysics (AREA)
• General Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (2)

Family

ID=36498461

Family Applications (1)

Country Status (5)

Cited By (2)

Families Citing this family (6)

Family Cites Families (32)

• 2004
  • 2004-11-29 US US10/999,209 patent/US20060117355A1/en not_active Abandoned
• 2005
  • 2005-11-17 AU AU2005309706A patent/AU2005309706B2/en not_active Expired
  • 2005-11-17 JP JP2007543380A patent/JP4782145B2/ja not_active Expired - Lifetime
  • 2005-11-17 EP EP05849684A patent/EP1817909A4/en not_active Withdrawn
  • 2005-11-17 WO PCT/US2005/042227 patent/WO2006057981A2/en not_active Ceased

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events