Patent Grant
8561105
This application claims the benefit, under 35 U.S.C. §365 of International Application PCT/US2008/012456 and filed Nov. 4, 2008, which was published in accordance with PCT Article 21(2) on May 14, 2010, in English and which claims the benefit of U.S. provisional patent application No. 61/070,074, filed on Mar. 20, 2008, in English.
LiveTV™ is a major provider of airline in-flight entertainment systems, namely in-flight satellite-delivered live programming content, and allows air passengers to have the freedom to choose from a wide variety of satellite delivered live programming. Its main product comprises providing in-aircraft seat-back satellite television services, in addition to such services as live flight tracking, which allows people to see their current location during a flight in real-time. Depending on the region of the world the airline operates in, LiveTV™ can utilize different satellite television providers. For example, in the U.S.A. such satellite programming is typically provided by DirecTV™. Thus, in one example, a LiveTV™ system on an airplane can deliver DirecTV™ content to each passenger. A satellite system on an airplane can deliver many channels of content to its passengers in real time. However, if the pilot or stewardess interrupts the programming to make announcements, all of the real time satellite programming content during those announcements is lost.
Individual pause systems are used all over the world to adjust time to accommodate the viewer. Pause functions are well known in devices such as VCRs. For example, if the audio/video source is a VCR tape or tapes, a pause can be implemented by simply pressing the pause button on the VCR and then pressing ‘play’ when an interruption period is ended to resume playback of the program(s). This form of pause typically does not require any special design techniques. Indeed, a simple pause function for a single program is found today in many homes on a Personal Video Recorder (PVR) or Digital Video Recorder (DVR) unit. The PVR can have a specific design to record and playback programs as specified by its user. In almost all cases, only single programs are adjusted in time and not an entire system. One complication with individual storage systems is that if the viewer changes stations during the program, unless the other program has an equal pause, he will not be able to go back to his original station without losing portions of the original program.
However, providing a pause function in a real time digital streaming environment with hundreds of channels available, such as in an airplane satellite system, presents a challenging problem. This is especially so since the viewer is normally not in control of the video/audio program other than selecting what is available. Pausing a streaming system also introduces complications with system clocks, program guides, and control systems.
In one embodiment according to the present principles, a system and method is provided for ensuring that viewers watching live broadcast television programming, e.g., live satellite program content on, e.g., an aircraft, bus, train, theater, etc., configured to deliver live broadcast television content, is enabled to tailor and adjust the programming start times of programs to a desired start time. Advantageously, viewers are not constrained by the departure and arrival schedules of a particular transportation vehicle or flight with regards to viewing program content.
According to one aspect, a global schedule pause feature is provided configured to store all of the delivered streams in a buffer, and to enable the delivery of the streamed content to the viewer at multiple, time-delayed start times. Advantageously, the viewers would therefore not miss any of the program content for any of the channels and can select a desired start time for a desired program.
According to one aspect, a system is provided configured to store all of the desired program content from all sources up to a limit of the system's bandwidth and to enable each program to be played back from the beginning at pre-determined delayed start times. Thus, a viewer can select a desired start time of a desired program.
According to another aspect, the program content which is to be stored is filtered so that only program content which is popular and/or likely to be viewed is stored.
Such a system can be simplified, e.g., by providing all of the pause functionality close to the tuner outputs. This eliminates requiring each passenger's set top box to include local storage to provide a pause function. In addition, the passengers do not have to worry about handling and implementing the control functions since the saving and resuming procedures would be automatically performed for all of the programming content. In addition, the data rate for incoming signals can be handled efficiently as one entire system versus handling each channel independently, further simplifying the system's operation and increasing efficiency.
In one aspect of the present principles, a system for providing a global program guide pause function in a broadcast multimedia system is provided comprising a first main control configured for processing audio and video data content received from a packet processor, the first main control comprising an analyzer module for acquiring and analyzing program guide data to determine multiple time-delayed start content; a filtration module for filtering out undesired content and enabling desired data streams to be saved in at least one global memory device; and a guide module for creating a program guide comprising only non-filtered programs being offered at time-delayed start times.
According to another aspect, a system for providing a global program guide pause function in a broadcast multimedia system is provided comprising a first main control configured for processing audio and video data content received from a packet processor, the first main control comprising an analyzer module for acquiring and analyzing program guide data to determine multiple time-delayed start content;
a filtration module for filtering out undesired content and enabling desired data streams to be saved in at least one global memory device; and a guide module for creating a program guide comprising only non-filtered programs being offered at time-delayed start times, the guide module further configured to create multiple listings in the program guide showing a real-time versus a delayed-start time for each non-filtered program. A popular stream packet processor is provided configured for saving data content corresponding to popular programs.
According to yet another aspect, a method for providing a global program guide pause function in a broadcast multimedia system configured to receive audio and video data content is provided comprising the steps of analyzing program guide data to determine program information; determining a size of pause buffers to determine multiple time-delayed start content; filtering out undesired data content to save desired data content in at least one pause function memory device; and creating at least one of multiple start times for programs comprising popular data content and multiple listings showing a real-time versus a delayed start time for each program in the desired data content.
These, and other aspects, features and advantages of the present principles will be described or become apparent from the following detailed description of the preferred embodiments, which is to be read in connection with the accompanying drawings.
In the drawings, wherein like reference numerals denote similar elements throughout the views:
It should be understood that the drawings are for purposes of illustrating the concepts of the present principles and are not necessarily the only possible configurations for illustrating the present principles.
A method, apparatus and system for providing a universal or global system program guide pause function for broadcast programming is advantageously provided according to various aspects of the present principles. Although the present principles will be described primarily within the context of an aircraft (in-flight) programming and program guide pause system and method, the specific embodiments of the present principles should not be treated as limiting the scope of the invention. It is appreciated by those skilled in the art and informed by the teachings of the present principles that the concepts of the present principles can be advantageously applied in other environments in which a global program schedule pause function is desired, e.g., broadcast television/radio, satellite radio, cable, etc., in environments having contained, limited audiences such as theaters, and in transportation means such as buses, trains, etc.
The functions of the various elements shown in the figures can be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor (“DSP”) hardware, read-only memory (“ROM”) for storing software, random access memory (“RAM”), and non-volatile storage. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).
Thus, for example, it is appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative system components and/or circuitry embodying the principles of the invention. Similarly, it is appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which can be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
In accordance with various embodiments of the present principles, a method, apparatus and system is described for providing a system-wide or ‘global’ pause function, namely, for simultaneously pausing multi-channel broadcast multimedia/television content broadcast to a plurality of viewers in real time. While the present principles can be applicable to any broadcast television system, the examples herein are described in relation to, e.g., aircraft satellite television environments in which television content is displayed to passengers either individually, e.g., in seat-back displays, or in groups, e.g., via a plurality of displays distributed throughout the passenger cabin. Generally, most system providers provide systems with individual controls since people generally desire independence in controlling programming content. However, passengers on trains, buses, theaters, and especially airplanes, tend to be captive audiences. In addition, transportation vehicles typically have varying departure times and schedules, which do not necessarily match broadcast program schedules.
Thus, a system-wide program and schedule pause feature in accordance with the present principles is especially desirable and useful.
According to one aspect of the present principles, a pause function can be implemented on, e.g., an airplane which has the capability of allowing most of the viewed content to be snapped to, e.g., a 30 minute interval so passengers can view entire programs rather than portions of programs, and so none of the desired program content is missed. This is advantageous if the plane leaves at 9:40 and a passenger wants to watch a show that started at 9:30. The passenger would miss 10 minutes without pause, or see the entire show with a 10 minute pause. Since the data is stored once, the capability of reading the data multiple times with, e.g., 5 minute start delays is also a possibility.
A system and method according to the present principles enables channel surfing for the first few minutes across all of the potential programs within the same timeframe. Since all programs are recorded, switching between stations is not a problem since every channel has been recorded at the same time, rather than just the one channel the passenger is watching at any given time. Given enough bandwidth in the memory, the system could store the data once but read it back at certain time intervals (e.g., 5-10 minute intervals) to accommodate multiple viewers requesting shows at multiple times. The system can implement a pause function to store the data and control the playback of the data.
Given a 30 minute storage time (1 Gb/s×60×30=200 GBytes) which is achievable with today's memory, the program guides can display what programs the viewer can watch in their entirety and not limit the programs available to shows already in progress. Advantageously, the program guides can be paused just like the programs to deliver a system that works together.
It is to be noted that each receiver (set top box) can be configured for local storage and allow individual user-enabled ‘local’ pause functions (e.g., to allow each user to activate a pause mode to pause content at a user-desired time). However, according to one aspect of the present principles, a ‘global’ or universal pause feature is further provided which does not require user activation and minimizes storage requirements for each set top box receiver. Note also that a global pause function (e.g., a pause function next to the tuners) as according to an aspect of the present principles advantageously allows users/viewers to change content or channels or customize viewing schedules during, e.g., a flight without encountering problems such as loss of data created with previous pauses. For example, a local pause function at each viewer's set top box would typically cause the loss of data whenever a channel change occurs after a pause has been implemented. The loss of data would be the time equal to the sum all of the pauses up to the point of channel change.
Advantageously, a system and method according to the present principles provides a streamlined and efficient manner in which to enable viewers to customize a program schedule to view program content at a desired start time. Further, the present system and method avoids complexity and minimizes the amount of memory needed, thus reducing costs. In one aspect, a ‘universal’ pause function is provided, in which a pause feature can be implemented at a main controller for automatically storing content from a plurality of channels in real-time. In another aspect, a customized guide is created having only non-filtered programs displayed at multiple delayed start times. Accordingly, each viewer will enjoy viewing of any video/audio programming content at a desired start time and will not miss any of the content, regardless of what channel each individual viewer was watching and without having to manually activate any controls.
Further, the passenger can be given a choice between viewing a program in real time or at a delayed time. This would be advantageous since some programs such as the news or sports might be desirable to be viewed in real time. If a passenger requests to start a program 20 minutes into the flight but everyone else started 10 minutes into the flight, it is still possible to accommodate his request since the data exists in memory.
One method to help reduce the bandwidth required to, e.g., read the data from memory from two different places while still storing new data, is to preselect the programs that are to be saved. Since data, for example, can be received from the satellites, the capability exists to screen the packets in real time to determine if they should be saved or filtered. This reduction in data allows new services such as providing multiple delayed starts of the same program or offering, e.g., a 30 minute program every 30 minutes which was only available every 6 hours via satellite.
Referring now to the Figures,
A filtration module 104 is provided for performing, e.g., at least steps 807, 809, 811, namely filtering out undesired program data streams and saving the desired streams, preferably up to the limit of the system bandwidth for reading the streams. If an optional separate packet processor is used for saving popular streams, the most popular or desirable programs are saved in a separate memory in the separate packet processor.
A guide module 106 is provided for perform, e.g., at least steps 813 and 815 of
The modules 102, 104 and 106 can alternatively be stored in a memory 211 of the packet processor 103.
Each packet processor 103 is connected to a main controller 205, which itself is connected to and controlled by a switch 207. The switch 207 can comprise, e.g., an 8 port 1000base T switch and can be configured for controlling signal output to any number or grouping of seats 209 (e.g., a plurality of seating ‘zones’). For example, switch 107 can be configured for distributing signals to a plurality of zones, each zone including a set top box (STB) receiver which can be functionally connected to a plurality of seat monitors. Any number of seats per STB receiver can be contemplated. For example, each STB can be connected to each other via a ‘daisy chain’ wiring scheme (electrical bus) configuration.
The processor 103 can include a capture/input module 203, a memory 211 and an output module 204 each in functional communication with one another. The capture module 203 and output module 204 can include a plurality of buffers 213 (not shown in module 204), which can preferably comprise, e.g., first-in-first-out (FIFO) buffers configured to process data such that the first data to be added to the queue is the first data to be removed, and processing proceeds sequentially in the same order. It is noted that the buffers 213 can also be included in the output control 217 of module 204.
The memory 211 can comprise any memory device, such as a hard disk drive (HDD), and/or preferably a non-volatile, solid-state memory device such as flash memory, which can be a more durable, efficient and suitable storage media, especially in high-altitude environments where air pressure might fluctuate, such as in airplane cabins. Since the majority of interruption periods, e.g., during a flight, can comprise announcements lasting only a minute or two, a minimum amount of memory is needed to cover a minimal system. Preferably, the memory 211 has storage capacity of, e.g., at least about 45 Mb/s for each transponder (an exemplary system setup can comprise, e.g., 32 tuners tracking 32 transponders).
Incoming data transport streams are input from tuners 201 to the buffers 213 for processing by the input module 203. The input module 203 can include an input controller 215, which itself can comprise at least a system control 311, an incoming timestamp counter 313, and an outgoing timestamp counter 315. The incoming timestamp counter 313 adds marker values/timestamps to incoming packets to register and acknowledge when packets are received and to improve data flow. For example, the incoming timestamp counter 313 is configured for marking when each incoming packet arrives from the tuner (e.g., by applying a time-based marker value to each incoming packet) and the outgoing timestamp counter 315 provides time-based marker values for each outgoing packet.
For example, as incoming serial packets are received they are byte aligned (step 303), and if it is determined that there is a new packet start, a timestamp is added (step 309), preferably to the packet header (step 305). In addition, step 309 can include flagging the packet with an extra ‘start bit’ to show when a packet begins. An exemplary timestamp can comprise, e.g., a 16 bit counter with a known clock reference that can be reset, programmed, or pre-loaded by the system controller. For example, a time reference about equal to ½ of the minimum single packet delivery time (˜16 to 18 μs) can be used as the time stamp clock reference.
For example: Consider a 27 MHz clock reference that takes 1/27,000,000=37 ns per bit. Packets of 130 bytes*8 bits/byte=1040 bits. 37 ns*1040=38.5 μs per packet.
It is desirable to mark packets at least within one packet time so let's pick ½ of a packet time which is ˜19 us so the frequency would be 1/19 us=˜53 KHz. As an estimate, we use 2^10=1024 bits and took half of this as 512 which is 2^9. Therefore:
Clock reference/(bits/packet)/2=27 MHz/130*8/2=27 MHz/520=˜52 KHz
Note that the addition of timestamps can result in the addition of extra data to each packet. For example, whenever a start bit is found, two bytes of timestamp data can be added to the packet header. The time-stamped packets are then sent to the buffer 213 (step 307) and on to the memory 211 for storage. As an example, an unstamped packet can comprise 130 bytes versus a time-stamped packet at 132 bytes.
Preferably, the software (e.g., processor 103) can build and store a navigation table/register using set intervals of time to contemporaneously record the IN_timestamp and the memory address in memory 211 where this data starts. This register can be used to keep track of where data is found in memory 211 with respect to its timestamp. Advantageously, this would enable very quick access to the desired data once a known delay or pause period is defined.
The outgoing timestamp counter 315 provides the output timestamps. Note that the OUT_timestamp counter 315 can be analogous in configuration and operation to the IN_timestamp counter 313. The outgoing timestamp counter 315 can use the same type of counter and same clock reference as the input timestamp counter 313 but the specific outgoing timestamp value will typically be equal or less than the incoming timestamp counter. This is because the outgoing counter 315 provides the timestamp for the memory access that represents the time that the viewer is watching. When a global pause occurs (pause mode/period begins), the outgoing counter 315 is stopped until the pause period is ended. This pause in the counting means the outgoing count/marker value normally is lower than the incoming count value. The outgoing counter reference with a lower value than the input counter reference indicates that the value is further back in time, which tracks the location of the start of the pause feature in the time domain.
The outgoing counter 315 is configured to be able to be reset, programmed, and/or pre-loaded by the system controller 311. Both counters 313, 315 are cleared at the start of the video service and begin counting, e.g., by setting both count enables high. The IN_timestamp counter 313 is constantly counting/marking incoming packets independent of any pause mode (i.e., regardless of whether the system is in a pause mode or non-pause mode) since it provides the timestamp/marker value for incoming data. The OUT_timestamp counter 315 also counts and follows the IN_timestamp counter 313, but stops incrementing/counting whenever a global pause mode is enabled.
A system and method according to the present principles provides a processor 103 configured to constantly watch and check for activation/triggering of a global pause signal 310. If a global pause signal 310 occurs, thus enabling a global pause mode, the input system control 311 stops the OUT_timestamp counter 315 from ‘incrementing’ (e.g., marking with further successive time-based marker values) for the duration of the global pause period/mode. One primary difference between the use of the counters 313, 315 is the offset in the OUT_timestamp counter 315 that is used to provide a real time output reference for the stored data. That is, when a pause period is over, the output timestamp counter 315 is referenced by an output program in the output controller 217 to find the corresponding input timestamp bytes that were captured when the packets arrived from the input counter 313. This output counter reference can comprise, e.g., the input timestamp counter minus the number of counts that represent the equivalent delay of the pause period. In one exemplary embodiment, the number of counts of the pause period can be programmed into the output counter 315 by the input system control 311.
Advantageously, by stopping the output counter 315 from incrementing during the pause period, the dataflow operation becomes automatic without requiring controller intervention. The system controller 311 could also read the output counter and then could add or subtract values from the OUT_timestamp counter 315 if repeated data or skipped data is desired. The output will then start counting again to provide the appropriate output timestamp reference until the next pause mode occurs. Note that if the output counter stops incrementing, the output data also stops since all of the incoming data timestamps are greater than the value being looked for.
For example, in the timeline shown below (Example 1) depicting an exemplary period of 20 minutes of streaming data content, a 5 minute pause period occurs starting from minute 10 to minute 15. While the data input continues to be written throughout the entire 20 minutes, at 10 minutes, the data output (reading) is stopped and the outgoing timestamp counter/marker value is noted. When the pause period is over at minute 15, the output counter searches for the output timestamp counter value (minute 10) in the input timestamped data to resume playback starting from minute 10. Note that after the pause, the next packet of data output would be the one following the last packet sent before the pause. The primary purpose of the timestamp counters is to ensure that the original transmission bitrate is maintained to avoid MPEG buffer overflows or underflows.
The input controller 215 is configured for both writing and reading the streaming data to or from memory 211. Details of the read and write operations and signals of the memory controller and interfaces are well known in the art and are not shown in
The output module 204 can include at least an output controller 217 which can comprise at least an output system control 513, state machine 515, a buffer 505, and an output circuit 219. The output system control 513 can include a comparator module 513 configured to check the incoming timestamps 517 of the data coming from memory 211 versus the desired timestamp to ensure that the bit buffers downstream do not overflow during the MPEG processing. As described above, for example, an additional bit in the FIFO can be used to flag the beginning of every packet to help count bytes as well as flag the timestamp in each packet.
In one exemplary embodiment, as shown in
In the embodiment of
In one embodiment, each packet processor 103 can include a delay/pause partition module for each tuner 201 so that when the data is played back, the system downstream can react the same. That is, each pause partition module can be found in a corresponding packet processor(s) 103. The partition module can be embodied in the memory 211 and enables individual storage of each tuner's output in a corresponding separate packet in the memory 211.
If all tuners are combined in the memory, then all tuners have channels with timestamps that could be equal. E.g., 8 or 16 tuners have 8 or 16 channels with timestamps that could be equal. If all of the tuners are combined into a common stream to the flash and/or HDD then extra data needs to be added to identify which packet came from which tuner. This would be done in the packet processor 103. There could be one packet processor per tuner or one packet processor per system serving N number of tuners.
In an embodiment using partitions, keeping the transport streams separated in the flash/HDD (e.g., via the pause partitions) advantageously simplifies the system and can be implemented by storing one tuner's output in its own packet on the memory (flash/HDD), storing the next tuner's output in another packet, and so on. Advantageously, in this embodiment the only difference is the packet management and not the bandwidth utilized for a defined system. The final architecture would be chosen based on bandwidth requirements versus the cost of the overhead for each additional packet processor.
A global pause control signal 310 can be provided and a pause function can accordingly be activated. According to one aspect, the packet processor 103 is configured to constantly check for activation of the global pause signal 310 during data delivery, and activate the global pause mode in response to triggering of the signal 310. Triggering/activation events for the global pause signal 310 can comprise, e.g., manual activation of a global pause button, or an automated activation.
In one embodiment, a multiplexer can be added (e.g., see 223 in
The system will not read the next packet of data from the FIFO until the system controller/comparator 513 compares the OUT-timestamp 319 with the IN-timestamp 517. In this example, when the start flag is equal to ‘1’ and the OUT and IN-timestamps are equal values, the next packet is read. Advantageously, this re-creates the original bit-rates found when the data was initially received, which avoids overflow of the MPEG buffers downstream. Once the values are equal, the state machine 515 will enable the read for an entire packet. The state machine 515 will stop the data flow again until the IN_timestamp 517 (e.g., found in the header data stored in the flash memory) is less than or equal to the OUT_timestamp 319.
An exemplary method for providing a global system pause function in an broadcast television system can be described as follows. While the system is waiting to be enabled (e.g., for the television service to be activated or on), the packet processor sets both incoming and outgoing timestamp counters equal and watches for a pause or interruption period to occur.
If a pause occurs, a pause mode is enabled and the outgoing timestamps (OT) are stored. During the pause mode a reference table is preferably created showing, e.g., incoming (IT) timestamps, tuner data, and start and end flash/HDD storage locations. The incoming data stream is preferably stored in the memory 211. In one exemplary embodiment, each user set top box (STB) can receive a message to indicate a pause mode, e.g., each STB can receive another data stream with a still picture, on-screen display (OSD), or a picture freeze with overlay to indicate a pause mode. During the pause mode, the system constantly checks to see whether the pause has ended. If the pause is stopped/ended, the timecodes (e.g., counter/marker value) and end address corresponding to the pause stop time are stored.
At a ‘pause end’, the OT counter is programmed with the pause_start location and data is streamed from the memory 211 to each set top box (receiver). That is, the navigation table is referenced to find the starting address for the IT timecode/marker value equal to the pause_start location, and the data is then read from the memory 211 between the start and end addresses. For example, if the pause has ended, the processor looks up pause_start=OT location in the stored IT table to get memory address location for data beginning at the pause_start. The next HDD read is found as the next table entry, and so on.
The streaming is continued using the OT as the timestamp reference while the incoming data is marked with the IT counter. If another pause occurs, the OT register value at pause_start is stored and a pause mode is entered again until the pause mode ends. The above steps will continue until a pause is encountered again or the TV service is ended.
Advantageously, playing back content that is regulated by the timestamps/marker values ensures that the original transport bit rates are being reconstructed on the output data from the memory 211. These original bit rates were carefully constructed at the transmitters to be sure that the MPEG bit buffers will not overflow or underflow during the decoding of the transport streams. This is also why the use of solid state flash can be advantageous over HDD magnetic disc drives in the present application since the HDDs can have large variations in the access times for reading and writing data while flash drives do not.
The primary filtered programs 606 are input to the pause-enabled packet processor 103 for processing e.g., as described above with respect to
A second main control 607 is provided functionally connected to the pause packet processor 103 and includes a user-customized filtration module 705 for performing a secondary filtering process, e.g., for further filtering the primary filtered programs 606 in accordance with viewer requests to eliminate programs that the passengers/viewers do not wish to control or are unlikely to view. This results in an even further reduction in the overall amount of data to be output to the viewers. For example, as shown in
As shown in
The stored programs of processor 103 can be paused for a certain time interval, which can be dependent on the limits of the system memory and bandwidth, for example, as shown here a 10 minute delay can be provided for all its stored programs. Since the popular stream processor 701 typically processes a much reduced amount of data streams, multiple delayed starts 703 can be provided in which a single ‘popular’ program can be viewed at multiple start times, e.g., with a 10 minute delay, a 15 minute delay, a 20 minute delay, etc. The amount of time delay (pause buffer) which can be provided for each program depends on the total amount of memory available.
In addition, the popular stream processor 701 can be configured to offer a program at more frequent viewing times. For example, where a 30 minute program was offered only every 6 hours on live satellite television, the system and method according to the present principles can offer it at more frequent intervals, such as every 30 minutes.
In step 801 the program guide data is acquired and analyzed. For example, the following information can be determined from the guide:
In step 803, check if multiple streams for the same program title are transmitted, e.g., such as standard definition (SD) as well as high definition (HD). If so, filter the HD streams in situations where the passengers are provided with only an SD display.
In step 805, consider the size of the pause buffer and review the program guide considering the pause function. Re-run the guide to accommodate the pause as well as any multiple time-delayed start content.
In step 807, the programs are filtered to save only the desired data streams up to the limit of the system bandwidth for reading the streams. Preferably, only the programs that have a chance to be selected and watched by the passenger or the service provider are saved.
In step 809 it is assessed whether a separate popular stream packet processor is being employed. If yes, the most popular programs are saved in the memory of the popular stream processor to allow enough bandwidth for, e.g., multiple reads and one write (step 811). Multiple time-delayed start times can be created for popular programs, if applicable, and/or multiple listings showing real-time vs. delayed time for each program (step 813). In this way, a revised or updated program guide can be created. In step 815, a program guide from which the viewer can select only the non-filtered programs (at any desired start time which is offered) is created. In step 817, the desired data streams saved, e.g., in a global memory, can be further filtered in accordance with viewer requests, to send the desired program to each viewer.
If at step 809 it is determined that a popular stream processor is not being used, the method proceeds directly to step 813.
Although the embodiment which incorporates the teachings of the present principles has been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings. Having described preferred embodiments for a system and method for providing a global schedule system pause function for broadcast multimedia programming (Which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes can be made in the particular embodiments of the principles disclosed which are within the scope and spirit of the inventive principles as outlined by the appended claims. Having thus described the invention with the details and particularity required by the patent laws, what is claimed and desired protected by Letters Patent is set forth in the appended claims.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2008/012456 | 11/4/2008 | WO | 00 | 8/20/2010 |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2010/053465 | 5/14/2010 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 4646280 | Toyosawa | Feb 1987 | A |
| 5357250 | Healey et al. | Oct 1994 | A |
| 5418863 | Ando | May 1995 | A |
| 5596647 | Wakai et al. | Jan 1997 | A |
| 5801786 | Song | Sep 1998 | A |
| 5854591 | Atkinson | Dec 1998 | A |
| 5896129 | Murphy et al. | Apr 1999 | A |
| 5956094 | Chun | Sep 1999 | A |
| 5973722 | Wakai et al. | Oct 1999 | A |
| 5995553 | Crandall et al. | Nov 1999 | A |
| 6014381 | Troxel et al. | Jan 2000 | A |
| 6052384 | Huang et al. | Apr 2000 | A |
| 6058288 | Reed et al. | May 2000 | A |
| 6249913 | Galipeau et al. | Jun 2001 | B1 |
| 6262737 | Li et al. | Jul 2001 | B1 |
| 6278375 | Hucker | Aug 2001 | B1 |
| 6323767 | Gropper | Nov 2001 | B1 |
| 6363207 | Duruoz et al. | Mar 2002 | B1 |
| 6377188 | Maruyama | Apr 2002 | B1 |
| 6393343 | Frey et al. | May 2002 | B1 |
| 6463273 | Day | Oct 2002 | B1 |
| 6539548 | Hendricks et al. | Mar 2003 | B1 |
| 6559812 | McCarten et al. | May 2003 | B1 |
| 6728269 | Godwin et al. | Apr 2004 | B1 |
| 6744967 | Kaminski et al. | Jun 2004 | B2 |
| 6745021 | Stevens | Jun 2004 | B1 |
| 6762733 | Smith et al. | Jul 2004 | B2 |
| 6813777 | Weinberger et al. | Nov 2004 | B1 |
| 6938258 | Weinberger et al. | Aug 2005 | B1 |
| 6978424 | Safadi | Dec 2005 | B2 |
| 7003052 | Koike et al. | Feb 2006 | B2 |
| 7028304 | Weinberger et al. | Apr 2006 | B1 |
| 7075945 | Arsenault et al. | Jul 2006 | B2 |
| 7114171 | Brady, Jr. et al. | Sep 2006 | B2 |
| 7130724 | Petersen et al. | Oct 2006 | B2 |
| 7159230 | Manson et al. | Jan 2007 | B2 |
| 7159231 | Clark | Jan 2007 | B1 |
| 7167639 | Haddad et al. | Jan 2007 | B2 |
| 7174085 | Demas et al. | Feb 2007 | B2 |
| 7177522 | MacInnis | Feb 2007 | B2 |
| 7194611 | Bear et al. | Mar 2007 | B2 |
| 7197234 | Chatterton | Mar 2007 | B1 |
| 7200859 | Perlman et al. | Apr 2007 | B1 |
| 7230652 | Demas et al. | Jun 2007 | B2 |
| 7257308 | Plourde, Jr. et al. | Aug 2007 | B2 |
| 7260312 | Srinivasan et al. | Aug 2007 | B2 |
| 7272298 | Lang et al. | Sep 2007 | B1 |
| 7272300 | Srinivasan et al. | Sep 2007 | B2 |
| 7292604 | Godwin et al. | Nov 2007 | B2 |
| 7409140 | Rodriguez et al. | Aug 2008 | B2 |
| 7565104 | Brown et al. | Jul 2009 | B1 |
| 7640566 | Taylor et al. | Dec 2009 | B1 |
| 20020118951 | Suzuki et al. | Aug 2002 | A1 |
| 20020152470 | Hammond | Oct 2002 | A1 |
| 20020177996 | Cooper et al. | Nov 2002 | A1 |
| 20030025599 | Monroe | Feb 2003 | A1 |
| 20030037331 | Lee | Feb 2003 | A1 |
| 20030084451 | Pierzga et al. | May 2003 | A1 |
| 20030093798 | Rogerson | May 2003 | A1 |
| 20030094659 | Goldman | May 2003 | A1 |
| 20030114107 | Aoyagi | Jun 2003 | A1 |
| 20030208764 | Galipeau et al. | Nov 2003 | A1 |
| 20040136408 | Tomobe et al. | Jul 2004 | A1 |
| 20040155961 | Litwin, Jr. et al. | Aug 2004 | A1 |
| 20050117583 | Uchida et al. | Jun 2005 | A1 |
| 20050135787 | Yoo et al. | Jun 2005 | A1 |
| 20050138659 | Boccon-Gibod et al. | Jun 2005 | A1 |
| 20050201629 | Karczewicz et al. | Sep 2005 | A1 |
| 20060020992 | Pugel et al. | Jan 2006 | A1 |
| 20060029359 | Shigehara et al. | Feb 2006 | A1 |
| 20060136965 | Ellis et al. | Jun 2006 | A1 |
| 20060224761 | Howarth et al. | Oct 2006 | A1 |
| 20060257099 | Potrebic et al. | Nov 2006 | A1 |
| 20060275022 | Perlman et al. | Dec 2006 | A1 |
| 20060275023 | Perlman et al. | Dec 2006 | A1 |
| 20060277316 | Wang et al. | Dec 2006 | A1 |
| 20070011343 | Davis et al. | Jan 2007 | A1 |
| 20070021099 | Sato | Jan 2007 | A1 |
| 20070065122 | Chatterton | Mar 2007 | A1 |
| 20070086488 | Kim et al. | Apr 2007 | A1 |
| 20070092078 | Yoshida et al. | Apr 2007 | A1 |
| 20070107019 | Romano et al. | May 2007 | A1 |
| 20070127887 | Yap et al. | Jun 2007 | A1 |
| 20070127891 | Demas et al. | Jun 2007 | A1 |
| 20070130597 | Parker et al. | Jun 2007 | A1 |
| 20070136743 | Hasek et al. | Jun 2007 | A1 |
| 20070143809 | Chen et al. | Jun 2007 | A1 |
| 20070143813 | Chen et al. | Jun 2007 | A1 |
| 20070162392 | McEnroe et al. | Jul 2007 | A1 |
| 20070166001 | Barton et al. | Jul 2007 | A1 |
| 20070168188 | Choi | Jul 2007 | A1 |
| 20070180465 | Ou et al. | Aug 2007 | A1 |
| 20070192613 | Amoroso et al. | Aug 2007 | A1 |
| 20090320075 | Marko | Dec 2009 | A1 |
| 20110007745 | Schultz et al. | Jan 2011 | A1 |
| 20110307548 | Fisk et al. | Dec 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 1717024 | Jan 2006 | CN |
| 1902697 | Jan 2007 | CN |
| 1909696 | Feb 2007 | CN |
| 0813341 | Dec 1997 | EP |
| 0907281 | Apr 1999 | EP |
| 1175091 | Jan 2002 | EP |
| 1283639 | Feb 2003 | EP |
| 1594317 | Nov 2005 | EP |
| 1739676 | Jan 2007 | EP |
| 1781034 | May 2007 | EP |
| 01288190 | Nov 1989 | JP |
| 578043 | Oct 1993 | JP |
| 7130150 | May 1995 | JP |
| 2001008200 | Jan 2001 | JP |
| 2001054066 | Feb 2001 | JP |
| 2001160940 | Jun 2001 | JP |
| 2002112199 | Apr 2002 | JP |
| 2002135729 | May 2002 | JP |
| 2002269910 | Sep 2002 | JP |
| 2003163892 | Jun 2003 | JP |
| 200423591 | Jan 2004 | JP |
| 2004248138 | Sep 2004 | JP |
| 2004282644 | Oct 2004 | JP |
| 2005184519 | Jul 2005 | JP |
| 2005244404 | Sep 2005 | JP |
| 2005310365 | Nov 2005 | JP |
| 2005318049 | Nov 2005 | JP |
| 2005535170 | Nov 2005 | JP |
| 200623748 | Jan 2006 | JP |
| 2006109301 | Apr 2006 | JP |
| 2006186580 | Jul 2006 | JP |
| 2006246297 | Sep 2006 | JP |
| 200753738 | Mar 2007 | JP |
| 2007158432 | Jun 2007 | JP |
| 2008005085 | Jan 2008 | JP |
| 2008193295 | Aug 2008 | JP |
| 2008539638 | Nov 2008 | JP |
| WO9843376 | Oct 1998 | WO |
| WO0072592 | Nov 2000 | WO |
| WO0271756 | Sep 2002 | WO |
| WO03019932 | Mar 2003 | WO |
| WO03024085 | Mar 2003 | WO |
| WO03032620 | Apr 2003 | WO |
| WO03067594 | Aug 2003 | WO |
| WO03075574 | Sep 2003 | WO |
| WO03092281 | Nov 2003 | WO |
| WO2004034707 | Apr 2004 | WO |
| WO2005045830 | May 2005 | WO |
| WO2006114759 | Nov 2006 | WO |
| WO2007036833 | Apr 2007 | WO |
| WO2007038131 | Apr 2007 | WO |
| WO2007056108 | May 2007 | WO |
| WO2007063430 | Jun 2007 | WO |
| WO2007076042 | Jul 2007 | WO |
| WO2008026187 | Mar 2008 | WO |
| WO2009117050 | Sep 2009 | WO |
| Entry |
|---|
| European Search Report dated Dec. 10, 2009. |
| Business Wire, “AMD Powers Up AMD Live!(TM) Horne Media Server Introducing Easy, Universal.Control of a Home Network”, Nov. 5, 2007. |
| AT&T, AT&T Introduces U-Verse in Austin, Business Wire, Nov. 8, 2007. |
| Monsoon, “HAVA Video Streaming and Place-Shifting Devices”, Press Release, Nov. 7, 2007. |
| Number | Date | Country | |
|---|---|---|---|
| 20110004901 A1 | Jan 2011 | US |
