SYSTEM AND METHOD FOR PROVIDING CONDITIONAL ACCESS IN A SATELLITE TELEVISION SYSTEM

A network device may pair with a particular satellite dish by storing a security key uniquely associated with the particular satellite dish. The network device may then receive encrypted data from the particular satellite dish, and decrypt the received encrypted data utilizing the security key. One or more circuits of the network device may be operable to prevent the network device from decrypting data from any satellite dish other than the particular satellite dish. The network device may be operable such that the security key is the only key that the network device can utilize for decrypting signals received via a particular interface and/or from a particular address. One or more circuits collocated with a satellite dish may be operable to encrypt data utilizing a security key stored in the one or more circuits. The security key may be unique to the one or more circuits and/or satellite dish.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
INCORPORATION BY REFERENCE

This patent application makes reference to:

U.S. Patent Application Provisional Ser. No. 61/487,979 entitled “Efficient Architecture for Broadband Receivers” filed on May 19, 2011;
U.S. patent application Ser. No. 13/326,125 entitled “System and Method in a Broadband Receiver for Efficiently Receiving and Processing Signals” filed on Dec. 14, 2011; and
U.S. patent application Ser. No. 13/301,400 entitled “Method and System for Providing Satellite Television Service to a Premises” filed on Nov. 21, 2011.

Each of the above applications is hereby incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

Certain embodiments of the invention relate to satellite television. More specifically, certain embodiments of the invention relate to a system for method for conditional access in an in-home network based on multi-network communication.

BACKGROUND OF THE INVENTION

Existing systems for conditional access are overly expensive and often ineffective. Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.

BRIEF SUMMARY OF THE INVENTION

A system and/or method for providing conditional access in a satellite television system, substantially as illustrated by and/or described in connection with at least one of the figures, as set forth more completely in the claims.

These and other advantages, aspects and novel features of the present invention, as well as details of an illustrated embodiment thereof, will be more fully understood from the following description and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary satellite television system.

FIG. 2 depicts an exemplary Internet Protocol low-noise block-downconverter (IP-LNB).

FIG. 3 depicts an exemplary network gateway for use with a satellite dish comprising an IP-LNB.

FIG. 4 illustrates removal and application of content protection by an IP-LNB.

FIG. 5 is a flowchart comprising exemplary steps for pairing of a satellite dish and a client device.

FIG. 6 is a diagram illustrating out-of-band exchange of security keys in a satellite television system in which a satellite dish is paired with a gateway.

DETAILED DESCRIPTION OF THE INVENTION

As utilized herein the terms “circuit” and “circuitry” refer to physical electronic components (i.e. hardware) and any software and/or firmware (“code”) which may configure the hardware, be executed by the hardware, and or otherwise be associated with the hardware. As utilized herein, “and/or” means any one or more of the items in the list joined by “and/or”. As an example, “x and/or y” means any element of the three-element set {(x), (y), (x, y)}. As another example, “x, y, and/or z” means any element of the seven-element set {(x), (y), (z), (x, y), (x, z), (y, z), (x, y, z)}. As utilized herein, the terms “block” and “module” refer to functions than can be implemented in hardware, software, firmware, or any combination of one or more thereof. As utilized herein, the term “exemplary” means serving as a non-limiting example, instance, or illustration. As utilized herein, the terms “e.g.” or “for example” introduce a list of one or more non-limiting examples, instances, or illustrations.

FIG. 1 depicts an exemplary satellite television system. As shown in FIG. 1, the system 100 comprises an exemplary in-home network 100, a satellite dish 106 comprising a module 122, a wide area network (WAN) 112 comprising one or more servers 124, a network link 108 connecting the dish 106 and the in-home (or in-premises) network 100, and a link 110 connecting the in-home network 100 and the WAN 112. The exemplary in-home network 100 comprises a gateway 102, television 114, and a local area network (LAN) 104.

The satellite dish 106 may comprise circuitry operable to receive satellite signals and output the received signals to the gateway 102 via the communication link 108. The satellite dish 106 may, for example, comprise the Internet Protocol (IP) low noise block-downconverter (LNB) 122 described below with respect to FIG. 2.

Each of the communication links 108 and 110 may comprise one or more wired, wireless, and/or optical links. The communication link 108 may comprise, for example, a coaxial cable and/or a 60 GHz wireless link which carries physical layer symbols in accordance with, for example, Multimedia over Coax Alliance (MoCA) or Ethernet standards. The communication link 110 may comprise, for example, a coaxial cable or Cat-5e cable which carries physical layer symbols in accordance with, for example, DSL or Ethernet standards.

The gateway 102 may comprise circuitry operable to receive satellite signals, process the received signals to recover data, and output the data to an end-user device such as the television 114. The gateway 102 may also comprise circuitry operable to transmit and/or receive data over the communication link 110 and 128. Communications over the link 128 may be in accordance with, for example, Multimedia over Coax Alliance (MoCA) and/or Ethernet standards. Details of an exemplary gateway 102 are described below with respect to FIG. 3. The gateway 102 may, for example, be a stand-alone unit or may be integrated with a television set top box (STB) or other device of the network 100.

The television 114 may comprise circuitry operable to receive media and control data via one or more point-to-point media links (e.g., HDMI), process the received data to recover audio and/or video, and present the audio and/or video to a viewer.

The WAN 112 may comprise, for example, a DSL (or cable) headend and associated circuitry and/or devices. Such devices may include one or more servers 124 which are operable to communicate with the gateway 102 to communicate general IP traffic and/or to communicate control information pertaining to satellite television communications. For example, the server 124 may establish a secure connection to the gateway 102 to exchange security keys for decrypting and/or descrambling signals received via the dish 106. The communication link between a satellite television content provider and the network 100 via the satellite dish 106 and communication link 108 may, for example, be completely or partially independent of the WAN and communication link 110.

The LAN 104 may comprise any number and/or type of networking devices. Exemplary devices shown include a computer 116, network attached storage 120, and a wireless access point (WAP) 118. The devices of the LAN 104 may communicate utilizing, for example, MoCA and/or Ethernet protocols.

In operation, the dish 106 may receive satellite signals, the signals may be processed by the IPLNB 122, and the processed signals may be transmitted onto the link 108. The processing of the signals by the IPLNB 122 may include encryption utilizing one or more security keys that are unique to the dish 106 and/or unique to the IPLNB 122. As utilized herein, “unique” means literally unique (i.e., one of a kind), or unique to the point where the probability of another dish or IPLNB having the same security keys is below a desired threshold. The threshold may be chosen by, for example, the manufacturer of the IPLNB 122 and/or the satellite service provider employing the IPLNB 122. Higher probability of keys being unique may be achieved by, for example, utilizing longer keys.

The gateway 102 may receive the signals on the link 108, process the signals, and output media and/or other data to the television 114 and/or the LAN 104. The processing of the signals by the gateway 102 may include decryption utilizing a security key that is unique to the dish 106 and/or unique to the IPLNB 122. The security key may have been programmed into the gateway 102 during a pairing of the gateway 102 to the dish 106 and/or IPLNB 122. Such a pairing may, for example, be performed by a technician during installation of the dish 106, the IPLNB 122, and the gateway 102. For example, the technician may configure the IPLNB 122 and/or the gateway 102 into a “service mode.” A service mode may be, for example, a mode which is accessible only by persons having necessary security credentials (e.g., a password, and/or a dongle or other specialized hardware). While the IPLNB 122 and/or the gateway 102 is in a service mode, a technician may be able to read and/or write security keys to and/or from memory in the IPLNB 122 and/or gateway 102.

In an exemplary embodiment, once the security keys are programmed into the IPLNB 122 and the gateway 102, the gateway may be able to only decrypt signals from the particular IPLNB 122 and not able to decrypt signals from another IPLNB (not shown). In this manner, if the gateway 102 is moved to a different location and connected to a different IPLNB, the gateway 102 may be unable to process signals from the different IPLNB (e.g., the gateway 102 may be unable to decrypt encrypted content from the different IPLNB).

FIG. 2 depicts exemplary circuitry collocated with a satellite dish. The transceiver circuit 122, referred to herein as IP-LNB 122, comprises a low-noise block-downconverter 210 and a broadband multichannel receiver (BMR) 215. The LNB 210 and BMR 215 may, for example, be integrated on a common substrate (e.g., a single silicon die).

The LNB 210 receives RF satellite signals, and filters and amplifies such signals to generate corresponding IF signals, which are then provided to downstream entities. The LNB 210 is illustrated outputting M (an integer number) of IF signals, labeled s1 to sM. Each of such IF signals may, for example, comprise IF signals in the 950 MHz to 2150 MHz range, each of which may correspond to a respective satellite signal (e.g., a satellite television signal).

The BMR 215 may, for example, be operable to process the plurality of IF signals S1-SM received from the LNB 210 and output a digital signal (e.g., one or more digital Internet Protocol (IP) signals) that communicates desired channels. For example, a non-limiting exemplary implementation of the BMR 215 is illustrated in FIG. 2, and comprises a variety of modules, for example a Full-Band Capture Receiver bank 240, Digital Channelizer 250, N×Demodulator bank 260, IP Bridge 270, Communication Interface Module 280 (e.g., an IP communication interface module comprising a MAC and PHY layer for IP networking), and a conditional access module 262.

For example, the BMR 215 may comprise a Full-Band Capture Receiver bank 240 (e.g., comprising M full-band capture receivers, FBCR1-FBCRM). Each of such full-band capture receivers may, for example, digitize the entire IF signal contained on a respective input IF signal from the LNB 210. In an exemplary satellite implementation, each of such full-band capture receivers may, for example, digitize the entire 950 MHz to 2150 MHz range of satellite-related content (e.g., media content) on the respective input signal. For example, FBCR1 may receive analog IF signal s1 from the LNB 210 and digitize the entire IF content of the input signal s1 to generate output signal d1. In such a manner, the full-band capture receiver bank 240 may receive M analog IF signals s1-sM from the LNB 210 and output corresponding digital signals d1-dM.

Note that although the full-band capture receiver bank 240 is shown and discussed as receiving the M analog IF signals s1-sM from the LNB 210, such signals may be received from a plurality of different sources (e.g., from one or more satellite television sources, from one or more cable television sources, from one or more terrestrial broadcast television sources, etc.). Such full-band capture receiver(s) may, for example, operate to capture the complete, or substantially complete, spectral band for a particular communication protocol, standard or not (e.g., for a satellite television communication protocol). Also, such full-band capture receiver(s) may, for example, operate to capture the complete, or substantially complete, respective spectral bands for a plurality of respective communication protocols or standards (e.g., for a satellite television communication protocol and/or a cable television communication protocol and/or a terrestrial television communication protocol, etc.).

Note that, depending on the IF bandwidth utilization and/or depending on desired channels, one or more of the plurality of FBCRs of the FBCR bank 240 may be powered down. For example, if a particular FBCR corresponds to a satellite signal that is not presently providing a desired channel, such particular FBCR may be powered down (e.g., until a need for a channel corresponding to the particular FBCR arises). Alternatively, a non-utilized FBCR may also be re-tasked to process another signal (e.g., a signal corresponding to another orbital slot, a signal corresponding to a different signal source, for example, a different satellite and/or terrestrial broadcast source, etc.).

The BMR 215 may also comprise a digital channelizer (DCC) 250. The DCC 250 may, for example, operate to receive the digitized signals d1-dM output from the FBCR bank 240. The DCC 250 may then, for example, process such received digitized signals d1-dM (e.g., decimating and filtering such signals) to select desired channels from the set of channels available in the digitized signals d1-dM. As such, the DCC 250 may, for example, serve as a crossbar for selecting an arbitrary set of desired channels from among the channels available from one or more broadband sources.

The DCC 250 may perform such processing in any of a variety of manners. For example and without limitation, the DCC 250 may utilize a polyphase filter or a block that calculates a running FFT of the received digitized signals d1-dM and selects a decimated output from each FFT for further processing. The DCC 250 may, for example, perform switching and routing operations after performing the above-mentioned FFT/filtering operations, which may, for example, beneficially reduce the speed at which the switching and routing operations need be performed.

The further processed output may then, for example, be output on one or more signals c1 (e.g., output on M output lines, each of which corresponding to one of the M input signals; multiplexed onto a single output line; multiplexed onto more than one and less than M output lines, etc.).

The DCC 250 may, for example, receive channel-selection information from upstream (e.g., via a path from the satellite) and/or from downstream (e.g., from an in-home device), such channel-selection information being indicative of such desired and available channels.

The BMR 215 may additionally comprise an N×Demodulator bank (NDB) 260. Such NDB 260 may, for example, operate to receive the output signal(s) c1 from the DCC 250 and recover the digital information modulated on such received signal(s). The one or more signals c2 output by the NDB 260 (which may comprise one or more digital signals output on one or more output lines) may, for example, comprise one or more transport streams, including for example, media transport streams like MPEG, general data transport streams, etc.

In an exemplary embodiment of the invention, the signal(s) c2 may comprise one or more scrambled and/or encrypted transport streams. Accordingly, the conditional access module (CA) 262 may be operable to descramble and/or decrypt the signal(s) c2. The CA 262 may, however, only descramble and/or decrypt content that is permitted by a service-level agreement between the satellite provider and the owner of the dish 106. Content to which the dish 106 is permitted access (e.g., free content and/or content that the owner of the dish 106 has paid for) may be descrambled and/or decrypted before being output as signal(s) c3. Content to which the dish 106 is not permitted access (e.g., subscription-based content that the owner of the dish 106 has not paid for) may be output as signal(s) c3 in the scrambled and/or encrypted form in which it was received.

The BMR 215 may further comprise a digital rights management (DRM) module 264 which may be operable to generate the signal(s) c4 by applying content protection to the signal(s) c3. The DRM module 264 may, for example, scramble and/or encrypt the signal(s) c3 utilizing one or more keys. The one or more keys may be unique to the IPNLB 122. The key(s) may be one-time programmable and/or may be occasionally and/or periodically updated.

The DRM module 264 may, for example, apply content protection in accordance with the DTCP-IP standard. The CA 262 and the DRM 264 may be tightly integrated (e.g., integrated in a single IC, performed by a same processor, etc.) to provide physical protection for the signal(s) c3.

The BMR 215 may further comprise an IP Bridge (BIP) 270 (or other protocol bridge(s)). Such BIP 270 may, for example, operate to receive the output signal(s) c4 from the DRM module 264 (e.g., including transport streams and/or other information) and encapsulate such digital information in IP packets. Such encapsulation may, for example, comprise forming the input digital information into IP packets for downstream communication.

The BIP 270 may also, for example, operate to filter the digital information received from the DRM module 264. Such filtering may, for example, comprise various types of data filtering. For example, the BIP 270 may operate to perform packet identification (PID) filtering to select only desired and available (i.e., content permitted by the CA 262) portions of the input data for encapsulation. Such filtering may, for example, beneficially reduce the amount of IP-encapsulated data that is sent downstream from the IP-LNB 122 to the customer premises (e.g., only desired packets are communicated on the in-home IP network). Such filtering may also enable conditional access and/or digital rights management by restricting which portions of the signal(s) c4 (i.e., which content) can be sent to which network address(es). Such filtering may, for example, be controlled by the operator (e.g., via the conditional access module 262 and control signal(s) received via a satellite channel) and/or by the user (e.g., via control signal(s) received from in-home user apparatus).

The BIP 270 may then output the IP-encapsulated data as one or more output signals c5. The BMR 215 may also comprise a communication interface module 280 operable to interface with an IP network. The BMR 215 may, for example, operate to perform network layer operation, transport layer operation, MAC layer operations, and/or PHY layer operations compatible with one or more network standards (e.g., MoCA and/or Ethernet). In such example, the communication interface module 280 may operate to interface with the IP network by transmitting and/or receiving signals sIP. compatible with the IP network.

FIG. 3 depicts an exemplary network gateway for use with a satellite television system. The exemplary gateway 102 comprises a host subsystem 304, a data bus 312, a wide area network (WAN) interface module 314, a dish interface module 316, a LAN interface module 318, a digital rights management (DRM) module 322, an MPEG processing module 324, video encoding module 328, and an audio digital-to-analog conversion (DAC) module 330.

The host subsystem 304 may comprise a CPU 306 and a memory 308 that may be operable to implement processes and/or applications 310 for controlling the overall function of the gateway 102. The processes and/or applications 310 may, for example, comprise an operating system and a graphical user interface. The memory 308 may comprise, for example, one-time programmable (OTP) memory, flash memory, and/or electronically erasable programmable read only memory (EEPROM) in which one or more security keys may be stored. In an exemplary embodiment, one or more security keys may be read from and/or written to the memory 308 only while the gateway 102 is configured into a service mode.

The WAN interface module 314 may operate as an interface between the data bus 312 and the wide area network 112. The WAN module 314 may support, for example, a WAN protocol such as xDSL or Ethernet in the first mile.

The LAN interface module 318 may operate as an interface between the data bus 312 and the LAN 104. The LAN interface module 318 may support, for example, a protocol such as Ethernet or MoCA.

The dish interface module 316 may operate as an interface between the data bus 312 and the dish 106. The dish interface module 316 may support, for example, a proprietary protocol and/or a standardized protocol such as Ethernet or MoCA. In various exemplary embodiments of the invention, the IP-LNB 122 may be a member of the LAN 104 and may communicate with the gateway 102 in accordance with protocols in use in the LAN 104. In one such embodiment, the dish interface 316 may be substantially the same as the LAN interface 318. In another such embodiment, dish interface module 316 may be absent and the IP-LNB 122, along with the other devices of the LAN 104, may communicate with the gateway 102 via a network switch (which may be internal or external to the gateway 102).

The data bus 312 may comprise circuitry for the communication of data between various modules of the gateway 102. The data bus 312 may operate in accordance with one or more standards such as, for example, the peripheral component interconnect (PCI) express standard.

The digital rights management (DRM) module 322 may be operable to descramble and/or decrypt an MPEG transport stream received via the data bus 312. The key(s) utilized by the DRM module 322 to descramble and/or decrypt may be the same as (for symmetric-key algorithms), or a complimentary to (for asymmetric-key algorithms), the key(s) utilized by the dish 106 in scrambling and/or encrypting the MPEG transport stream. In an exemplary embodiment, the DRM 322 may be configured such that it is capable of decrypting only signals from the particular dish with which the gateway 102 has been paired. That is, the DRM 322 may be prevented from decrypting signals from any dish/IPLNB other than the dish 106/IPLNB 122. In an exemplary embodiment, the DRM 322 may be forced to use one or more security keys corresponding to the dish 106/IPLNB 122 when decrypting data received via a particular interface (e.g., via the dish interface 316) and/or from a particular address (e.g., MAC address).

The MPEG processing module 324 may be operable to demultiplex and decode the MPEG transport stream received via the data bus 312. The video encoding module 328 may be operable to receive a video stream from the MPEG processing module 324 and encode the video for conveyance to an end-user device, such as the television 114, via a wired or wireless connection. (e.g., a point-to-point wired connection such as HDMI). The audio digital-to-analog conversion (DAC) module 330 may be operable to receive a digital audio stream from the MPEG processing module 324 and convert the audio stream to analog for conveyance to one or more speakers.

In operation, the gateway 102 may connect to the WAN 112 via the module 314, connect to the dish 106 via the module 316, and connect to the LAN 104 via the module 318. The gateway 102 may receive an IP-encapsulated MPEG transport stream from the dish 106 via the module 316. The module 316 may extract the MPEG transport stream from the IP stream and convey the MPEG transport stream onto the bus 312. The DRM module 322 may receive the MPEG transport stream from the data bus 312 and attempt to descramble and/or decrypt the MPEG transport stream utilizing one or more keys. In an exemplary embodiment of the invention, the keys utilized by the DRM module 322 may have been programmed into the DRM module 322 when pairing the gateway 102 with the dish 106 (or IPLNB 122) during installation. In another exemplary embodiment of the invention, the keys utilized by the DRM module 322 may have been received from a server (e.g., server 124 of FIG. 1) of the satellite provider, as, for example, described below with respect to FIG. 8.

In instances that the received MPEG transport stream was not received from the dish 106/IPLNB 122, i.e., not received from the dish/IPLNB corresponding to the key(s) stored in the memory 308, then the DRM 322 may be unsuccessful in attempting to decrypt and/or descramble the MPEG transport stream.

In instances that the received MPEG transport stream was received from the dish 106/IPLNB 122, i.e., the dish/IPLNB corresponding to the key(s) stored in the memory 308, then the DRM 322 may successfully decrypt and/or descramble the MPEG transport stream. Subsequently, the DRM module 322 may pass the descrambled and/or decrypted transport stream to the MPEG processing module 324. The MPEG processing module 324 may demultiplex and decode the MPEG transport stream and output the video to the video encoding module 328 and the audio to the audio DAC module 330. The video encoding module 328 may encode and output the video in accordance with one or more standards (e.g., HDMI or Displayport). The audio DAC module 330 may convert the audio to one or more analog audio signals and output the audio signal to one or more speakers.

FIG. 4 illustrates removal and application of content protection by circuitry collocated with a satellite dish. Shown in FIG. 4 is the IP-LNB 122 and the gateway 102. The IP-LNB 122 receives a content-protected MPEG transport stream 405. The conditional access module 262 descrambles and/or decrypts those portions of the stream to which the dish 106 has access (i.e., free content and content for which the owner of the dish 106 has paid) to generate the unprotected stream 407. The DRM module 264 then applies content protection to the stream 407 to generate the stream 409. The DRM module 264 may protect the stream 407 in accordance with one or more standards such as, for example, DTCP-IP. The encryption and/or scrambling of the stream 407 to generate the stream 409 may utilize one or more keys 412. The key(s) 412 may be unique to the IPLNB 122. The key(s) 412 may, for example, be programmed into the IP-LNB 122 when the dish 106 is being installed at the end-user location (e.g., a home) and paired with the gateway 102. Additionally or alternatively, the key(s) 412 may be occasionally and/or periodically updated via received satellite signals. The stream 409 may be communicated to the DRM module 322 of the gateway 102 via the link 108. Note that processing of the stream 409 between the DRM 464 and the DRM module 322 (e.g., by the BIP 270, the IPPM 280, and the dish interface module 316) is not shown in FIG. 4, for simplicity of illustration. Also note that the so-called “unprotected” stream 407 may be physically protected deep within integrated circuitry.

The DRM module 322 may descramble and/or decrypt the stream 409 to recover the stream 407. The descrambling and/or decryption may utilize one or more keys 414. The key(s) 414 may be unique to devices paired with the IPLNB 122. The key(s) 414 may, for example, be programmed into the gateway 102 when the gateway 102 is being installed at the end-user location (e.g., a home) and mated with the dish 106. Additionally or alternatively, the key(s) 414 may be occasionally and/or periodically updated by signals received via any one or more of the modules 314, 316, and 318.

FIG. 5 is a flowchart comprising exemplary steps for pairing of a satellite dish and a client device. The exemplary steps begin with step 502 in which one or more security keys are read out of a circuit collocated with (or intended to be collocated with) a satellite dish. The key(s) may, for example, be based on a hardware unique identifier programmed into the circuit during production of the circuit. The reading of the key(s) may occur, for example, during installation in the end-user premises using special equipment possessed by an installation technician and/or by the installation technician entering a password.

In step 504, the key(s) read at step 502 may be programmed into a client device (e.g., the gateway 102). This may occur, for example, during installation in the end-user premises using special equipment possessed by an installation technician or by the circuit collocated with the dish and the client device each being configured into a service mode where the circuits send the key(s) to the client device.

In step 506, during operation of the dish and client, the circuitry collocated with the dish may scramble and/or encrypt content using the key(s) read out in step 502. Next, in step 508, the circuitry collocated with the dish may transmit the scrambled and/or encrypted content onto a network link.

In step 510, the client may receive the content via the network link, and descramble and/or decrypt content using the key(s) using the key(s) programmed into the client device in step 504.

FIG. 6 is a diagram illustrating out-of-band exchange of security keys in a satellite television system in which a satellite dish is paired with a gateway. Referring to FIG. 6, is the dish 106 with IP-LNB 122, the gateway 102, the WAN 112, a provider 602, and a satellite 604.

In operation, the provider 602 may occasionally and/or periodically send a new one or more keys 412 to the dish 106. Upon update of the key(s) 412, the key(s) 414 in the gateway 102 will also need to be updated so that the gateway 102 can continue to descramble and/or decrypt signals from the dish 106. Accordingly, the provider may establish a secure connection to the gateway 102 via the WAN 112. After verifying the identity of the gateway 102 (including verifying that the gateway 102 has been registered with the dish 106 and/or IP-LNB 122), the provider may send the one or more keys 414 to the gateway 102. Accordingly, if the gateway 102 is not a client that is registered with the dish 106 and/or IP-LNB 122, the gateway 102 will be unable to obtain the key(s) 414 for descrambling and/or decrypting content from the dish 106. Similarly, because the key(s) 414 are uniquely compatible with the dish 106, if the gateway 102 is not connected to the dish 106 but is connected to another dish (not shown), the gateway 102 will be unable to descramble and/or decrypt content from such other dish.

In accordance with various aspects of the present invention, a network device (e.g., gateway 102) may pair with a particular satellite dish (e.g., dish 106 comprising IPLNB 122) by storing a security key (e.g., key 414) uniquely associated with the particular satellite dish. The network device may then receive encrypted data from the particular satellite dish, and decrypt the received encrypted data utilizing the security key. In an exemplary embodiment, one or more circuits of the network device may be operable to prevent the network device from decrypting data from any satellite dish other than the particular satellite dish. In an exemplary embodiment, the network device may be operable such that the security key is the only key that the network device can utilize for decrypting signals received via a particular interface (e.g., the dish interface 316) and/or from a particular address. The security key may be written to memory in the network device while the network device is configured into a service mode. The security key may be received via a link (e.g., link 110) that is out-of-band with a link (e.g., link 108) between the network device and the particular satellite dish. The network device may comprise one-time-programmable (OTP) memory and/or electrically erasable programmable read only memory (EEPROM) in which the security key is stored.

In accordance with various aspects of the present invention, one or more circuits collocated with a satellite dish (e.g., circuits of the IPLNB 122 collocated with the dish 106) may be operable to encrypt data utilizing a security key (e.g., key 412) stored in the one or more circuits. The one or more circuits may then transmit the encrypted data. The security key may be unique to the one or more circuits and/or satellite dish. The one or more circuits may be operable to transmit the encrypted data over an Internet Protocol (IP) network. In an exemplary embodiment, the security key may be readable from the one or more circuits only while the one or more circuits are configured into a service mode. In an exemplary embodiment, the one or more circuits may transmit the security key to a network device (e.g., gateway 102) while the one or more circuits are configured into a service mode. The one or more circuits may comprise one-time-programmable (OTP) memory and/or electrically erasable programmable read only memory (EEPROM) in which the security key may be stored.

Other embodiments of the invention may provide a non-transitory computer readable medium and/or storage medium, and/or a non-transitory machine readable medium and/or storage medium, having stored thereon, a machine code and/or a computer program having at least one code section executable by a machine and/or a computer, thereby causing the machine and/or computer to perform the steps as described herein for providing conditional access in a satellite television system.

Accordingly, the present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in at least one computing system, or in a distributed fashion where different elements are spread across several interconnected computing systems. Any kind of computing system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general-purpose computing system with a program or other code that, when being loaded and executed, controls the computing system such that it carries out the methods described herein. Another typical implementation may comprise an application specific integrated circuit or chip.

The present invention may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.

While the present invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiment disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims.

Claims

1. A system comprising:

one or more circuits for use in a network device, said one or more circuits being operable to: pair with a particular satellite dish by storing a security key uniquely associated with said particular satellite dish; receive encrypted data from said particular satellite dish; decrypt said received encrypted data utilizing said security key.

2. The system of claim 1, wherein said one or more circuits are operable to prevent said network device from decrypting data from any satellite dish other than said particular satellite dish.

3. The system of claim 1, wherein said one or more circuits are operable such that said security key is the only key that said network device can utilize for decrypting signals received via a particular interface and/or from a particular address.

4. The system of claim 1, wherein said security key is written to said one or more circuits while said one or more circuits are configured into a service mode.

5. The system of claim 1, wherein said security key is received via a link that is out-of-band with a link between said network device and said particular satellite dish.

6. The system of claim 1, wherein:

said one or more circuits comprise one-time-programmable (OTP) memory; and
said security key is stored in said OTP memory.

7. The system of claim 1, wherein:

said one or more circuits comprise an electrically erasable programmable read only memory (EEPROM); and
said security key is stored in said EEPROM.

8. The system of claim 1, wherein:

said one or more circuits comprise flash memory; and
said security key is stored in said flash memory.

9. A method comprising:

performing by one or more circuits in a network device: pairing with a particular satellite dish by storing a security key uniquely
associated with said particular satellite dish; receiving encrypted data from said particular satellite dish; decrypting said received encrypted data utilizing said security key.

10. The method of claim 9, comprising preventing said network device from decrypting data from any satellite dish other than said particular satellite dish.

11. The method of claim 9, wherein said security key is the only key that the network device can utilize for decrypting signals received via a particular interface and/or from a particular address.

12. The method of claim 9, comprising writing said security key to said one or more circuits while said one or more circuits are configured into a service mode.

13. The method of claim 9, comprising receiving said security key via a link that is out-of-band with a link between said network device and said particular satellite dish.

14. The method of claim 9, wherein:

said one or more circuits comprise one-time-programmable (OTP) memory; and
said storing comprises storing the security key in said OTP memory.

15. The method of claim 9, wherein:

said one or more circuits comprise an electrically erasable programmable read only memory (EEPROM); and
said storing comprises storing the security key in said EEPROM.

16. The method of claim 9, wherein:

said one or more circuits comprise flash memory; and
said security key is stored in said flash memory.

17. A system comprising:

one or more circuits collocated with a satellite dish, said one or more circuits being operable to: encrypt data utilizing a security key stored in said one or more circuits, wherein said security key is unique to said satellite dish; and transmit said encrypted data.

18. The system of claim 17, wherein said one or more circuits are operable to transmit said encrypted data over an Internet Protocol (IP) network.

19. The system of claim 17, wherein said security key can be read from said one or more circuits only while said one or more circuits are configured into a service mode.

20. The system of claim 17, wherein said one or more circuits are operable to transmit said security key to a network device while said one or more circuits are configured into a service mode.

21. The system of claim 17, wherein:

said one or more circuits comprise one-time-programmable (OTP) memory; and
said security key is stored in said OTP memory.

22. The system of claim 17, wherein:

said one or more circuits comprise an electrically erasable programmable read only memory (EEPROM); and
said security key is stored in said EEPROM.

23. The system of claim 17, wherein:

said one or more circuits comprise flash memory; and
said security key is stored in said flash memory.
Patent History
Publication number: 20120297415
Type: Application
Filed: Jan 20, 2012
Publication Date: Nov 22, 2012
Inventors: Brian Sprague (Irvine, CA), Curtis Ling (Carlsbad, CA)
Application Number: 13/354,640
Classifications
Current U.S. Class: With Encryption Or Scrambling Of Video Signal (725/31)
International Classification: H04N 21/2347 (20110101);