Methods and apparatus for selecting multicast ip data transmitted in broadcast streams

METHODS AND APPARATUS FOR SELECTING

MULTICAST IP DATA TRANSMITTED IN

BROADCAST STREAMS

BACKGROUND OF THE INVENTION

1. FIELD OF THE INVENTION

The present invention relates generally to computer software. More particularly, the present invention relates to methods and apparatus for selecting multicast data transmitted in broadcast streams.

2. DESCRIPTION OF RELATED ART

The digital television revolution is one of the most significant events in the history of broadcast television. With the advent of digital television, high speed data transfer is possible via satellite, cable and terrestrial television channels. Digital television offers users more channels as well as significantly improved video and audio quality. Most importantly, digital television ushers in the age of true interactive television. For instance, digital receivers will be able to offer users a variety of enhanced services, from simple interactive quiz shows, to internet, and a mix of television and web-type content. As the market for digital television grows, content developers are looking for a feature-rich, cost-effective, and reliable software platform upon which to build the next generation of interactive television services such as Electronic Programming Guides, Video-On-Demand, and Enhanced

Broadcasting.

Java is a leading commercial object-oriented language designed as a portable language that can run on any compatible device that supports the JAVA™ PLATFORM. For instance, Java is incorporated into all major Web browsers. Thus, Java runs on any web-enabled computer via that computer's Web browser. As such, Java offers great promise as the software platform for set-top boxes and digital television.

In object-oriented programming, code and data are merged into objects. Each object is defined via its class, which determines the properties and behavior of an object. In other words, objects are individual instances of a class.

In an interactive digital television environment, it will be common to receive data from multiple sources. For instance, a television program (i.e., service) received by a particular channel might consist of audio, video as well as other data (e.g. IP data streams). With the advent of digital television, it would be desirable if the data received by a television receiver could include data from the Internet and therefore conform to the Internet Protocol (IP). Moreover, it would be desirable if each channel could receive data from multiple sources.

When a television channel broadcasts digital data to viewers, it is impossible to address digital data to each viewer individually (e.g., through a single address). Thus, in order to send digital data to multiple television viewers simultaneously, multicast addressing must be used. However, no central repository or mechanism exists to verify that the same multicast address is not used by multiple sources (e.g., channels). It is therefore impossible to distinguish data streams by the associated multicast address. Moreover, it would be desirable to transmit data received from other sources such as those available on the Internet on two different channels. It is therefore possible that the data received by these multiple sources may conflict. This is particularly important since picture-in-picture capability is available in most televisions. As a result, it is possible that conflicting data may be received by multiple channels that are being simultaneously displayed via a picture-in-picture option. Thus, conflicting data may be provided to a single channel through multiple data streams or to multiple channels through a single data stream received by each of the channels. In either case, when this data is ultimately provided to one or more television channels, it would be undesirable if this conflicting data were broadcast to television viewers via the wrong television channel or presented in an incorrect manner by a television channel.

In view of the above, it would be beneficial if a mechanism for unambiguously identifying and selecting one of the data streams associated with a particular channel could be provided. Moreover, it would be desirable if such a mechanism were designed to identify, select, and read a multicast IP data stream transmitted in a broadcast stream, even where multiple data streams are associated with the same multicast address.

SUMMARY

The present invention enables multicast IP data transmitted in broadcast streams to be selected and received. More particularly, a network interface card has an associated IP address. However, a digital television receiver cannot identify a network interface card. Rather, a digital television receiver communicates solely with one or more associated tuners. Thus, through the association of an IP address with each data stream, a single system may be used to read and display data associated with a network card as well as a tuner.

In accordance with one aspect of the invention, each data stream associated with a tuner is identified by a unique IP address. More particularly, a locator adapted for identifying a data stream is obtained, where the locator is associated with one of a plurality of data streams. The locator is then mapped to an LP address. Through the use of this mapping, a digital television receiver may obtain the appropriate locator to read the associated data stream. In this manner each data stream may be uniquely identified, even where multiple data streams are associated with a single multicast address.

In accordance with another aspect of the invention, it is determined whether the JP address corresponds to a data stream locator associated with a data stream. When it is determined that the IP address corresponds to a data stream locator, a tuner is instructed to read the data stream associated with the data stream locator. However, when it is determined that the IP address does not correspond to a data stream locator, a network card identified by the IP address is instructed to read data from its associated network. However, all information in a particular data stream may not be relevant. More particularly, it may be desirable to filter the information in the data stream. Thus, since each data stream may be associated with a plurality of multicast IP addresses, a multicast group address may then be specified to identify the appropriate multicast IP data transmitted in the broadcast stream. Packets addressed to the multicast group address may then be received by either a tuner or a network interface card. Accordingly, a single system may be used to select and receive multicast IP data transmitted in broadcast streams via a network card or a tuner. BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which: FIG. 1 is a block diagram illustrating a digital television receiver in which the present invention may be implemented.

FIG. 2 is a block diagram illustrating a system in which the present invention may be implemented.

FIG. 3 is a process flow diagram illustrating a method of receiving packets addressed to a multicast address in accordance with an embodiment of the invention.

FIG. 4 is a diagram illustrating the use of locators to identify data streams in accordance with an embodiment of the invention.

FIG. 5 is a diagram illustrating the use of an interface map to map a data stream to an IP address through the use of a locator in accordance with an embodiment of the invention.

FIG. 6 is a process flow diagram illustrating a method of identifying a data stream using an interface map such as that illustrated in FIG. 5.

FIG. 7 is a process flow diagram illustrating a method of performing the set interface method shown at block 306 of FIG. 3 in accordance with an embodiment of the invention.

FIG. 8 is a block diagram illustrating a typical, general-purpose computer system suitable for implementing the present invention. DETAILED DESCRIPTION OF THE PREFERRED

EMBODIMENTS

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order not to unnecessarily obscure the present invention. The invention is described within the context of a digital television and digital television receiver. FIG. 1 is a block diagram illustrating an exemplary digital television receiver. As shown, a signal is received via antenna 102 and tuned by tuner module 104, producing MPEG2 transport stream 106. De-multiplexer 108 then produces encrypted MPEG streams 110 including a video stream 112, an audio stream 114, and one or more data streams 116. These three streams are then processed by conditional access subsystem 118. For instance, the conditional access subsystem 118 may utilize key management information 120 as well as decryption information 122 (e.g., decryption algorithms). The conditional access subsystem 118 produces decrypted MPEG streams 123 including a video stream 124 and audio stream 125 as well as data 126, all of which are decrypted. A decoder 128 then processes the decrypted MPEG stream 123, and forwards the decoded video data to frame buffer

130 and transmits the decoded audio data to speaker 132.

A Java Virtual Machine is one platform that may be used to implement the present invention to process information received by a digital television receiver such as that illustrated in FIG. 1. More particularly, when the data 126 (e.g., broadcast data stream) is processed, it may be desirable to process information such as a downloaded application provided in the data 126. Moreover, each associated service or program provided by a channel may include one or more data streams, as represented by the data 126 as described above with reference to FIG. 1.

FIG. 2 is a block diagram illustrating an exemplary system in which the present invention may be implemented. A digital television receiver 202 is shown to include a first television tuner 204 and a second television tuner 205. A receiver typically requires a tuner for each different picture (e.g., picture-in-picture) provided. Thus, when a receiver includes two or more tuners, multiple channels may be simultaneously be available to a television viewer. As shown, the first tuner 204 has an associated video stream 206, audio stream 208 and data stream 210. Similarly, the second tuner 205 has an associated video stream 212, audio stream 214, and a first data stream 216, a second data stream 218 and a third data stream 220. Thus, the second tuner 205 has three associated data streams. It would be desirable if the data streams received by the television receiver could include Internet Protocol (IP) formatted data. However, as described above, since multiple sources of data may be using the same multicast group address, it is necessary to distinguish the data streams from one another. FIG. 3 is a process flow diagram illustrating a method of receiving packets addressed to a multicast address in accordance with an embodiment of the invention. In accordance with one embodiment, a method of selecting multicast IP data transmitted in broadcast streams is implemented through the customization and modification of a method of receiving packets by a network card. First, a Java.net.multicastsocket class is obtained at block 302. Next, a multicast socket object capable of listening for multicast data which is sent through the object is instantiated at block 304. More particularly, the object includes a method for specifying an IP address, a method for specifying a multicast group address to listen in on, and a method for receiving packets addressed to the multicast address. These methods are then called in blocks 306 through 310. At block 306, the method for specifying an LP address is called. More particularly, the method instructing a tuner to read a data stream associated with the IP address when the IP address corresponds to a data stream locator, and otherwise instructs a network card to read data from the network. One method of specifying an LP address is described in further detail below with reference to FIG. 7. Next, at block 308, the method for specifying a multicast group address is called to specify a multicast group address associated with the IP address (e.g., data stream). The method for receiving packets addressed to the multicast group address is then called at block 310. Garbage collection may then be performed for the multicast object when it is no longer being used. Through the modification of the method of specifying an IP address (i.e., via a set interface method) described above at block 306, multicast IP data may be received by a tuner as well as a network card. When the set interface method is called, an IP address is provided to the set interface method. More particularly, the IP address corresponds either to a network interface card or the IP address corresponds to a data stream. When the IP address is associated with a data stream rather than a network interface card, the appropriate IP address must be obtained. Thus, even when multiple sources are transmitting on the same multicast group address, the present invention enables each data stream to be uniquely identified. FIGs. 4 through 6 illustrate a mechanism for mapping an IP address to a data stream in order to uniquely identify that data stream, even where multiple data streams are associated with the same multicast group address.

FIG. 4 is a diagram illustrating the use of locators to identify data streams in accordance with an embodiment of the invention. As described above, multiple data streams 216, 218, and 220 may be associated with a single multicast IP address. In order to distinguish the data streams 216, 218 and 220 from one another, a locator adapted for identifying a data stream is associated with each of the data streams 216, 218 and 220. Each of the data streams 216, 218 and 220 may be associated with the same channel or a different channel. In accordance with one embodiment of the invention, an interface map is used to create a one-to-one mapping between each data stream and an associated local IP address. Thus, even where data streams are associated with the same multicast IP address, the data streams may be uniquely identified through the associated local IP addresses. FIG. 5 is a diagram illustrating the use of an interface map to map a data stream to an IP address through the use of a locator in accordance with an embodiment of the invention. As shown, for a particular data stream Dl 500, a locator LI 502 is obtained. For instance, the locator 502 may be a locator object that has been obtained from an outside source. Alternatively, the locator 502 may be instantiated internally by an interface map 504. Once the interface map 504 has obtained the locator 502, a local IP address L 506 is generated and mapped to the locator LI 502. For instance, the local IP address L 506 may be obtained from a pool of available IP addresses. Thus, through the use of the interface map 504, a one-to- one correspondence is created between each data stream and a local IP address.

FIG. 6 is a process flow diagram illustrating a method of identifying a data stream using an interface map such as that illustrated in FIG. 5. As shown, a locator is obtained at block 602. For instance, a locator object may be instantiated or obtained from another source. The locator is then associated with one of a plurality of data streams at block 604, each one of the plurality of data streams being associated with one of a plurality of television channels. For instance, the data streams may be associated with the same channel or different channels. An interface map such as that illustrated in FIG. 5 is then used to map the locator to an LP address at block 606. For instance, the IP address may be generated from a set of local IP addresses reserved for use in private networks. The locator object may then be garbage collected when it is no longer used. In this manner, data streams associated with one or more tuners may be identified.

Once the IP address associated with the data stream locator is obtained from the interface map, the address may be used to specify the local IP address via the set interface method as shown at block 306 of FIG. 3. FIG. 7 is a process flow diagram illustrating a method of performing the set interface method shown at block 306 of FIG. 3 in accordance with an embodiment of the invention. Once a local IP address is obtained at block 702, it is determined from the interface map whether the local IP address corresponds to a data stream locator associated with a data stream at block 704. At block 706, when it is determined that the IP address corresponds to a data stream locator associated with a data stream, the data stream associated with the data stream locator is selected. More particularly, the digital television receiver may use the locator to read the associated data stream. Thus, the locator is identified at block 708 and a tuner is instructed to read the data stream associated with the locator at block 710. For instance, the tuner may be a tuner that is tuned to the data stream or it may simply be a tuner that is currently unused. When it is determined at block 706 that the IP address does not correspond to a data stream locator, the local address corresponds to a network card as shown at block 712 and the network card is instructed to read data from the network at block 714. When the IP address is no longer being used to read the data stream, the IP address may be released for future use. For instance, the interface map may be instructed to release the IP address for future use when it is no longer in use.

Although the IP address has been specified, there may be multiple multicast addresses associated with the IP address. Thus, once the tuner or network card has been instructed to read the data identified by the IP address, a multicast group address associated with the IP address is specified as described above with reference to block 308. Packets addressed to the multicast address may then be received as shown at block 310.

Through the use of the present invention, an IP address may be used to specify a network card or a data stream associated with a tuner. In this manner each data stream may be uniquely identified, even where multiple data streams are associated with a single multicast address. Moreover, through the mapping of an IP address to each data stream, an existing system which is capable of reading data associated with a network card may easily be modified for use with a tuner.

The present invention may be implemented on any suitable computer system. FIG. 8 illustrates a typical, general-purpose computer system 1502 suitable for implementing the present invention. The computer system may take any suitable form. For example, the computer system may be integrated with a digital television receiver or set top box.

Computer system 1530 or, more specifically, CPUs 1532, may be arranged to support a virtual machine, as will be appreciated by those skilled in the art. The computer system 1502 includes any number of processors 1504 (also referred to as central processing units, or CPUs) that may be coupled to memory devices including primary storage device 1506 (typically a read only memory, or ROM) and primary storage device 1508 (typically a random access memory, or RAM). As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPUs 1504, while RAM is used typically to transfer data and instructions in a bi-directional manner. Both the primary storage devices 1506, 1508 may include any suitable computer-readable media. The CPUs 1504 may generally include any number of processors.

A secondary storage medium 1510, which is typically a mass memory device, may also be coupled bi-directionally to CPUs 1504 and provides additional data storage capacity. The mass memory device 1510 is a computer-readable medium that may be used to store programs including computer code, data, and the like. Typically, the mass memory device 1510 is a storage medium such as a hard disk which is generally slower than primary storage devices 1506, 1508. The CPUs 1504 may also be coupled to one or more input/output devices

1512 that may include, but are not limited to, devices such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers. Finally, the CPUs 1504 optionally may be coupled to a computer or telecommunications network, e.g. , an internet network or an intranet network, using a network connection as shown generally at 1514. With such a network connection, it is contemplated that the CPUs 1504 might receive information from the network, or might output information to the network in the course of performing the above- described method steps. Such information, which is often represented as a sequence of instructions to be executed using the CPUs 1504, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.

Although illustrative embodiments and applications of this invention are shown and described herein, many variations and modifications are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those of ordinary skill in the art after perusal of this application. For instance, the present invention is described as being implemented within the context of a digital television receiver. However, the present invention may be used in other contexts. Moreover, although the present invention is described as being implemented on a JAVA PLATFORM, it may also be implemented on a variety of platforms. Moreover, the above described process blocks are illustrative only. Therefore, the present invention may be performed using alternate process blocks as well as alternate data structures. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.