HK1131301A - Presentation modes for various format bit streams - Google Patents

Description

Presentation mode for various format bitstreams

Cross Reference to Related Applications

The benefit of U.S. provisional patent application serial No. 60/812,197 entitled "detection models FOR variance problem form BIT STREAMS", filed 2006, 6, 9, 35u.s.c. § 119(e) by Hanno base et al, which is incorporated herein by reference.

Technical Field

The present invention relates generally to satellite signal delivery systems and, in particular, to the presentation of bit streams of various formats within a satellite signal delivery system.

Background

Satellite broadcasting of communication signals has become commonplace. Satellite distribution of commercial signals for television programs currently utilizes multiple feedhorns on a single outdoor unit (ODU) that provide signals to up to 8 IRDs on different cables from a multiswitch.

Fig. 1 shows a typical satellite television system of the related art.

Fig. 1 shows a communication system, in particular a television broadcast system 100 for transmitting and receiving audio, video and data signals via satellite. Although the present invention is described in the context of a satellite-based television broadcast system, the techniques described herein are equally applicable to other program content delivery methods, such as air-to-ground systems, cable-based systems, and the internet. In addition, although the present invention is described primarily with respect to television content (i.e., audio and video content), the present invention may be implemented with a variety of program content material, including video content, audio and video related content (e.g., television viewer channels), or data content (e.g., computer data).

Television broadcast system 100 includes a transmitting station 102, an uplink dish 104, at least one satellite 106, and receiver stations 108A-108C (collectively receiver stations 108). The transmitting station 102 includes a plurality of inputs 110 for receiving various signals such as analog television signals, digital television signals, video cassette signals, original program signals, and computer-generated signals containing HTML content. In addition, input 110 receives signals from a digital video server having a hard disk or other digital storage medium. The transmitting station 102 also includes a plurality of timing inputs 112 that provide electronic schedule information regarding timing and various television channel content, such as those commonly found in television program schedules contained in newspapers and television guides. The transmitting station 102 converts the data from the timing input 112 into program guide data. Program guide data may also be manually entered at the transmitting station 102 side. The program guide data is composed of a plurality of "objects". The program guide data object includes data used to construct an electronic program guide that is ultimately displayed on the user's television.

Transmitting station 102 receives and processes the various input signals received on input 110 and timing input 112, converts the received signals into a standard form, combines the standard signals into a single output data stream 114, and continuously sends output data stream 114 to uplink dish 104. The output data stream 114 is a digital data stream that is compressed, typically using MPEG2 encoding, although other compression schemes may be used.

The digital data in the output data stream 114 is divided into a plurality of packets, each such packet being labeled with a Service Channel Identification (SCID) number. The SCIDs may be used by receivers in receiver station 108 to identify packets corresponding to each television channel. Error correction data is also included in the output data stream 114.

Output data stream 114 is typically a multiplexed signal modulated by transmitting station 102 using standard frequency and polarization modulation techniques. The output data stream 114 preferably comprises a plurality of frequency bands, typically 16 frequency bands, each band being left polarized or right polarized. Alternatively, vertical and horizontal polarizations may be used.

Uplink dish 104 continuously receives an output data stream 114 from transmitting station 102, amplifies the received signal, and transmits a signal 116 to at least one satellite 106. Although fig. 1 shows a single uplink dish 104 and three satellites 106, it may be preferable to use multiple uplink dishes 104 and a large number of satellites 106 to provide additional bandwidth and to help ensure continuous delivery of signals 114 to receiver stations 108.

The satellite 106 rotates on a geosynchronous orbit of the earth. Each satellite 106 includes a plurality of transponders that receive signals 116 transmitted by uplink dish 104, amplify the received signals 116, frequency shift the received signals 116 to different frequency bands, and then transmit the amplified frequency-shifted signals 118 back to a desired geographic area on earth where receiver stations 108 are located or will be located at some future time. The receiver station 108 then receives and processes the signals 118 transmitted by the satellites 106.

Each satellite 106 typically broadcasts signals 118 at thirty-two (32) different frequencies that are licensed to individual users for the broadcast of programs, which may be audio, video, or data signals, or any combination. These signals are typically located in the Ku band, i.e., 11-18GHz, but may be broadcast in the Ka band, i.e., 18-40GHz, more typically in the range of 20-30GHz, or other frequency bands.

Fig. 2 is a block diagram of a receiver station 108 that receives and decodes audio, video, and data signals. Typically, the receiver station 108 is a "set-top box," also known as an Integrated Receiver Decoder (IRD), which typically resides in a home or multi-dwelling unit and is used to receive satellite broadcast television signals 118.

Receiver dish 200 may be an outdoor unit (ODU), which is typically a smaller dish mounted on a home or multi-dwelling unit. However, the receiver dish 200 may also be a larger antenna dish mounted on the ground, if desired.

Receiver dish 200 typically uses a reflector dish and feed horn assembly to receive downlink signal 118 and direct it to receiver station 108 via a wire or coaxial cable. Each receiver station has a dedicated cable that allows the receiver dish 200 to selectively direct the downlink signals 118 to the receiver station 108 via a multi-way switch and allows the receiver station 108 to determine which of the signals 118 is desired.

Receiver station 108 includes a receiver dish 200, an alternate content source 202, a receiver 204, a monitor 206, a recording device 208, a remote control 210, and an access card 212. Receiver 204 includes tuner 214/demodulator/Forward Error Correction (FEC) decoder 216, digital-to-analog (D/a) converter 218, CPU220, clock 222, memory 224, logic 226, interface 228, Infrared (IR) receiver 230, and access card interface 232. The receiver dish 200 receives the signal 118 transmitted by the satellite 106, amplifies the signal 118, and passes the signal 118 to a tuner 214. The tuner 214 and demodulator/FEC decoder 216 operate under the control of the CPU 220.

CPU220 operates under the control of an operating system stored within memory 224 or within secondary memory within CPU 220. The functions performed by CPU220 are controlled by one or more control programs or application programs stored in memory 224. The operating system and application programs are comprised of instructions that, when read and executed by CPU220, cause receiver 204 to perform the necessary functions and steps to implement and/or use the present invention, typically by accessing and manipulating data stored in memory 224. The instructions to implement these applications are tangibly embodied in a computer-readable medium, such as memory 224 or access card 212. CPU220 also communicates with other devices through interface 228 or receiver dish 200 to receive commands or instructions to be stored in memory 224 to form a computer program product or article of manufacture in accordance with the present invention. As such, the terms "article of manufacture," "program storage device" and "computer program product" as used herein are intended to encompass any application accessible by CPU220 from any computer-readable device or media.

Memory 224 and access card 212 store various parameters of receiver 204, such as a list of channels authorized for receiver 204 to process and generate displays; the zip code and area code of the area in which the receiver 204 is used; the model name or number of the receiver 204; a serial number of the receiver 204; the serial number of the access card 212; the name, address, phone number of the owner of the receiver 204; and the manufacturer name of the receiver 204.

The access card 212 may be removed from the receiver 204 (as shown in figure 2). When inserted into the receiver 204, the access card 212 is connected to an access card interface 232, and the access card interface 232 communicates with a customer service center (not shown) through the interface 228. The access card 212 receives access authorization information from the customer service center based on the user's specific account information. In addition, the access card 212 communicates with the customer service center regarding billing and ordering of services.

Clock 222 provides CPU220 with the current local time. Interface 228 is preferably connected to a telephone jack 234 at receiver station 108. As shown in fig. 1, interface 228 allows receiver 204 to communicate with transmitting station 102 through telephone jack 234. The interface 228 may also be used to transfer data to and from a network, such as the internet.

The signal transmitted from receiver dish 200 to tuner 214 is a plurality of modulated Radio Frequency (RF) signals. The desired RF signal is then down-converted to baseband by tuner 214, tuner 214 also producing in-phase and quadrature-phase (I and Q) signals. These two signals are then passed to a demodulator/FEC Application Specific Integrated Circuit (ASIC) 216. The demodulator 216ASIC then demodulates the I and Q signals and the FEC decoder correctly identifies each transmitted symbol. A received symbol of Quadrature Phase Shift Keying (QPSK) or 8PSK signal carries 2 or 3 data bits, respectively. The corrected symbols are converted to data bits, which are in turn assembled into payload data bytes and finally into packets. A data packet may carry 130 data bytes or 188 bytes (187 data bytes and 1 sync byte).

In addition to the digital satellite signals received by the receiver dish 200, other sources of television content are preferably used. For example, the alternate content source 202 provides additional television content to the monitor 206. The alternate content source 202 is connected to a tuner 214. The alternate content source 202 may be an antenna for receiving wireless signals, National Television Standards Committee (NTSC) signals, a cable for receiving American Television Standards Committee (ATSC) signals, or other content source. Although only one alternate content source 202 is shown, multiple sources may be used. Initially, when data enters the receiver 204, the CPU220 looks for initialization data, which is commonly referred to in the industry as a boot object. The guide object identifies the SCIDs where all other program guide objects can be found. The boot object is always sent through the same SCID, so CPU220 knows that it must look for packets marked by that SCID. CPU220 uses the information from the boot object to identify packets of program guide data and route them to memory 224.

The remote control 210 transmits an Infrared (IR) signal 236 that is received by an infrared receiver 230 in the receiver 204. Alternatively, other types of data entry devices may be used, such as, by way of example and not limitation, an Ultra High Frequency (UHF) remote control, a keyboard on the receiver 204, a remote keyboard, and a remote mouse. When a user requests display of a program guide by pressing the "guide" button on remote control 210, IR receiver 230 receives the guide request signal and passes it to logic 226. Logic circuitry 226 informs CPU220 of the guidance request. In response to the guide request, CPU220 causes memory 224 to transfer the program guide digital image to D/a converter 218. D/a converter 218 converts the program guide digital image to a standard analog television signal, which is then transmitted to monitor 206. The monitor 206 then displays the TV video and audio signals. Alternatively, monitor 206 may be a digital television, in which case digital-to-analog conversion in receiver 204 is not required.

The user interacts with the electronic program guide using remote control 210. Examples of user interactions include selecting a particular channel or requesting additional guide information. When a user selects a channel using remote control 210, IR receiver 230 communicates the user's selection to logic 226, logic 226 communicates the selection to memory 224, and CPU220 accesses the selection at memory 224. The CPU220 performs MPEG2 decoding on the audio, video, and other packets received from the FEC decoder 216 and outputs the audio and video signals of the selected channel to the D/a converter 218. The D/a converter 218 converts the digital signal into an analog signal, and outputs the analog signal to the monitor 206.

As the number of satellites 106 increases, the number of program selections increases. In addition, when a user adds additional television monitors 206 to the home, in the related art system 200, each monitor 206 requires a dedicated cable from the receiver 204 to the receiver dish 200 for control and delivery of the downlink signal 118. This creates difficulties for the user in laying out additional cables and adding potentially unnecessary receiver 204 hardware in a given receiver station 108 device.

It can be seen that there is a need in the art for a more intelligent satellite data delivery system.

Disclosure of Invention

To minimize the limitations in the prior art, and to minimize other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a system and method for displaying various mode bitstreams.

The system according to the invention comprises an antenna, a server receiver connected to the antenna, and at least one client receiver connected to the server receiver, wherein the client receiver sends commands to the antenna and receives signals from the antenna through the server receiver.

Other features and advantages are inherent in the systems and methods as set forth and disclosed, or will become apparent to those skilled in the art from the following detailed description and the accompanying drawings thereof.

Drawings

Referring now to the drawings in which like reference numbers represent corresponding parts throughout:

fig. 1 shows a typical satellite system of the related art;

fig. 2 shows a typical receiver of the related art;

FIG. 3 shows a system diagram of the present invention;

FIG. 4 shows a block diagram of services provided by the home media center of the present invention; and

fig. 5-7 illustrate system processes performed by the present invention for managing resource requests and reservations.

Detailed Description

In the following description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration several embodiments of the invention. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

Overview of the System

Figure 3 shows a system diagram of the present invention.

In the present invention, the ODU108 is connected to a Frequency Translation Module (FTM) 300. FTM300 is connected to server IRDs 304 through cables 302. FTM300 is also connected to legacy IRDs 112 through cables 124, although legacy IRDs 112 may alternatively be connected to server IRDs 304 through cables 306. Server IRD308 is also connected to client IRD310 by cable 308. There may be more than one server IRD308 at a given location, if desired. One or more server IRDs 304 are also referred to as "home media centers" (HMCs) 312.

The HMC312 serves as a central location for the logging, publishing and scheduling of the tasks and system resources of the present invention. Based on client IRD310 requests sent over cable 308 to HMC312, HMC312 allocates resources to client IRD310 as needed.

Client IRD308 makes requests to HMC312 to record events, view specific channels, and other system resources. HMC312 handles all requests from all client IRDs 310 and any legacy IRDs 112 and either satisfies the request or notifies users of a given IRD310 that the request cannot be satisfied. For example, if a user of given client IRD310 wishes to record a program, and HMC312 is using a Digital Video Recorder (DVR) for another purpose, HMC312 will notify the user of given client IRD310 that the DVR is not available at the current time. The HMC312 can also provide the user with options to assist in satisfying the request, such as informing the user when the DVR is available, what the DVR is recording, so the user can choose to override the current DVR usage, or allow the user to make other resource allocations to allow the current request to be satisfied.

Bidirectional communication between HMC312 and client IRDs 310 occurs via cable 308 or via other lines, such as a power distribution line or a telephone line, present in premises 110.

SUMMARY

HMC312 allows digital video recording functionality to be provided to each TV in premises 110 without having a DVR at each client IRD 310. HMC312 includes one or more server IRDs 308 as a central hub. Server IRD308 receives and optionally records programming received from satellite signals received by ODU 108. One or more client IRDs 310 connect to HMC312 through one or more cables 308 to receive audio, video and data and display them on a television monitor.

HMC312 is a High Definition (HD) receiver based on MPEG-2 or MPEG-4 transport streams via server IRD308, in addition to other proprietary formats used for legacy IRDs 112. The HMC312 also introduces advanced modulation/coding (AMC) including Low Density Parity Check (LDPC) coding.

LDPC coding with advanced modulation is a Forward Error Correction (FEC) coding technique that is superior to conventional convolutional FEC (Reed-Solomon/Viterbi) coding schemes. LDPC coding provides a more bandwidth efficient approach to improve the bit error rate of digital signals. Advanced modulation also provides higher Phase Shift Keying (PSK) modulation. In PSK modulation, carrier signals are transmitted with different phases according to a phase mapping. With 8PSK, the number of phases is increased to 8 in order to double the amount of information carried within the same bandwidth as QPSK transmission.

The HMC312 utilizes MPEG-2 transmission formats and advanced modulation/LDPC coding and FTM300 technology to provide video, audio and data services to each monitor within the premises 110.

Advanced modulation/coding

HMC312 conditions for different satellite data streams, some using QPSK modulation and Reed-Solomon FEC, and others using FEC and other advanced modulation/coding techniques to provide the desired signal to each client IRD310 present in house 310. This requires the HMC312 to use at least two different setting or tuning parameters depending on the type of satellite stream to be decoded and used. For legacy stream types, i.e., QPSK modulated streams, the tuning parameters are network id, frequency, polarization, SCID (12 bits), modulation type, and FEC type. For advanced modulation streams, i.e., the "a 3 stream" type, the tuning parameters are network id, frequency, polarization, PID (13 bits), mode bit, symbol rate, roll-off coefficient, physical layer header unique word (PLH UW), Gold code sequence scrambler, and pilot indicator.

Comparing the two types of data streams, it can be seen that the a3 stream coding parameters are mode id, symbol rate, roll-off coefficient, physical layer header unique word, Gold code sequence scrambler, and pilot indicator. Each of these parameters is described below.

Mode id

There are a total of 28 modulation/coding modes supported by the a3 advanced demodulation and decoding method. Each of these modes changes the modulation type (i.e., QPSK or 8PSK), FEC algorithm (i.e., Reed-solomon (rs) or low density parity check/Bose, Chaudhuri, Hocquenghem (LDPC/BCH)), and the amount of FEC (i.e., 1/4, 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 6/7, 8/9, and 9/10).

Symbol rate

The symbol rate defines the bandwidth capacity of QPSK or 8PSK modulated signals. The symbol rate may have a value of 20M symbols/sec for all legacy transmission streams and 20M symbols/sec or 30M symbols/sec for all non-legacy transmission streams.

Roll off coefficient

The roll-off coefficient (α) is used to filter the signal using a baseband square root raised cosine filter. The roll-off coefficient may have values of 0.20, 0.25 and 0.35.

Physical layer header unique word

The physical layer header unique word (PLHEADER) is a 90-bit header applied to each 64,800-bit FEC frame. The PLHEADER consists of a 26 bit start of frame (SOF) and a unique 64 bit Physical Layer Signal (PLS) code. SOF was fixed at 0xl8D2E 82. The PLS code may change for each transport stream. The 90-bit PLH _ UW is exclusive OR (XOR) ed with PLHEADER. PLHEADER is not used in legacy and DVBS modes, but is used in QPSK and 8PSK advanced modes.

Gold sequence scrambler

The Gold sequence scrambler is an 18-bit value used to randomize the modulation phase (I, Q) for symbol transmission in the FEC frame. A Gold sequence scrambler is used on each FEC frame except the PLHEADER. Gold sequence scramblers are not used in the legacy and DVBS modes. Gold sequence scramblers are used only in QPSK and 8PSK advanced modes.

Pilot indicator

The pilot indicator is a 1-bit field indicating whether pilot symbols are inserted in the FEC frame. The pilot symbols facilitate carrier tracking by inserting an unmodulated grid of 36 symbols every 1440 symbols in the FEC frame. There is also a pilot-less transmission mode which has the advantage of providing an additional 2% useful capacity. Pilot symbols are not used in legacy and DVBS modes. The pilot symbols are used only in QPSK and 8PSK advanced modes.

Interaction between server and client

In the present invention, HMC312 (via server IRD308) must interact with client IRDs 310 in order to allow each client IRD310 to receive the data streams (e.g., desired television channel audio and video streams) requested at that client IRD310 as well as any other services requested by client IRDs 310. For example, a given IRD310 may send HMC312 a request to watch a particular channel, record the channel, record a program that occurs later, purchase a pay-per-view event, purchase a movie to be recorded on a DVR, and other requests. HMC312 coordinates all of these requests from all client IRDs 310 connected to HMC312 and may resolve any conflicts between requests by reporting the conflicts to the user and allowing the user to manually select system resources in order to satisfy the requests to the greatest extent possible.

Fig. 4 shows a block diagram of the services provided by the home media center of the present invention.

Several types of services are provided through the HMC 312. These services include recording services 400, playback services 402, purchase services 404, playback mode support 406 and resource management 408, and live television services 410, described with respect to fig. 4.

Recording service

Recording service 400 receives subscription and recording requests from client IRDs 310 and server IRDs 308. The logging service 400 makes a determination to log the event based on responses received from other components (e.g., resource manager 408, etc.). The recording service 400 records the reservation event and all relevant metadata by the DVR writer at a scheduled start time and for a specified duration. The recording status is reported to the playback mode support 406 for viewing by the user.

The recording service 400 allows viewers to purchase and record events. The recording service handles incoming subscription requests received locally or over a network from the home media server 308 and the home media client 310. The types of events that can be subscribed to include mandatory and optional software downloads, single (explicit) event logging, repeat event logging, opt-in logging, network schedule (push) logging, manual logging, repeat manual logging, find logging, log extension, subscribe for event deletion, and prioritization of repeat events.

The logging service 400 interfaces with the resource manager 408 to resolve scheduling conflicts for requested events. The recording service 400 interfaces with a resource manager 408 to reserve the necessary resources for recording the requested event. The recording service 400 maintains a conflict-free list of pending subscription events and synchronizes the list across all clients 310 and servers 308 in the home media network. The logging service 400 links events in the pending list to resources reserved and managed by the resource manager 408. The recording service 400 manages content stored on local drives and removes content when a drive reaches capacity. The recording service 400 stores metadata needed for viewers to view and purchase records. The recording service 400 initiates recording of the subscription event at a scheduled start time and for a scheduled duration. When updating the APG database, the logging service 400 processes updates to scheduled start times and durations or subscription events. The recording service 400 updates the playback manager 406 with the events available for viewing.

The home media client 310 and the home media server 308 use the recording service 400 to subscribe to events, delete subscribed events, assign priorities to subscribed events, and delete content from the servers.

All client 310 requests are received by a "record agent service" local to the requesting client 310. The recording agent is responsible for passing requests between the client 310 and the server 304 over the home media network.

Upon receiving a subscription request from the client 310 or the server 304, the recording service 400 requests the resource manager 408 to reserve resources required for recording. The resource manager 408 interfaces with a conflict resolver 412 to perform the necessary conflict resolution on behalf of the logging service 400. If no conflicts exist and resources are available, the resource manager 408 will reserve resource packets ("video pipeline", including tuners, demultiplexers, and necessary disk space) to handle the request. An event is booked when there are no conflicts or all conflicts are resolved (automatically or by the viewer) and the resources required for recording are reserved.

The logging service 400 maintains an internal list of conflict-free subscription events. The logging service 400 queries available resources and other metadata related to network logging data (such as APGs) and logs these data in a conflict-free subscription list. The recording service 400 will initiate recording of the subscription event at the scheduled start time and for the specified duration. The recording service 400 gives the PIP, rating information, and CGMS value to the DVR writer at the scheduled start time. The DVR writer will store this metadata in the metadata indexer/Rasp service at the time of recording.

The recording service 400 updates the playback manager 406 with the events available for viewing. Unless the event is a network scheduled recording (push event), the event is available for viewing when the recording begins. A push event is only available for viewing after the event is completed. The recording service 400 also provides the playback manager 406 with metadata to be associated with the event. The playback manager 406 stores these metadata until the event is deleted from the server 304.

The logging service 400 receives APG updates through a callback mechanism. Upon receiving an APG update, the record service 400 will 1) attempt to search for and subscribe to new events that match the record request; and 2) determining whether the updated event information causes a scheduling conflict with an existing subscription. The new conflict is passed to the conflict resolver 412 for conflict resolution. The logging service 400 will attempt to re-subscribe to lower priority events that were cancelled due to the conflict resolution process.

The recording service 400 manages all recorded material on the server 304 and removes content when the drive reaches capacity based on priority or quota or when content is marked as exceeding a specified date. The recording service 400 notifies the playback manager 406 and DVR writer when content is deleted, allowing these services to remove metadata associated with the deleted event.

The recording service 400 uses the CDI API to control all recording and tuning requests. The recording service 400 controls the flow of pre-recorded or live events to remote viewing devices in a multi-television home.

The conflict resolver 412 determines, or in some cases queries, the viewer to determine which set of conflicting activities (e.g., recording, live TV, etc.) should use the HMC312 resources (tuner, demultiplexer, disk space, etc.) for the specified time frame.

Standard booking algorithm

The booking is allowed according to the following "standard booking algorithm". The HMC server 304 or HMC client 310STB should allow the viewer to subscribe to any event for recording, even if the event exceeds a specified rating limit, or for STBs on which the event is subscribed, the event exceeds minimum hardware requirements. The HMC server 304 should support direct viewing of "live TV" and should bypass the recording service 400 in order to view live TV on the HMC client STB through live TV support 410 as shown in fig. 4.

Playback of recorded content should appear similar to live viewing with the following exceptions. Recorded content is only allowed to be played back by the playback service 402 if the viewer is a DVR subscriber, the HMC server 304 or HMC client 310STB should only allow the viewer to play back events that meet the minimum hardware requirements of a given STB, the HMC server 304 or HMC client 310STB should only allow the viewer to view the event using live television support 410 if the event meets the minimum hardware requirements of the STB, the HMC server 304 or HMC client 310STB should allow the viewer to transmit a currently playing recording to another STB only if the target STB meets the hardware requirements of the event, and the HMC server 304 or HMC client 310 should display an OSD or other defined STB when the minimum hardware requirements are exceeded. The playback service 402 acts as an authentication criterion to ensure that no matter which of the server 304 or client 310 requests playback, such requests can be supported, and if the request cannot be satisfied, the user is asked how best to proceed so that the request can be satisfied.

Playback of recorded content

The playback service 402 plays back events and services recorded by the recording service 400 and displays a list of network scheduled recorded events and which events requested to be purchased by the purchase manager 404 are allowed to be purchased. The recorded content should remain on the disc, either on a disc that is controllable by the viewer or on a network-controlled disc until the deletion condition is met. The rating of the recorded content is checked by the playback service 402 to ensure that the recorded event does not exceed a defined rating limit during playback. The rating may be checked continuously or periodically and the user may override the rating limits by manually entering a password or other method.

The purchase manager 404 should only allow the purchase of events if the PIP is stored at the time of subscription or recording. If there is a PIP stored with the event, it is sent to the CAM to determine viewing options when the viewer selects the event for viewing before starting playback.

If the event requires a purchase, the user may purchase the event. The purchase manager 404 may include spending limits that may be set for a given client 310, group of clients 310, group of servers 304 or servers 304, or for the entire system, and allow viewers to override the spending limits using OSDs on a global basis or on a per event basis. If the cancellation is performed prior to a predetermined time or event occurring during a purchase event, such as prior to viewing a non-free preview portion of the event, the purchase may be cancelled by the purchase manager 404. Multiple parts (multipart) events may be presented to a user by purchase manager 404 for purchase of multiple events individually or in groups.

Look over the buffer

The HMC server should associate a view buffer 414 with the live tv support 410 for a live tv viewing session. A live TV viewing session is associated with either the client 310 or the server 304 STB. The HMC server 304 should continue to record live TV to the view buffer 414 even if no server 304 or HMC client 310STB is viewing the content in the view buffer 414. When the STB is in a live TV viewing session and the tuner is to be tuned to a different channel, an OSD is typically displayed to the viewer on the monitor 206. The STB should attempt to use an idle tuner for channel change and if no idle tuner is available, the OSD is displayed. The STB should continue recording to the view buffer 414 of that tuner until the tuner is tuned to a different channel. When these STBs are tuned to the same channel, if two or more clients 310 or servers 304 select the same event for recording, the HMC server 304 should only store a single instance of the same event to the view buffer 414. The HMC server 304STB should store the view buffer 414 within the viewer partition of the disc. After the channel change, the HMC server 304STB should flush the view buffer 414.

Resource allocation and management

The resource manager 408 defines the resource pipelines required by a particular activity and establishes the resource pipelines by acquiring or reserving resources for the requesting activity, manages resource reservations to make optimal use of available resources at any time, utilizes the conflict resolver 412 to detect and mediate resource conflicts, and re-optimizes the settings of the reservations when the requested settings change or resource allocation changes. The resource manager 408 approves or denies the resource request for optimal use of the available resources. The resource manager 408 internally maintains a collision-free resource reservation database to track resource allocation throughout the network.

When a particular type of pipeline is required for a requesting activity (e.g., for live TV viewing, record only, playback only, record and playback), the resource manager 408 determines what resources are needed to create or construct a pipeline that can support the request. The resource manager 408 also checks all pipeline resources available to determine if the request can be satisfied.

When the resource manager 408 encounters a resource conflict during viewer or service activity, it compiles a list of resource groups called "full diversity" and submits the list with a request to the conflict resolver 412 to help in resolving the conflict. The conflict resolver 412 module returns a list of sufficient sets ordered according to a conflict resolution policy, or requests viewer interaction, based on the nature of the activity and the nature of the conflict. Based on the information received from the conflict resolver 412 module, the resource manager 408 will make a decision to allow the conflict-causing activity to proceed, decline the activity, or present the conflict to the viewer on the monitor 206 after releasing the required resources.

The sufficient set includes one or more activities that conflict with the requesting activity over a time frame of the requesting activity. Each sufficient set includes a set of activities that, if cancelled, will free up enough resources to resolve the resource conflict for the requesting activity.

When a change in the settings is requested (scheduling or canceling a recording request, or initiating or terminating a playback session), the resource manager 408 automatically updates the reservation settings. Similarly, when resources are added to or removed from the network, the resource manager 408 re-evaluates and reschedules the reservation settings. In addition to disk storage resources, an activity frees resources it acquires when it is cancelled or completed, freeing disk storage resources only when a file is deleted.

The resource manager 408 checks whether one activity can share the same resources with another activity and if so, will only allocate one resource to both activities. For example, when two event recordings occur on the same channel, and the two events overlap due to recording spread, the resource manager 408 recognizes that there is overlap on a single channel and only one tuner is assigned to record the two events. That is, since both events are on the same channel, the explorer 408 will not assign a second tuner for the recording when the overlap begins.

Resource types and pipelines

The resources (devices and services) discovered by the resource manager 408 may operate as managed or unmanaged resources. Those resources that impose limitations on the behavior of the system, such as tuners, the number of which determines an upper limit on the number of concurrent recordings, are considered managed resources. The managed resources are registered by the resource manager 408 and their use (reservation and acquisition) is scheduled by the resource manager 408. Unmanaged resources, on the other hand, are registered by the system, but are not managed by the resource manager. For example, tuners and disk space are managed resources that are registered by the resource manager 408 and whose usage is scheduled to satisfy the recording request. The memory is not registered by the resource manager 408 and its use is not scheduled.

The processing of broadcast services requires the use of a set of hardware devices commonly referred to as TV pipelines. Typically, a TV pipeline is a set of the following resources:

tuner, demultiplexer, SCID/PID filter, remultiplexer, video decoder device, audio decoder device, disk space, disk bandwidth, network bandwidth, and CAM.

Typically the resource manager 408 is limited to managing access to tuners, demultiplexers, remultiplexers (for recording and live viewing only), SCID/PID filters, disk bandwidth, network bandwidth, and disk space. It is assumed that other resources including the key generation capabilities of the video decoder, audio decoder and CAM are sufficient and that no conflict arises in any case.

The resource manager 408 accepts resource requests during three specific events within a specified timeframe, typically the lifetime of the server 308 or client 310 activity. These times are a resource scheduling time, a resource pre-acquisition time, and a resource acquisition time.

For certain types of activities, all three events occur, such as a single record in the future, a multiple event record in the future, and so forth. These types of activities must request resources from the resource manager 408 at all three events. Other types of activities, such as live TV viewing, cannot be scheduled and/or pre-acquired. These types of activities require the resources to be acquired immediately, or pre-acquired n minutes before the start time.

The resource scheduling request is used to attempt to reserve resources for future activities. For example, a single recording for the next wednesday will request that resources will be needed in order to perform the recording.

The resource pre-fetch request is used to attempt to pre-fetch a resource n minutes before the start time of the requesting activity and to ensure that no resource conflicts occur at this resource pre-fetch event. If no conflict exists, a "weak binding" between the pre-acquired resource and the requesting activity is created. For example, a previously scheduled single record pre-fetch request for this evening 7 o' clock will revalidate its resource reservation at 6:55 PM, and a weak binding will trigger a "2 minute warning" OSD on the UI.

The resource is acquired at the start time of the requested activity and is strongly bound to the activity. For example, live viewing session requests for immediate possession of the live viewing pipeline are hard-bound and cannot be used for any other activity without user intervention.

Resource request and reservation

A high-level overview of the system processing of a resource manager for managing resource requests and reservations is provided in flowcharts in fig. 5-7.

Resource scheduling

FIG. 5 illustrates block 500, which shows the resource manager 408 executing a resource scheduling task. At block 502, the resource manager 408 checks the availability of resources, not including disk bandwidth or other network bandwidth or disk space. After this check, decision block 504 is entered to see if there are any conflicts.

If no conflict is found in decision block 504, the system proceeds to a resource pre-fetch block 506. If conflicts exist, the conflict resolver 412 is invoked at block 508 to determine where conflicts exist and how to resolve them.

Initially, the conflict resolver 412 must determine whether user interaction is required, which is done at block 510. If user interaction is not required, control passes to block 512. If user interaction is required, the conflict resolver 412 presents the user with a conflicting activity screen at block 514 along with a prioritized list of sufficient sets to perform all requested activities so that the user can decide which activities are desired.

If the user deactivates the request of block 500 at block 516, control passes to block 518 where the resource scheduling request is denied. The request is then stored in memory at block 520.

The resource manager 408 then determines at block 522 whether the resources required for the denied request are available, and if not, control passes to block 524, where the resource manager 408 determines whether the denied request is due, typically by the passage of time. If not, the resource manager 408 continues to monitor the denied request for future changes to the system until the request expires, in which case the resource scheduling request of block 500 ends at block 526. If the resource becomes available at block 522 due to some other change in the system, control is passed back to block 502 and the resource manager 408 and conflict resolver 412 operate to determine if the request can now be approved.

Returning to block 510, if the conflict can be resolved by the conflict resolver 412 without user intervention, the conflict resolver 412 must determine at block 512 whether the requested activity can be approved by revoking a sufficient set of resources other than the requested activity itself. If so, control passes to block 528. Where the conflict resolver 412 typically cancels resource reservations for other events using a priority scheme to allow the requested activity of block 500 to proceed. Once these reservations are cancelled or rescheduled, the resource pre-fetching in block 506 may be performed for the requested activity.

If the conflict resolver 412 cannot reschedule or revoke sufficient diversity to warrant the requested activity of block 500, then control passes to block 518 and processing proceeds as described above with respect to block 518 and 524.

Returning to block 516, if the viewer does not cancel the requested activity, control passes to block 530 where the resource manager 408 approves the requested activity of block 500 and cancels or schedules the unresolved resource. Control then passes to block 506 for pre-fetching.

Resource pre-acquisition

In FIG. 6, the pre-fetch block 506 passes control to a block 600 where the availability of the network-active pipeline resources is determined. The decision block 602 determines whether there are any resource conflicts. If not, control passes to block 604, where resources are allocated for the request.

If conflicts exist, a conflict resolver 412 is invoked at block 606 to determine where conflicts exist and how to resolve them.

Initially, the conflict resolver 412 must determine whether user interaction is required, which is done at block 608. If user interaction is not required, control passes to block 610. If user interaction is required, the conflict resolver 412 presents the user with a conflicting activity screen at block 612, along with a prioritized list of sufficient sets to perform all requested activities so that the user can decide which activities are desired.

If the user cancels the pre-fetch activity of block 506, originally requested at block 500, at block 614, control passes to block 616 where the resource scheduling request is denied. The request is then stored in memory at block 618.

The resource manager 408 then determines at block 620 whether the resources required for the denied request are available, and if not, control passes to block 622 where the resource manager 408 determines whether the denied request is due, typically by the passage of time. If not, the resource manager 408 continues to monitor the denied request for future changes to the system until the request expires, in which case the resource scheduling request of block 500 ends at block 624. If the resource becomes available at block 620 due to some other change in the system, control is passed back to block 600 and the resource manager 408 and conflict resolver 412 operate to determine if the request can now be approved.

Returning to block 608, if the conflict can be resolved by the conflict resolver 412 without user intervention, the conflict resolver 412 must determine at block 610 whether the requested activity can be approved by revoking a sufficient set of resources other than the requested activity itself. If so, control passes to block 626. Where the conflict resolver 412 typically cancels resource reservations for other events using a priority scheme to allow the requested activity of block 500 and the pre-fetch activity of block 506 to proceed.

If the conflict resolver 412 cannot reschedule or revoke sufficient diversity to approve the requested activities of block 500 and the pre-acquisition activities of block 506, control passes to block 616 and processing continues as described above with respect to block 616 and 622.

Returning to block 614, if the viewer does not cancel the requested activity, then control passes to block 628 where the resource manager 408 cancels the sufficient set of viewer selections and weakly binds the requested activity and the allocated resource, which is the activity requested in block 500. Control then passes to block 604 for resource acquisition.

Resource acquisition

FIG. 7 depicts the flow of a resource acquisition event 604. Initially, decision block 700 is entered, which determines whether the acquisition of resources is from a pipe request or from a modem request. If it is a modem request, control passes to block 702 where the availability of modem access for the requested activity is checked. Control then passes to block 704 where a modem conflict is determined. If there is no modem conflict, control passes to block 706 where resource acquisition is granted.

If there is a modem conflict, the conflict resolver 412 is queried to resolve the existing conflict at block 708. If the conflict can be resolved by revoking sufficient diversity at block 710 instead of requesting activity, the request is approved at block 706; otherwise the request is denied at block 712.

If it is determined at block 700 that it is a pipe request, block 714 checks the availability of all pipe resources. If a pipeline resource conflict is not found at block 716, control passes to block 718 to determine if there are any disk space conflicts. If there is no disk space conflict, then at block 720 pipeline fetches are approved.

If there are pipeline resource conflicts, the conflict resolver 412 is invoked at block 718 to determine where the conflicts are and how to resolve them.

Initially, the conflict resolver 412 must determine whether user interaction is required, which is done at block 720. If user interaction is not required, control passes to block 722. If user interaction is required, the conflict resolver 412 presents the user with a conflicting activity screen at block 724 along with a prioritized list of sufficient sets to perform all requested activities so that the user can decide which activities are desired.

If the user cancels the resource acquisition activity 604 at block 726, which was originally requested at block 500, which is the pre-acquisition activity of block 506, then control passes to block 728 where the resource scheduling request is denied.

If the user does not cancel the requested activity, then the sufficient set of viewer selections is cancelled at block 730 and control passes to block 718.

Returning to block 720, if the conflict can be resolved by the conflict resolver 412 without user intervention, the conflict resolver 412 must determine at block 722 whether the requested activity can be approved by revoking a sufficient set of resources other than the requested activity itself. If so, control passes to block 732. Where the conflict resolver 412 typically cancels resource reservations for other events using a priority scheme to allow activities that make the request of block 500 and pre-fetch activities of block 506. Control then passes to block 718.

If the conflict resolver 412 cannot reschedule or revoke sufficient diversity to approve the requested activity of block 500 and the pre-fetch activity of block 506, control passes to block 728 and pipeline fetch is denied.

If block 718 determines that a disk space conflict exists, the conflict resolver 412 is again invoked to resolve the conflict in block 734, and in block 736 the resource manager 408 deletes the content files that are necessary and requested by the conflict resolver 412 to allow the fetch 604 in block 720.

Resource release

When an activity is cancelled or completed, its resources will be released and become available for other uses. When the viewing session initiates a take-over use by starting another playback or by tuning to another channel, the resources acquired for live viewing or playback of the recorded program will be released. The resource manager 408 is notified that the resource is no longer being used, or if it is a managed resource, the resource manager 408 knows that the resource is no longer being used and can schedule the resource for use elsewhere in the system.

Weak bindings

A weak binding refers to a resource reservation by the resource manager 408 for the request activity grant during a pre-fetch time (n minutes before the actual start time of the activity) such that any activity that is using or attempting to use the weak bound resource will be alerted but will not be preempted until the resource is strongly bound to the request activity. For example, if a live viewing or playback activity is currently using a weakly bound resource or is attempting to use a weakly bound resource within a 2 minute time period, the resource manager 408 will trigger the UI to display a "2 minute warning" OSD.

Conflict resolver

The conflict resolver 412 allows control of which action is taken when HMC312 activity encounters a resource conflict, in a manner that is independent of the rest of the system. These conflicts may occur when concurrent viewer or service activities (live TV, recording download or playback) require more resources than are available in the HMC 312.

When the HMC312 encounters a resource conflict during a viewer or service activity, it makes a request to the conflict resolver 412 to assist in resolving the conflict. The conflict resolver 412 module compiles a list of activities that may be taken to resolve conflicts based on the nature of the activity and the nature of the conflict. Based on the information received from the conflict resolver 412 module, the system will make a decision to allow the conflict-causing activity to proceed after the required resources are released, deny the activity, or present the conflict to the viewer via the UI.

Trick mode/trick play

The Set Top Box (STB) (also referred to herein as HMC312 and/or client IRD308) should support pause/Play Trick Play Bar (Trick Play Bar) functionality. When the viewer requests any trick play bar functionality, the STB displays the trick play bar. The STB supports 2 x, 6 x, 12 x and 30 x fast forward and rewind speeds. The STB should not time out to display trick play bars in FF and REW modes.

Dedicated tuner for network management functions

Additionally, there may be a user-controlled tuner in the HMC312 that is not capable of commanding the tuner, such as through a viewer channel request. Such tuners are commonly referred to as "network tuners". The network tuner is not meant to be under the control of the user, but is rather designed to be under the control of the service provider. Regardless of the channel assignments made by FTM300, the network tuner will be available to all client IRDs 310, server IRDs 304 and PVRs.

A network tuner typically provides emergency audio/video information or a dedicated chain of tuners, demodulators, etc. that a service provider may use to provide information other than viewer channels to each IRD 308. Additionally, a network tuner may be present in the FTM300 or in the IRDs 304/310 or PVRs without departing from the scope of the present invention.

Such a dedicated tuner may be used to provide channel guide information, record content desired by the service provider on a recording device, or other functionality required or desired by the service provider.

Conclusion

This concludes the description of the preferred embodiments of the present invention. The foregoing description of the preferred embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching.

The invention discloses a system for delivering satellite video signals for display on a monitor. The system according to the invention comprises an antenna, a server receiver connected to the antenna, and at least one client receiver connected to the server receiver, wherein the client receiver sends commands to the antenna and receives signals from the antenna through the server receiver.

It is intended that the scope of the invention be limited not with this detailed description, but rather by the claims appended hereto and their equivalents. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many modifications of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended and their equivalents.

Claims (20)

1. A system for receiving satellite video signals for display on a monitor, comprising:

an antenna;

a server receiver connected to the antenna; and

at least one client receiver connected to the server receiver, wherein the client receiver sends commands to the antenna and receives satellite video signals from the antenna through the server receiver.

2. The system of claim 1, wherein the server receiver allocates resources to the at least one client receiver based on commands sent from the at least one client receiver to the server receiver.

3. The system of claim 2, wherein the command comprises at least one of a group consisting of recording an event and viewing a particular channel.

4. The system of claim 3, wherein the server receiver identifies a conflict between the first client receiver and the second client receiver.

5. The system of claim 4, wherein the server receiver accepts manual intervention to resolve the conflict.

6. The system of claim 5, wherein the server receiver reports the conflict on the monitor.

7. The system of claim 6, wherein the server receiver comprises a video recorder.

8. The system of claim 7, wherein said video recorder includes a plurality of playback speeds.

9. An apparatus for displaying video information, comprising:

a broadcast delivery system comprising a transmitter, a first receiver, and at least one second receiver, the first receiver and the at least one second receiver communicatively connected;

a first monitor connected to the first receiver;

at least one second monitor respectively connected to the at least one second receiver, wherein the first monitor and the second monitor independently display video information based on signal selection in the first receiver and the at least one second receiver;

a processor coupled to the first receiver, wherein the processor receives commands from the at least one second receiver to change the video information displayed on the at least one second monitor.

10. The apparatus of claim 9, wherein the broadcast delivery system is a satellite-based delivery system.

11. The apparatus of claim 10, wherein the first receiver allocates resources to the at least one second receiver based on a command sent from the at least one second receiver to the first receiver.

12. The apparatus of claim 11, wherein the command comprises at least one of a group consisting of recording an event and viewing a specific channel.

13. The apparatus of claim 12, wherein the first receiver identifies a collision between the first second receiver and the second receiver.

14. The apparatus of claim 13, wherein the first receiver accepts manual intervention to resolve the conflict.

15. The apparatus of claim 14, wherein the first receiver reports the collision on the first monitor.

16. The apparatus of claim 15, wherein the first receiver comprises a video recorder.

17. The apparatus of claim 16, wherein said video recorder includes a plurality of playback speeds.

18. The apparatus of claim 17 wherein said at least one second receiver sends a command to said first receiver to record a video program on a video recorder for viewing on said at least one second monitor.

19. The apparatus of claim 17, wherein the first receiver reports the collision on the at least one second monitor.

20. The apparatus of claim 17, wherein the data stream is selected from the group consisting of: selecting a communication connection between the first receiver and the at least one second receiver from the group of cable, distribution line and telephone line.