Patent Grant
8713195
The invention relates generally to digital video networks, and more particularly, to techniques for streaming digital video content to a client in a digital video network that is capable of distributing digital video content via multicasting and unicasting.
The viewer experience with delivery of digital video content via broadcast channels is often poor. Because of the characteristics of compressed video encoding, the viewer often waits seconds after selection of a broadcast channel until the digital video content is finally displayed. Because viewers are accustomed to near instantaneous channel change functionality with analog television, the quality of the digital television experience often times does not meet viewer expectations.
One cause of the slow channel change problem involves the framing of compressed video (e.g., MPEG2 or MPEG4/H.264). In order to minimize bandwidth, the majority of the frames contained within a compressed stream of digital video content are P-frames and B-frames, which are frames that encode changes to a displayed image. An I-frame (MPEG2) on the other hand is a frame that presents a complete new image. The rate at which I-frames (or equivalent I-slice constructs in MPEG4) are delivered in a digital video stream is typically one I-frame every ¼ to 2 seconds, depending on the amount of motion contained within the stream. The delay after requesting a channel change is dominated by having to wait until the next I-frame finally arrives, which can be up to 2 seconds, before the new channel can be displayed.
In an Internet Protocol (IP) television environment, different channels of digital video content are distributed to multiple clients via IP multicasting. One technique for implementing a fast channel change in an IP television environment is described in U.S. Pat. Publ. No. 2005/0081244 to Barret et al. The technique described by Barret et al. involves servicing a channel change request by 1) retaining an I-frame from each different broadcast stream, and then 2) transmitting the retained I-frame for the requested channel to the corresponding client via a unicast message instead of via a multicast message. The I-frame is then used to quickly display the requested channel. Once the retained I-frame is sent to the client via the unicast message, the client is rapidly joined to the multicast group corresponding to the requested channel in time for the client to receive the next I-frame via multicasting. In IP television environments, internet group management protocol (IGMP) is typically used to join clients to multicast groups. While transmitting an I-frame via a unicast message works well to achieve a fast channel change, using IGMP to join a client to a multicast group requires multiple messages between client and server. When a large number of channel change requests are made in a short period of time, the flood of associated IGMP messages can introduce significant delay into the network. In particular, delay associated with the IGMP messages can place limitations on the scalability of this fast channel technique.
In addition to a channel change being fast, it is important to the viewer experience that the quality of the post-channel change content be comparable to the quality of the pre-channel change content. Real-time Transport Protocol (RTP) is a packet-based protocol that is widely used to stream video media. RTP Control Protocol (RTCP) is a control protocol for use with RTP. Upon receiving a new stream of digital video content, typical RTP/RTCP schemes require the receiving client to wait for a client buffer to grow large enough to sustain negative acknowledgements before digital video content from the new stream can be played out at the client. The wait time can be reduced by sending an initial burst of digital video content to the client to rapidly fill the buffer. Although it is possible to transmit a large initial burst of digital video content to rapidly fill a client buffer, this approach does not scale well in a multiclient digital video network.
In view of this, what is needed is a technique for streaming digital video content to a client, including providing fast channel changes, which is able to provide new streams of digital video content to a client with minimal delay at an acceptable quality level and which scales well when applied in a multi-client network.
A technique for streaming digital video content to a client involves providing a new stream of digital video content to the client using forward error correction (FEC) for a limited initial period and then ending the use of FEC after the limited initial period has ended. In an embodiment, during the limited initial period, the digital video content is provided to the client at a rate that is slightly higher than the playout rate, e.g., 1-10% higher than the playout rate, in order to allow a client buffer to accumulate digital video content. FEC continues to be used until the client buffer is sufficiently populated such that lost or damaged frames can be retransmitted to the client before the corresponding digital video content is needed for playout. Once the client buffer is sufficiently populated, FEC is ended and retransmission is used to maintain the quality of the streamed digital video content. Using FEC for the limited initial period provides error protection immediately upon receiving a new stream of digital video content without imposing long term processing and bandwidth drains on the network. The use of FEC for the limited initial period enables the client to immediately begin decoding and displaying new digital video content while allowing time for the client buffer to be filled without having to send a large burst of frames to the client. Additionally, using retransmission after the limited initial period to provide long term error protection reduces the demands on processing and bandwidth resources.
In an embodiment, the technique is applied to servicing a channel change request in a streaming digital video network. In this application, the technique involves using FEC for a limited initial period after detecting a channel change request. FEC helps to maintain the quality of digital video content for the requested channel immediately upon executing the channel change and thereby supports a high-quality fast channel change. FEC continues to be used until a buffer at the client is sufficiently populated such that lost or damaged frames can be retransmitted to the client before the corresponding digital video content is needed for playout. While FEC is used, the client buffer is populated by a relatively small increase in the stream rate over the playout rate and without a large burst of frames. Once the client buffer is adequately populated, FEC is ended and retransmission is used to maintain the quality of the streamed digital video content.
Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
Throughout the description, similar reference numbers may be used to identify similar elements.
As used herein, the terms “multicast” and “multicasting” refer to a technique for providing the same digital video content to multiple clients in which the digital video content is delivered over common links only once (e.g., the digital video content is copied when it reaches nodes with links to multiple destinations). As used herein, multicast and multicasting are synonymous with the terms broadcast and broadcasting as related to, for example, hybrid fiber coaxial (HFC) cable networks.
As used herein, the terms “unicast” and “unicasting” refer to a technique for providing digital video content to a single specified client.
In some applications, the network for distributing digital video content is a packet-based network. In packet-based networks, multicasting may involve replicating packets at nodes that include multiple branches leading to different clients. The replication of packets at branching nodes eliminates the need to send multiple packets of the same content over the same link. Packet-based distribution networks may utilize, for example, IP, Ethernet, ATM, or a combination thereof to communicate digital video content. In packet-based networks, unicasting typically involves point-to-point messaging between nodes (e.g., servers and clients). Point-to-point messaging can be accomplished, for example, using well-known source/destination address based protocols (e.g., IP or Ethernet).
In some applications, the network for distributing digital video content includes an HFC network that utilizes radio frequency signals (RF) for local distribution of digital video content to the clients. In HFC networks, multicasting typically involves distributing all channels to all clients. Each client is able to receive any channel by tuning to the desired channel. In HFC networks, unicasting may involve distributing a channel, which is intended for only one client, to multiple clients and coordinating with the intended client so that only the intended client is able to receive to the desired channel. Even though the channel may be distributed to multiple clients, only one client, the intended client, is able to access the channel and display the digital video content. For purposes of this description, a communications technique such as this, which can be implemented in HFC networks, is considered unicasting.
The distribution network 110 supports the multicasting and unicasting of digital video content downstream to the clients 112. The distribution network also supports upstream unicast messaging from the clients to the stream server 106 and channel change server 108. The distribution network may utilize any network technology that supports multicasting and unicasting. In a packet-based environment, the distribution network may utilize, for example, routers, switches, DSLAMs, cable modem termination systems (CMTSs), passive optical network (PON) architectures, or any combination thereof. In an HFC environment, the distribution network may utilize, for example, a combination of routers, switches, and QAMs. The clients are systems that receive the digital video content from the distribution network and provide the digital video content to video display devices (e.g., televisions). The clients may be embodied as hardware, firmware, software, or any combination thereof and are sometimes referred to as set-top boxes (STBs). Clients in general are well-known in the field. Specific functions of the clients in accordance with the invention are described in more detail below.
Referring to
In the example of
Referring to
In accordance with the invention and in contrast to the prior art, the digital video content related to channel 2 continues to be provided to the client 112 via unicasting until a pre-established condition is met. That is, multiple consecutive frames of digital video content related to channel 2 are unicast to the client and the client is not switched back to receiving digital video content via multicasting until some pre-established condition is satisfied. In particular, the client is not switched back to multicasting after the unicasting of a single I-frame as is known in the prior art. By not immediately switching back to multicasting after unicasting the single I-frame, the network is allowed to opportunistically switch the client from unicasting back to multicasting. By opportunistically switching the client from unicasting back to multicasting, network resources can be intelligently managed to achieve efficient resource utilization.
In accordance with the invention, exemplary pre-established conditions which could trigger a switch from unicasting back to multicasting include:
1) Expiration of a pre-established time interval;
2) Expiration of a pre-established time interval in which no channel change requests are received;
3) An explicit request to join multicasting (e.g., a request to switch back to multicasting or a request to exit a surf mode);
4) Reaching a pre-established resource threshold (e.g., switch back to multicasting only when certain resources are available);
5) Reaching a benefit threshold (e.g., switch back to multicasting only if a certain benefit is achieved or only if certain resources can be reclaimed).
Before the client 112 is switched back to multicasting, if any additional channel change requests are made by the client (e.g., client A), the channel change requests are serviced via unicasting instead of multicasting.
Once the pre-established condition is met, the process of switching back to providing digital video content to the client 112 via multicasting instead of unicasting is initiated.
With reference to
In an embodiment, channel change requests are serviced through interaction between the server system 104 and the client 112.
In an alternative embodiment of the invention, whether the digital video content is provided via multicasting or unicasting is a function of whether or not the client is in “surf mode.” When the client is not in surf mode, digital video content is provided to the client via multicasting and when the client is in surf mode, digital video content is provided to the client via unicasting.
An embodiment of the process of servicing a channel change request via unicasting is now described with reference to
In the convention used in
As described above, a channel change request is serviced by providing digital video content related to the requested channel to the client 112 via unicasting instead of multicasting. In particular, the unicast session starts with the first buffered I-frame and continues with the buffered frames that come after the first I-frame.
In an embodiment, the server system is configured such that the multicast streams are streamed out slightly ahead of any unicast streams. That is, duplicate frames of digital video content will be streamed via multicasting slightly before the corresponding frames are streamed via unicasting. As will be seen, the fact that multicast streams are slightly ahead of their corresponding unicast streams can be used advantageously to transition the client from unicasting to multicasting without skipping a frame.
Switching from unicasting back to multicasting may be accomplished using many different techniques. Although there are many different techniques that can be used to switch from unicasting back to multicasting, it is desirable to make the switch without causing any disruption to the playout of the digital video content by the client 112. For example, it is desirable to avoid skipping any frames that make up the stream of digital video content. A seamless switch from unicasting back to multicasting can be accomplished, for example, using one of the techniques described below.
A first technique for switching a client from unicasting back to multicasting involves accumulating enough digital video content at the client to bridge the time it takes to transition from receiving the digital video content via unicasting to receiving the digital video content via multicasting. The transition time is a function of the network specifics. For example, in HFC networks that utilize RF for local delivery of digital video content to the clients, the transition time is a function of how long it takes to retune the tuner to a new channel. In IP-based networks, the transition time is a function of how long it takes to join the client to the corresponding multicast group. In accordance with an embodiment of the invention, digital video content is accumulated at the client by temporarily increasing the stream rate of the unicast stream above the playout rate. While the digital video content is being streamed at the increased rate, the amount of digital video content stored in the client's stream buffer grows (as opposed to staying the same, which is the case when the stream rate is the same as the playout rate). That is, the number of frames in the client's stream buffer increases while the stream rate is increased. The stream rate is held at the increased rate until the client accumulates enough frames in its buffer to be able to bridge the time it takes to transition from receiving the digital video content via unicasting to receiving the digital video content via multicasting. For example, if the transition time from unicasting to multicasting is approximately 1 second, then the stream rate is increased until the client is able to accumulate at least 1 second worth of frames in the stream buffer. In an embodiment, the transition time includes the time required to make the switch from unicasting to multicasting plus the maximum delay that can be attributed to waiting for the next I-frame to arrive at the client (e.g., equal to the time of one GOP).
Operation of this technique is described with reference to FIGS. 8 and 9A-9D. Referring to
Exemplary states of the client's 112 stream buffer 154 are illustrated with respect to this technique in
Although in this embodiment, the process of switching to multicasting is initiated right after the client accumulates enough frames, in other embodiments, the client may wait to initiate the switch. Although a two buffer implementation is described with reference to
A second technique for switching a client from unicasting back to multicasting involves simultaneously providing the digital video content to the client via unicasting and multicasting until the client has buffered duplicate frames (i.e., frames that contain the same digital video content). Once the client has buffered duplicate frames, the client can transition from playing out of a buffer that holds frames received via unicasting to playing out of a buffer that holds frames received via multicasting without skipping a frame. Once the transition back to multicasting is complete, unicasting is terminated and any frames remaining in the unicast buffer are flushed.
Operation of this technique is described with reference to FIGS. 10 and 11A-11D. Referring to
Exemplary states of the client's stream buffer 154 related to this technique are illustrated in
Once the client begins to receive digital video content related to the current channel via multicasting in addition to unicasting, the multicast frames are buffered in a multicast buffer.
The join operation involves making a unique identification between a frame in the unicast buffer and the corresponding and identical frame in the multicast buffer. For this purpose, the minimum size of data required to effect a matching operation is defined as an Identification Quantum (IDQ). The IDQ represents the smallest amount of data required in order to be able to guarantee that a match between frames is unique. Selection of an IDQ type may be according to a list of choices, known to those skilled in the art. These include, but are not limited to: 1) a CRC or MD5 checksum, or other condensed representation, of the data contained within a single transport packet or within multiple packets, 2) a vector consisting of, but not limited to, one or more of the following fields: a transport packet continuity counter, a picture temporal reference, a picture type (I,P,B, etc.), an absolute stream offset from start, where the vector represents a unique frame start identifier, and 3) an in-stream marker bit or bits, or a set of the same (this is possible if the server is able to manipulate the contents of the multicast buffer).
One consequence of buffering the multicast frames and switching to the multicast buffer once duplicate frames arrive is that the timeline of the displayed digital video content is permanently time shifted by the interval that resulted from the first channel change. This delay can be expected to be on the order of from zero to the maximum GOP size (e.g., 1-2 seconds). The above-described technique is especially applicable to clients that are capable of concurrently receiving two different streams and to cases in which adequate bandwidth headroom is temporarily available (e.g., fiber or dual RF/IP path).
The processor 130, 150 within the channel change server 108 and client 112 may include a multifunction processor and/or an application specific processor that is operationally connected to the memory 132, 152. The processor performs functions, such as executing software code, which are well-known in the field. The memory within the channel change server and the client may include circuits for storing processor-executable instructions, for buffering digital video content, and for storing data structures. Although the processor and memory are depicted as separate functional units, in some instances, the processor and memory are partially or fully integrated onto the same device.
With reference to
The above-described techniques for servicing channel change requests can be applied to any type of distribution network that is able to distribute digital video content via multicasting and unicasting. The return to multicasting can be a one-sided operation that is accomplished entirely by the server system 104 and/or the client 112 or it can be a two-sided operation that involves communications between the server system and the corresponding client. The server system depicted in
In
Although the stream server 106 is depicted as a single entity for description purposes, the stream server may be implemented as a single server or multiple servers that act collectively to stream digital video content to the clients.
As described above, it is important to the viewer experience to be able to achieve a fast channel change in a digital video network. In addition to the channel change being fast, the quality of the displayed video after the channel change must also be maintained.
Two techniques for maintaining the quality of streaming digital video content are forward error correction (FEC) and retransmission. Forward error correction is a technique for maintaining the quality of streaming digital video content that involves adding redundant data to a transmission that enables the receiver to detect and correct errors in received data without requiring additional data from the transmitter. The strength of an FEC protocol is typically a function of the volume of redundant data that is added to the primary data stream, with more redundant data resulting in stronger FEC, e.g., better error correction capability. Many different FEC schemes exist, including, for example, schemes that are media-independent, schemes that are media-specific, schemes that utilize block coding, and schemes that utilize convolution coding. Block coding works on fixed size blocks of bits or symbols of predetermined size and convolution coding works on bit or symbol streams of arbitrary length.
Using FEC to maintain the quality of streaming digital video content increases the bandwidth required to transmit the same amount of digital video content to a client.
Retransmission is a technique for maintaining the quality of streaming digital video content that involves the retransmission of frames that are lost, damaged, or otherwise received with an unacceptably high BER. When a retransmission protocol is used after a channel change, a certain amount of digital video content must be buffered at the client before the retransmission protocol can be relied upon to provide effective error protection. The buffered digital video content is needed to provide a sufficient amount of time to complete the retransmission of lost or damaged frames back to the client before the digital video content carried in the frames is needed for playout at the client. If digital video content is streamed to the client at the playout rate, waiting for the client buffer to fill can negatively affect the channel change process. For example, the channel change can be delayed until the client buffer is sufficiently filled or the requested channel can be played out for an initial period without the benefit of retransmission of lost or damaged frames. A client buffer could be rapidly filled by sending a large initial burst of digital video content to the client immediately upon detecting a channel change request.
In accordance with an embodiment of the invention, a technique for servicing a channel change request in a streaming digital video network involves using FEC for a limited initial period after detecting a channel change request and then switching to a retransmission protocol at the end of the limited initial period. FEC helps to maintain the quality of digital video content for the requested channel immediately upon executing the channel change and thereby supports a high-quality fast channel change. In particular, the client does not have to wait for a buffer to fill and can therefore immediately begin decoding and displaying received digital video content for the requested channel. In an embodiment, FEC continues to be used until a buffer at the client is sufficiently populated such that lost or damaged frames can be retransmitted to the client before the corresponding digital video content is needed for playout. While FEC is used, the client buffer can be populated by a relatively small increase in the stream rate over the playout rate and without a large burst of frames. Once the client buffer is adequately populated, FEC is ended and retransmission is used to maintain the quality of the streamed digital video content. Using FEC for a limited initial period provides error protection immediately upon detecting the requested channel without imposing long term processing and bandwidth drains on the network. The use of FEC for the limited initial period also allows time for the client buffer to be filled without having to send a large burst of frames to the client. Additionally, using retransmission after the limited initial period ends provides long term error protection in a bandwidth effective manner.
An embodiment of a technique for servicing a channel change request is described with reference to
As described above, FEC is used for a limited initial period to maintain the quality of the streaming digital video content. For example, FEC is used until the client buffer is sufficiently populated such that lost or damaged frames can be retransmitted to the client before they are needed for playout. In an embodiment, the amount of digital video content that must be buffered to ensure that lost or damaged frames can be retransmitted to the client before they are needed for playout is indicated by a pre-established threshold. The pre-established threshold may be expressed, for example, in terms of the quantity of buffered digital video content at the client, the quantity of space available in the buffer, the utilization percentage of the client buffer, playout time of the buffered digital video content, the amount of time that the buffer trickle has been active, or some other criteria. Whatever the parameter, once the client buffer is populated to the pre-established threshold, the limited initial period ends and FEC is no longer used to provide digital video content to the client. Other actions that could trigger the end of the limited initial period include, for example, the expiration of a pre-established time interval or when digital video content related to the requested channel is switched from being provided to the client via unicasting to being provided to the client via multicasting. In an embodiment, the ending of FEC is triggered by the expiration of a time interval in the range of 20-30 seconds.
In the embodiment of
At some point after the requested channel has been provided to the client, the client can be switched from unicasting to back to multicasting. For example, the client can be switched from unicasting back to multicasting using one of the techniques described above with reference to
In another embodiment, the addition of the buffer trickle is not simultaneous with the beginning of FEC and the ending of the buffer trickle is not simultaneous with the ending of FEC. For example,
In another embodiment, it may be that the client buffer is filled enough to support retransmission but is not filled enough to support another operation such as a switch from unicasting to multicasting. In this case, FEC may be ended when the client buffer has reached a pre-established threshold that is specific to error protection while the buffer trickle is continued.
In the examples described with reference to
The graphs of
In an embodiment, the pre-established threshold related to the client buffer can be changed in response to criteria such as transmission time, link performance, BER, desired quality of service, etc. The change can be manually or automatically triggered and can be done on a static or dynamic basis.
As described above, digital video content is streamed to a client using FEC for a limited initial period. In order to use FEC as an error protection mechanism, an embodiment of the digital video network 100 includes an FEC encoder and an FEC decoder.
The client receive module 232 can determine whether or not a received stream includes FEC using various techniques. In one embodiment, the receive module knows that FEC is being used when FEC codes are identified. Once the FEC codes are no longer present in the stream, the client receive module can initiate a retransmission protocol for error protection. Other techniques that may be used by the client receive module to determine whether or not FEC is being used include placing an FEC indicator such as a flag in frame headers or providing FEC status information to the client via an out-of-band protocol such as the Real-time Streaming Protocol (RTSP).
In an embodiment, the strength of the FEC protocol is application-specific. The BER is generally a function of the strength of the FEC protocol, with stronger FEC protocols utilizing more redundant data that results in a lower BER. Further, the strength of the FEC protocol generally corresponds to the bandwidth requirement of the FEC protocol, with stronger FEC protocols requiring more bandwidth. In an embodiment, the FEC is selected to provide a BER in the range of 10-12, where a lower BER generally translates to higher quality digital video content. The strength of the FEC can be dynamically adjusted based on, for example, feedback related to the quality of the corresponding transport path.
In an embodiment, FEC can be applied to retransmissions of data. That is, even after FEC has ended for the transmission of the primary stream of digital video content, FEC may be used for the retransmission of data that is triggered by lost or damaged frames. The decision on whether or not to use FEC for the retransmission of data and the strength of the FEC protocol can be dynamically selected based on, for example, network conditions.
Although the above-described technique for maintaining the quality of streaming digital video content is described in the context of servicing channel change requests, the technique is applicable to any situation in which a new stream of digital video content is being provided to a client and/or a new stream session is setup. For example, a new stream of digital video content may be provided to a client when a channel change is initiated or when a new stream of digital video content is spliced into an existing stream (e.g., client-specific advertising content). In the general case of a new stream, an embodiment of the technique involves first identifying a new stream of digital video content that is intended for a client, e.g., in response to a channel change request or a splice of new content, such as a commercial or interactive content, into an existing stream. Once a new stream is identified, streaming of the previous stream ends, the client immediately flushes all buffered digital video content related to the previous stream, and digital video content corresponding to the new stream is provided to the client using FEC for a limited initial period. After the limited initial period, the use of FEC is ended. In an embodiment, during the initial limited period, the digital video content for the new stream is provided to the client at a rate that is higher than the playout rate (e.g., the buffer trickle). The increased rate above the playout rate enables a client buffer to accumulate digital video content related to the new stream. In an embodiment, the limited initial period ends once the client buffer is populated to a pre-established threshold. Once FEC ends, the quality of the streamed digital video content is maintained using a retransmission protocol instead of FEC.
Real-time Transport Protocol (RTP) is a packet-based protocol that is widely used to stream video media. RTP Control Protocol (RTCP) is a control protocol for use with RTP. The combination of RTP and RTCP is often referred to together as “RTP/RTCP.” The above-described techniques for maintaining the quality of streaming digital video content are especially applicable to a streaming environment that utilizes RTP with RTCP negative acknowledgements. Typical RTP/RTCP schemes require a client to wait for the client buffer to grow large enough to sustain negative acknowledgements (e.g., NAK/receive-transmitted-frame). As described above with reference to
The above-described technique for using FEC for a limited initial period is applicable to constant bit rate (CBR) or variable bit rate (VBR) traffic. The above-described technique is not limited to RTP/RTCP schemes and is applicable to any technique that enables identification of content transmission blocks and retransmission with reference to specific transmission blocks.
In an embodiment, encapsulation of both FEC and non-FEC encoded digital video content is equivalent from a framing perspective, e.g., when used in an RTP environment. For example, when a sequence of frames that was previously provided to a client using FEC is subsequently retransmitted to the client, the same sequence of frames will arrive at the client except without FEC encoding.
In an embodiment, at the end of the limited initial period, instead of ending FEC all together, the strength of the FEC can be reduced. Reducing the strength of the FEC reduces the bandwidth usage and processing utilization contributed from FEC while still providing some degree of error correction. In this case, the strength of the FEC that is used after the limited initial period is a balance between bandwidth usage, processing utilization, and the desired level of error correction.
Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts as described and illustrated herein. The invention is limited only by the claims.
This application is entitled to the benefit of provisional U.S. Patent Application Ser. No. 60/772,061, filed Feb. 10, 2006, the disclosure of which is incorporated by reference herein in its entirety. This application is a continuation in part of the U.S. patent application entitled “FAST CHANNEL CHANGE WITH CONDITIONAL RETURN TO MULTICASTING” having application Ser. No. 11/360,078, filed Feb. 23, 2006, the U.S. patent application entitled “SWITCHING A CLIENT FROM UNICASTING TO MULTICASTING BY INCREASING THE UNICAST STREAM RATE TO THE CLIENT” having application Ser. No. 11/360,080, filed Feb. 23, 2006, and the U.S. patent application entitled “SWITCHING A CLIENT FROM UNICASTING TO MULTICASTING BY SIMULTANEOUSLY PROVIDING UNICAST AND MULTICAST STREAMS TO THE CLIENT” having application Ser. No. 11/361,303, filed Feb. 23, 2006.
| Number | Name | Date | Kind |
|---|---|---|---|
| 2510397 | Hansell | Jun 1950 | A |
| 2915652 | Hatsopoulous | Dec 1959 | A |
| 3021472 | Hernqvist | Feb 1962 | A |
| 3118107 | Gabor | Jan 1964 | A |
| 3169200 | Huffman | Feb 1965 | A |
| 3173032 | Maynard | Mar 1965 | A |
| 3194989 | Garbuny | Jul 1965 | A |
| 3238395 | Sense | Mar 1966 | A |
| 3239745 | Hernqvist | Mar 1966 | A |
| 3267307 | Fox | Aug 1966 | A |
| 3267308 | Hernqvist | Aug 1966 | A |
| 3281372 | Haas | Oct 1966 | A |
| 3300660 | Bensimon | Jan 1967 | A |
| 3328611 | Davis | Jun 1967 | A |
| 3376437 | Mayerand, Jr. et al. | Apr 1968 | A |
| 3393330 | Vary | Jul 1968 | A |
| 3470393 | Moncorge | Sep 1969 | A |
| 3515908 | Caldwell | Jun 1970 | A |
| 3519854 | Davis | Jul 1970 | A |
| 3578992 | Shimada | May 1971 | A |
| 3600933 | Johnston | Aug 1971 | A |
| 3740592 | Engdahl et al. | Jun 1973 | A |
| 3821462 | Kaufman et al. | Jun 1974 | A |
| 3843896 | Rason et al. | Oct 1974 | A |
| 3992885 | Forster | Nov 1976 | A |
| 4004210 | Yater | Jan 1977 | A |
| 4011582 | Cline et al. | Mar 1977 | A |
| 4039352 | Marinescu | Aug 1977 | A |
| 4063965 | Cline et al. | Dec 1977 | A |
| 4097752 | Wulf et al. | Jun 1978 | A |
| 4148192 | Cummings | Apr 1979 | A |
| 4188571 | Brunson | Feb 1980 | A |
| 4199713 | Förster | Apr 1980 | A |
| 4224461 | Snyder, Jr. et al. | Sep 1980 | A |
| 4281280 | Richards | Jul 1981 | A |
| 4373142 | Morris | Feb 1983 | A |
| 4410951 | Nakamura | Oct 1983 | A |
| 4423347 | Kleinschmidt | Dec 1983 | A |
| 4667126 | Fitzpatrick | May 1987 | A |
| 4880975 | Nishioka et al. | Nov 1989 | A |
| 4928030 | Culp | May 1990 | A |
| 4937489 | Hattori | Jun 1990 | A |
| 4958201 | Mimura | Sep 1990 | A |
| 5028835 | Fitzpatrick | Jul 1991 | A |
| 5049775 | Smits | Sep 1991 | A |
| 5068535 | Rabalais | Nov 1991 | A |
| 5083056 | Kondou | Jan 1992 | A |
| 5119151 | Onda | Jun 1992 | A |
| 5229320 | Ugajin | Jul 1993 | A |
| 5233205 | Usagawa | Aug 1993 | A |
| 5235803 | Rodgers | Aug 1993 | A |
| 5247223 | Mori | Sep 1993 | A |
| 5307311 | Sliwa, Jr. | Apr 1994 | A |
| 5309056 | Culp | May 1994 | A |
| 5323737 | Farrell | Jun 1994 | A |
| 5327038 | Culp | Jul 1994 | A |
| 5332952 | Ugajin | Jul 1994 | A |
| 5336547 | Kawakita et al. | Aug 1994 | A |
| 5351412 | Furuhata | Oct 1994 | A |
| 5356484 | Yater | Oct 1994 | A |
| 5371388 | Oda | Dec 1994 | A |
| 5399930 | Culp | Mar 1995 | A |
| 5410166 | Kennel | Apr 1995 | A |
| 5465021 | Visscher | Nov 1995 | A |
| 5487790 | Yasuda | Jan 1996 | A |
| 5503963 | Bifano | Apr 1996 | A |
| 5521735 | Shimizu | May 1996 | A |
| 5592042 | Takuchi | Jan 1997 | A |
| 5625245 | Bass | Apr 1997 | A |
| 5675972 | Edelson | Oct 1997 | A |
| 5699668 | Cox | Dec 1997 | A |
| 5699772 | Yonekawa et al. | Dec 1997 | A |
| 5701043 | Razzaghi | Dec 1997 | A |
| 5722242 | Edelson | Mar 1998 | A |
| 5810980 | Edelson | Sep 1998 | A |
| 5874039 | Edelson | Feb 1999 | A |
| 5892767 | Bell et al. | Apr 1999 | A |
| 5917156 | Nobori et al. | Jun 1999 | A |
| 5973259 | Edelson | Oct 1999 | A |
| 5981071 | Cox | Nov 1999 | A |
| 5981866 | Edelson | Nov 1999 | A |
| 5994638 | Edelson | Nov 1999 | A |
| 6054837 | Edelson | Apr 2000 | A |
| 6064137 | Cox | May 2000 | A |
| 6084173 | DiMatteo | Jul 2000 | A |
| 6089311 | Edelson | Jul 2000 | A |
| 6117344 | Cox et al. | Sep 2000 | A |
| 6166317 | Volk, Jr. | Dec 2000 | A |
| 6175217 | Da Ponte et al. | Jan 2001 | B1 |
| 6192687 | Pinkerton et al. | Feb 2001 | B1 |
| 6214651 | Cox | Apr 2001 | B1 |
| 6225205 | Kinoshita | May 2001 | B1 |
| 6229083 | Edelson | May 2001 | B1 |
| 6232546 | DiMatteo et al. | May 2001 | B1 |
| 6271614 | Arnold | Aug 2001 | B1 |
| 6272873 | Bass | Aug 2001 | B1 |
| 6281514 | Tavkhelidze | Aug 2001 | B1 |
| 6314466 | Agarwal et al. | Nov 2001 | B1 |
| 6339785 | Feigenbaum | Jan 2002 | B1 |
| 6417060 | Tavkhelidze et al. | Jul 2002 | B2 |
| 6489704 | Kucherov et al. | Dec 2002 | B1 |
| 6493876 | DeFreese et al. | Dec 2002 | B1 |
| 6535909 | Rust | Mar 2003 | B1 |
| 6543053 | Li et al. | Apr 2003 | B1 |
| 6594793 | Guey | Jul 2003 | B1 |
| 6651105 | Bhagwat et al. | Nov 2003 | B1 |
| 6651760 | Cox et al. | Nov 2003 | B2 |
| 6691312 | Sen et al. | Feb 2004 | B1 |
| 6711741 | Yeo | Mar 2004 | B2 |
| 6720704 | Tavkhelidze et al. | Apr 2004 | B1 |
| 6731625 | Eastes et al. | May 2004 | B1 |
| 6774003 | Tavkhelidze et al. | Aug 2004 | B2 |
| 6823394 | Waldvogel et al. | Nov 2004 | B2 |
| 6845398 | Galensky et al. | Jan 2005 | B1 |
| 6869855 | Tavkhelidze et al. | Mar 2005 | B1 |
| 6973667 | Fritsch | Dec 2005 | B2 |
| 7107351 | Baumeister et al. | Sep 2006 | B2 |
| 7523482 | Barrett et al. | Apr 2009 | B2 |
| 7549160 | Podar et al. | Jun 2009 | B1 |
| 7788393 | Pickens et al. | Aug 2010 | B2 |
| 7904581 | Sherer et al. | Mar 2011 | B2 |
| 8140699 | Pickens et al. | Mar 2012 | B2 |
| 20010046749 | Tavkhelidze et al. | Nov 2001 | A1 |
| 20020114465 | Shen-Orr et al. | Aug 2002 | A1 |
| 20020124258 | Fritsch | Sep 2002 | A1 |
| 20020126755 | Li et al. | Sep 2002 | A1 |
| 20020170172 | Tavkhelidze et al. | Nov 2002 | A1 |
| 20030042819 | Martinovsky et al. | Mar 2003 | A1 |
| 20030068431 | Taliashvili et al. | Apr 2003 | A1 |
| 20030074667 | Cheung et al. | Apr 2003 | A1 |
| 20030093802 | Cho et al. | May 2003 | A1 |
| 20030093803 | Ishikawa et al. | May 2003 | A1 |
| 20030152815 | LaFollette et al. | Aug 2003 | A1 |
| 20040029341 | Cox et al. | Feb 2004 | A1 |
| 20040034712 | Rajwan et al. | Feb 2004 | A1 |
| 20040045036 | Terasaki | Mar 2004 | A1 |
| 20040195934 | Tanielian | Oct 2004 | A1 |
| 20050008240 | Banerji et al. | Jan 2005 | A1 |
| 20050081244 | Barrett et al. | Apr 2005 | A1 |
| 20050226272 | Luby et al. | Oct 2005 | A1 |
| 20050257106 | Luby et al. | Nov 2005 | A1 |
| 20060029065 | Fellman | Feb 2006 | A1 |
| 20060159117 | Furlong et al. | Jul 2006 | A1 |
| 20060187950 | Bou-Diab et al. | Aug 2006 | A1 |
| 20060200574 | Pickens et al. | Sep 2006 | A1 |
| 20060200576 | Pickens et al. | Sep 2006 | A1 |
| 20060215593 | Wang et al. | Sep 2006 | A1 |
| 20060279437 | Luby et al. | Dec 2006 | A1 |
| 20070107026 | Sherer et al. | May 2007 | A1 |
| 20070157221 | Ou et al. | Jul 2007 | A1 |
| 20080141097 | Vayanos et al. | Jun 2008 | A1 |
| 20080151805 | Vayanos et al. | Jun 2008 | A1 |
| 20080205640 | Shen-Orr et al. | Aug 2008 | A1 |
| 20090064242 | Cohen et al. | Mar 2009 | A1 |
| 20090100473 | Segel | Apr 2009 | A1 |
| Number | Date | Country |
|---|---|---|
| 4025618 | Feb 1992 | DE |
| 1 119 134 | Jul 2001 | EP |
| 1 487 215 | Dec 2004 | EP |
| 404080964 | Mar 1992 | JP |
| 7-322659 | Dec 1995 | JP |
| 10-238406 | Sep 1998 | JP |
| 961916 | Sep 1981 | SU |
| WO 9702460 | Jan 1997 | WO |
| WO 9910974 | Mar 1999 | WO |
| WO 9913562 | Mar 1999 | WO |
| WO 9940628 | Aug 1999 | WO |
| WO 0249359 | Jun 2002 | WO |
| WO 03021758 | Mar 2003 | WO |
| WO 03075496 | Sep 2003 | WO |
| WO 03083177 | Oct 2003 | WO |
| WO 03090245 | Oct 2003 | WO |
| Entry |
|---|
| Non-Final Office Action for U.S. Appl. No. 11/360,078, 33 pages (May 27, 2009). |
| Non-Final Office Action for U.S. Appl. No. 11/360,080, 16 pages (May 26, 2009). |
| Non-Final Office Action for U.S. Appl. No. 11/361,303, 8 pages (Jun. 23, 2009). |
| International Search Report for International Application No. PCT/US2006/006446, 3 pages (Apr. 10, 2007). |
| Written Opinion of the International Search Authority for International Application No. PCT/US2006/006446, 3 pages (Apr. 10, 2007). |
| International Search Report for International Application No. PCT/US2007/061957, 3 pages (Feb. 14, 2008). |
| Written Opinion of the International Search Authority for International Application No. PCT/US2007/061957, 4 pages (Feb. 14, 2008). |
| U.S. Final Office Action dated Dec. 23, 2009 cited in U.S. Appl. No. 11/361,303, 16 pgs. |
| U.S. Final Office Action dated Dec. 23, 2009 cited in U.S. Appl. No. 11/360,080, 30 pgs. |
| U.S. Office Action dated Oct. 4, 2010 cited in U.S. Appl. No. 11/361,303, 13 pgs. |
| U.S. Office Action dated Mar. 29, 2011 cited in U.S. Appl. No. 11/361,303, 10 pgs. |
| Canadian Office Action dated Nov. 3, 2009 in Appl. No. 2,597,836, 5 pgs. (60374.0525cawo). |
| European Communication/Extended European Search Report dated Oct. 4, 2011 in Application No. 06735917.4, 6 pgs. |
| European Communication/Extended European Search Report dated Nov. 22, 2012 cited in Appl. No. 07 756 849.1, 9 pgs. |
| Canadian Office Action dated Nov. 26, 2012 in Appl. No. 2,597,836, 2 pgs. |
| Fitzpatrick, Gary et al., “Demonstration of Close-Spaced Thermionic Converters,” Proceedings of the 28th Intersociety Energy Conversion Engineering Conference, May 1993, pp. 1.573-1.580, vol. 1, American Chemical Society, Washington, DC, USA. |
| Fitzpatrick, Gary O. et al., “Close-Spaced Thermionic Converters with Active Spacing Control and Heat-Pipe. Isothermal Emitters,” Proceedings of the 31stIntersociety Energy Conversion Engineering Conference, Aug. 11, 1996, pp. 920-927, vol. 2, IEEE, USA. |
| Fitzpatrick, Gary O. et al., “Updated perspective on the potential for thermionic conversion to meet 21stcentury energy needs,” IECEC '97, Proceedings of the 32ndIntersociety Energy Conversion Engineering Conference, Energy Systems, Renewable Energy Resources, Environmental Impact and Policy Impacts on Energy, Jul. 27, 1997, pp. 1045-1051, vol. 2, IEEE, USA. |
| Fukuda, Ryuzo et al., “Development of the Oxygenated Thermionic Energy Converters Utilizing the Sputtered Metal Oxides as a Collector,” Space Technology and Applications International Forum, 1999, AIP Conference Proceedings, Subseries: Astronomy and Astrophysics, Jan. 22, 1999, pp. 1444-1451, vol. 458, American Institute of Physics, USA. |
| Hatsopoulos, George N. et al., “Thermionic Energy Conversion—vol. 1: Process and Devices,” Mar. 15, 1974, p. 222, The MIT Press, USA. |
| Houston, J.M., “Theoretical Efficiency of the Thermionic Energy Converter,” Journal of Applied Physics, Sep. 17, 1959, pp. 481-487, vol. 30, No. 4, American Institute of Physics, New York. |
| Huffman, Fred N. et al., “Preliminary Investigation of a Thermotunnel Converter,” 1988 IECEC; Proceedings of the 23rdIntersociety Energy Conversion Engineering Conference, Aug. 1988, pp. 573-579, vol. 1, American Society of Mechanical Engineers, New York. |
| Kalandarishvili, Arnold G., “The basics of the technology of creating a small interelectrode spacing in thermionic energy converters with the use of two-phase systems,” IECEC '97, Proceedings of the 32ndIntersociety Energy Conversion Engineering Conference, Energy Systems, Renewable Energy Resources, Environmental Impact and Policy Impacts on Energy, Jul. 27, 1997, pp. 1052-1056, vol. 2, IEEE, USA. |
| King, Donald B. et al., “Results from the Microminiature Thermionic Converter Demonstration Testing Program,” Space Technology and Applications International Forum—1999, Jan 22, 1999, pp. 1432-1436, vol. 458, American Institute of Physics, USA. |
| Mahan, G.D., “Thermionic Refrigeration,” Journal of Applied Physics, Oct. 1, 1994, pp. 4362-4366, vol. 76, Issue, 7, American Institute of Physics, USA. |
| Shakouri Ali et al., “Enhanced Thermionic Emission Cooling in High Barrier Superlattice Hetero-structures,” Materials Research Society Symposium Proceedings, Mar. 1999, pp. 449-458, vol. 545, Materials Research Society, Warrendale, Pennsylvania. |
| Svennson, Robert et al., “TEC as Electric Generator in an Automobile Catalytic Converter,” Proceedings of the 31stIntersociety Energy Conversion Engineering Conference, Aug. 1996, pp. 941-944, vol. 2, IEEE, USA. |
| Zeng, Taofang et al., “Hot Electron Effects on Thermionic Emission Cooling in Heterostructures,” Materials Research Society Symposium Proceedings, Mar. 1999, pp. 467-472, vol. 545, Materials Research Society, Warrendale, Pennsylvania. |
| Number | Date | Country | |
|---|---|---|---|
| 20070192812 A1 | Aug 2007 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60772061 | Feb 2006 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11360078 | Feb 2006 | US |
| Child | 11673484 | US |
