Source: http://www.google.com/patents/US8108680?dq=5,892,865
Timestamp: 2016-09-29 16:40:10
Document Index: 476843415

Matched Legal Cases: ['Application No. 2', 'Application No. 2', 'Application No. 08', 'Application No.7', 'Application No. 07', 'Application No. 07', 'Application No. 07', 'Application No. 07', 'Application No. 10', 'Application No. 10']

Patent US8108680 - Preventing unauthorized poaching of set top box assets - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsTo prevent poaching of an Internet Protocol (IP) set top box (STB) asset or similar network computing device from one system operator to another, code executing in the IP STB not only authenticates downloaded software images using a public key provided in a serial-number assigned digital certificate,...http://www.google.com/patents/US8108680?utm_source=gb-gplus-sharePatent US8108680 - Preventing unauthorized poaching of set top box assetsAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS8108680 B2Publication typeGrantApplication numberUS 11/781,412Publication dateJan 31, 2012Filing dateJul 23, 2007Priority dateJul 23, 2007Fee statusPaidAlso published asCA2694201A1, EP2174254A1, US20090031409, WO2009015116A1Publication number11781412, 781412, US 8108680 B2, US 8108680B2, US-B2-8108680, US8108680 B2, US8108680B2InventorsMark R. MurrayOriginal AssigneeMurray Mark RExport CitationBiBTeX, EndNote, RefManPatent Citations (122), Non-Patent Citations (37), Referenced by (7), Classifications (18), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetPreventing unauthorized poaching of set top box assets
US 8108680 B2Abstract
To prevent poaching of an Internet Protocol (IP) set top box (STB) asset or similar network computing device from one system operator to another, code executing in the IP STB not only authenticates downloaded software images using a public key provided in a serial-number assigned digital certificate, but also confirms that the serial number appears on a signed whitelist, or does not appear on a signed blacklist. The code executing in the STB further preferably enforces a rule that only the authority that signed the already-loaded whitelist/blacklist may replace it with a new list. Such a “sticky whitelist/blacklist” ensures that if the STB boots or resets in a new network, the existing authentication list will not be replaced by a list that is valid for a new or different network, and, as a result, that new software code images will not be authenticated.
1. A method for maintaining control over a set-top-box (STB) asset, comprising:
authenticating, using a hardware-based authentication process, a first software application, the first software application having been generated by a first party, wherein the STB asset is operated by a second party;
once authenticated, using the first software application to authenticate a public key received with a second software application that was generated by a third party and is intended to be run on the STB asset;
once authenticated, using the public key of the third party to authenticate the second software application generated by the third party; and
confirming that the second software application is authorized to be run on the STB asset by consulting a list of authorized third parties, wherein consulting the list of authorized third parties comprise utilizing a list maintenance code signing key (LMCSK) having a unique serial number always recognized by the hardware-based authentication process, and locating the third party that generated the second software application, wherein the list of authorized third parties is itself authenticated by the first software application using the LMCSK.
2. The method of claim 1, wherein the list comprises a plurality of serial numbers associated with the third parties.
3. The method of claim 1, further comprising restricting the ability to replace the list.
4. The method of claim 3, further comprising allowing replacement of the list only by a same signing authority that signed the list.
5. The method of claim 1, wherein said hardware-based authentication comprises authenticating a digital certificate using a public key embedded in hardware.
6. The method of claim 1, wherein the list is compiled in the STB asset.
7. The method of claim 1, wherein the list is downloaded from a server.
8. The method of claim 1, wherein the list is digitally signed with a private key belonging to the second party.
9. The method of claim 8, further comprising authenticating the digitally signed list using a public key compiled in the first software application.
10. The method of claim 8, wherein the first party is the asset hardware vendor.
11. The method of claim 8, wherein the second party is a content service provider.
12. The method of claim 11, wherein the second party is an IPTV service provider.
storing a first digitally signed list on an electronic device, the first digitally signed list including identification data for a plurality of software vendors authorized to load and run software on the electronic device;
receiving, at the electronic device, a second digitally signed list, the second digitally signed list also including identification data for a plurality of software vendors authorized to load and run software on the electronic device, wherein the identification data comprises a list maintenance code signing key (LMCSK) having a serial number unique to the signing authority that is always recognized by a bootloader;
determining that a signing authority that signed the second digitally signed list is the same as a signing authority that signed the first digitally signed list, wherein determining that the signing authority that signed the second digitally signed list is the same as the signing authority that signed the first digitally signed list comprises authorizing the LMCSK; and
replacing, utilizing the bootloader, the first digitally signed list with the second digitally signed list when it is determined that a signing authority that signed the second digitally signed list is the same as a signing authority that signed the first digitally signed list.
14. The method of claim 13, wherein the electronic device comprises a set top box.
15. The method of claim 13, wherein the first and second digitally signed lists are whitelists.
16. The method of claim 13, wherein said replacing is performed, at least in part, by a software program that has been authenticated via the bootloader.
receiving at a set top box a signed list of serial numbers, wherein the serial numbers respectively identify authorized digital certificates, and a digital certificate includes a public key associated with a developer of a code image;
storing the list of serial numbers in a memory of the set top box;
receiving at the set top box a signed replacement list of serial numbers and a list maintenance code signing key (LMCSK) having a serial number unique to the signing authority that is always recognized by a bootloader;
determining if a signing authority that signed the signed replacement list of serial numbers is the same as a signing authority that signed the list of serial numbers; and
replacing, utilizing the bootloader, the list of serial numbers with the list of serial numbers from the signed replacement list of serial numbers when the signing authority that signed the signed replacement list of serial numbers is the same as a signing authority that signed the list of serial numbers.
18. The method of claim 17, wherein the same signing authority is a system operator for the set top box.
19. The method of claim 17, wherein said replacing is performed, at least in part, by a software program that has been authenticated via a hardware-enforced authentication mechanism.
20. A set-top-box (STB), comprising:
a public key embedded in a hardware device in the STB; and
software code stored and operable on the STB to authenticate, based at least in part on the public key embedded in the hardware device and a stored list of authorized software vendors and a list maintenance code signing key (LMCSK) having a serial number unique to the signing authority that is always recognized by the hardware device, a software image downloaded from a server and prepared by one of a plurality of software vendors, the software code further operable to replace the stored list of authorized software vendors only when a new list of authorized software vendors is signed by a same signing authority that signed the stored list of authorized software vendors and recognized by the LMCSK.
21. The set-top-box of claim 20, wherein the set-top-box communicates over an internet protocol (IP) network.
22. The set-top-box of claim 20, wherein the set-top-box is operable with an internet protocol (IP) television (IPTV) system.
23. The set-top-box of claim 20, wherein the software code is operable to receive the new list of authorized software vendors from a download server. Description
The present disclosure relates generally to methods for providing enhanced control over set top boxes.
System operators, such a cable television service providers or content providers, generally, often provide set top boxes (STBs) to customers. STBs are generally connected between an incoming physical cable, wire, or other broadband connection and a nearby television set (or computer). As is well-known, STBs are conventionally used to, for example, demodulate and unscramble (as necessary) signals for standard television, pay per view, video on demand, gaming data, and other content that is broadcast from a head end of the system operator. The incoming data may be encoded in accordance with, for example, the Internet Protocol (IP) and be compliant with emerging IP television (“IPTV”) systems.
System operators invest significantly in purchasing STBs, and then installing the STBs on customer premises. While a system operator may, over time, recoup the cost of the STBs through subscription fees, it may be months or even years before the cost associated with a given STB and its installation is fully recaptured. It is therefore particularly frustrating for an incumbent system operator when a competing system operator is not only able to convince a given customer to switch service to the competing system operator, but is also able to use (or “poach”) the incumbent system operator's STB that is already in place on the customer premises. To the extent the incumbent system operator has not already recaptured the cost of the STB, that cost may be forever lost.
It is therefore desirable to provide a methodology or technique to better control STB assets belonging to an incumbent system operator.
Embodiments of the present invention reduce or eliminate the possibility that a competing system operator that uses Internet Protocol set top boxes supplied from the same hardware vendor can poach the incumbent system operator's IP STBs into the competing system operator's network.
In accordance with embodiments of the invention, an IP STB preferably includes a code authentication mechanism that is built into an operating system-like program, referred to herein as “Bootloader code” or “the Bootloader.” One function of the Bootloader is to ensure that any code executed on the STB is authenticated by a hardware vendor authorized signing key. The Bootloader recognizes a downloadable “whitelist” or “blacklist” that lists serial numbers associated with keys that are permitted (white) or not permitted (black) to be authenticated on the STB. The authentication list may be signed and authenticated by the hardware vendor's authorized signing key.
As noted, it is possible that an STB may be poached (i.e., transferred without functional impairment) from one system to another. For this to occur, the Bootloader may download a new version of software (properly authorized by the hardware vendor signing keys) and thus allow the transition from one operator network to another. Even if an authentication list is used, a new authentication list could be downloaded and enforced by the STB when it is powered on or is reset in the new network.
To reduce the possibility of poaching, the Bootloader in the STB preferably enforces a rule that only the authority that signed the current whitelist may replace it with a new whitelist. Such a “sticky whitelist” ensures that if the STB boots or resets in a new network, the existing authentication list will not be replaced by the list valid for the new network, and will not, accordingly, authenticate any code images from that network. This technique assumes that system operators require that their software providers use different signing keys for actual code images.
In an embodiment, a special hardware vendor-signed message can be used to remove an existing list to facilitate an authorized transition of STB asset from one system operator to another in the event of key loss, asset purchase, corporate merger, or other authorized instance.
FIG. 1 depicts a hardware-enforced authentication mechanism in accordance with embodiments of the present invention.
FIGS. 2 and 3 illustrate how a chain of trust is established in accordance with embodiments of the present invention.
FIG. 4 illustrates a key signing process in accordance with embodiments of the present invention.
FIG. 5 illustrates a code signing process in accordance with embodiments of the present invention.
FIG. 6 illustrates an authentication process in accordance with embodiments of the present invention.
FIG. 7 illustrates a list signing process in accordance with embodiments of the present invention.
An Internet Protocol (IP) set top box (STB) (“IP STB” or, more simply “STB”) typically includes basic operating code that is embedded within, e.g., a ROM of an integrated circuit or chip and that is operable to load other, executable, software code into RAM, such as a flash memory. In the case of an IP STB, an operating system-like routine is typically initially loaded on the STB and operates to load and execute still other software code. The operating system-like code of the IP STB is referred to herein as “Bootloader code,” or, more simply, “the Bootloader.” STBs that include such Bootloader code are designed and sold by, e.g., Scientific-Atlanta (Lawrenceville, Ga.). These STBs are installed, e.g., by cable television or telephone service providers or the like, on customer premises. Those skilled in the art will appreciate that the embodiments described herein are applicable to any “provider” that delivers content to a STB, or similar device.
In addition to the embedded operating code and the Bootloader code, service providers may also load other software on the IP STB to, for example, interact with a headend of the service provider, among other things. This additional software may be the service provider's own code, or more frequently, code generated by a third party. If the STBs are already in the field, the additional software may be delivered to the STBs using a broadcast technique. Notably, in allowing third party software to be loaded on STBs, there is the potential that corrupted, or worse, malicious software may be proliferated.
To ensure that only authorized software is loaded and executed on the STB, a software code image authentication mechanism may be implemented using a public-private key pair scheme along with digital certificates. Initially, in a preferred implementation, a root chain-of-trust on the set top box is established by a hardware-enforced mechanism that begins by authenticating the Bootloader itself before any other code execution is permitted.
FIG. 1 illustrates a series of steps for implementing the hardware-enforced authentication mechanism. At step 110, a STB hardware vendor generates a public-private key pair, referred to as the “Bootloader Signing Key,” and then at step 112, sends the public key portion thereof to, e.g., a chip manufacturer whose chips are to be incorporated in the STB asset. As those skilled in the art will appreciate, the chip manufacturer may then function as a “certificate authority” whereby, at step 114, the chip manufacturer signs the public key portion with its own chip manufacturer private key and returns a resulting digital certificate to the STB hardware vendor.
At step 116, in the course of manufacturing the integrated circuit (i.e., chip) for the STB, the manufacturer embeds its own public key in the circuit hardware. Meanwhile, at step 118, the STB hardware vendor develops the Bootloader code and at step 120 signs the code with its own private key, and then bundles the signed Bootloader code with the digital certificate previously received from the chip manufacturer, and loads these components in the flash memory or RAM of the STB. At step 122, when the STB thereafter powers up or is reset, the chip manufacturer's public key that is embedded in the chip is used to authenticate the digital certificate that is bundled with the Bootloader code, thereby authenticating the public key portion of the Bootloader signing key. The Bootloader code can then be properly authenticated with that public key. The procedure described above establishes a first link in a chain-of-trust, where the first link is considered to be a hardware-based authentication link.
Stated alternatively, if the Bootloader is executing on the STB, then the hardware-enforced security mechanism must have “passed” and the Bootloader is thereafter “trusted.” As will be explained in more detail below, a further chain-of-trust thereafter flows from this first hardware-enforced authentication mechanism to different keys, certificates and code.
FIG. 2 depicts a series of steps that illustrate a chain of trust for authenticating different software components, lists and keys that are intended to be run or used on the STB. Step 202 represents the hardware enforced authentication that is based on the STB hardware vendor's Bootloader Signing Key and that was described with respect to FIG. 1. The chain-of-trust may then be extended to other authorities through a series of key signing processes. In an embodiment, and as depicted by step 204, the STB hardware vendor itself may act as a certificate authority by signing a third Party Signing Key (i.e., signing a third party's public key) using a Key Signing Key (“KSK”) and returning a digital certificate, referred to as a “Key Signing Key Certificate” or “KSK Certificate,” to an authorized third party. In accordance with an embodiment, each such KSK Certificate includes an embedded serial number that is associated with the third party. As will be explained more fully below, the KSK may also be used to sign a List Signing Key (LSK) that itself is used to authenticate a list of serial numbers.
An authorized third party may then sign its own software code (or image) using its own Third Party Signing Key and embed the KSK Certificate in the resulting software image, as shown by step 206. At run-time, as represented by step 208, the Bootloader extends trust to the software image by first authenticating the embedded KSK Certificate, and then using the public key from the certificate to authenticate the software image itself. The Bootloader may also, in a similar fashion, authenticate a whitelist or blacklist. Details of such a process are described later herein.
FIGS. 3-7 depict in more detail the several signing and authentication processes, and practical effects thereof, in accordance with embodiments of the invention.
As shown in FIG. 3, a KSK public key 312 a is compiled as part of the Bootloader and is used to establish the authenticity of the third party public key 310 a, which is treated as data at this point. If the key signature 314 (which has been encrypted with a KSK private key 312 b) passes, then the third party public key can be trusted as authentic (since it was signed by the private KSK). The third party public key 310 a and KSK Signature 314 are elements of the KSK Certificate 404 (described below).
The third party now-“trusted” public key 310 a is then used to establish the authenticity of a code image 318. If a code signature 320 (which has been encrypted using the third party's private key 310 b) passes, then trust can be extended to the code image 318 (since it was signed by the third party private key, whose public key portion has been authenticated).
Key Signing Process
As shown by FIG. 4, a key signing process 400 is employed to sign the third party public key 310 a (its private key 312 b being held in confidence) and a serial number 402 using the KSK private key 312 b (recalling that the KSK public key 312 a is compiled in the Bootloader). The resulting output file is a “KSK Certificate” 404, which includes a copy of the third party public key 310 a, the serial number 402, and a signature of the data 314. Those skilled in the art will appreciate that there may be additional header fields associated with KSK Certificate 404 to ensure file corruption can be detected before any “bad” data is used.
The KSK Certificate 404 is provided to the third party and is used in subsequent code-signing steps, as explained below. The KSK Certificate need not be kept secret.
When a third party has been given a serial number-controlled KSK Certificate 404, the third party then has the ability to sign its own code images, as shown by the process 500 depicted in FIG. 5. Specifically, software code (or simply “code”) 318 is signed by the third party's private key 310 b and the data from the KSK Certificate 404 is copied into the output image file 510. The third party private key 310 b is used to generate a signature 320 for the code block. The code 318, KSK Certificate data 404, and code signature 320 are all packaged into a single image file 510 along with additional header bytes (not shown) that can be used to detect file corruption that can occur in transport. This signed code image file 510 can then be provided to a Download Server for broadcasting and loading into, e.g., flash memory on STBs.
Code Validation Process
As shown in FIG. 6, the Bootloader authenticates the signed code image file 510 immediately after download, before committing it to memory, or allowing it to execute on the STB, or combinations thereof. More specifically, the Bootloader uses the code header data along with the public key of the KSK, compiled-in the Bootloader, to authenticate the code image. This process was described in connection with FIG. 3.
As will be explained in more detail below, an optional blacklist/whitelist listing unique serial numbers of KSK Certificates can be used to reject authority for any particular serial number that is associated with a KSK Certificate, thereby rejecting the authority of a given third party vendor to have its code loaded on the STB.
List Signing Process
FIG. 7 shows how signing authority can be revoked/blacklisted (or expressly given/whitelisted) using a whitelist/blacklist mechanism. As shown, a list of serial numbers (previously assigned to respective third party vendors) in a whitelist or blacklist 701 is signed by process 700 using a private key portion 710 b of a List Signing Key (“LSK”), resulting in a signed whitelist/blacklist 702 that is then downloaded and stored in the memory of the STB for reference by the Bootloader. FIG. 2 shows how the LSK is used to authenticate a whitelist/blacklist.
Referring back to FIG. 6, when signed code image file 510 is received at the STB, the Bootloader not only authenticates the code image, but also may consult the signed whitelist/blacklist 702 to determine if a serial number on that list corresponds to the serial number 402 of the code image 510. If the serial number is listed in a whitelist, then the Bootloader will allow the code to be installed and/or executed, otherwise it may be rejected. If the serial number is listed on a blacklist, then the Bootloader will reject the code image 510, otherwise it may be accepted.
The whitelist or blacklist 701 comprising serial numbers that can be used to revoke signing authority to particular third party keys must be available to the Bootloader at the time a given code image is authenticated. Consequently, the list may be compiled-in the Bootloader or downloaded any time before code is downloaded. A compiled-in list is secure in that it cannot be tampered with because it is part of the hardware enforced authentication mechanism.
If the list is downloaded, the LSK private key used for signing the list ensures the content is not altered. On the other hand, the download mechanism or flash memory storage table could possibly be interfered with. For example, if the list were prevented from being loaded at all into flash memory, then the Bootloader would not know to reject a given serial number that was listed on the list that was blocked. Thus, a downloaded blacklist is a “best effort” method of authority revocation. A compiled-in list may be considered more secure.
Another approach, but still possibly vulnerable, is to require all serial numbers to be whitelisted. Thus, if the external list is removed or tampered with then authority can only be lost and not gained. However, if authority were granted to a given serial number in one version of the file and later revoked in a later version of the file, authority could be restored by re-flashing the original list back into flash memory.
In an example implementation, the STB recognizes a whitelist on a STB Download server associated with the headend of the system provider. As explained above, upon download this list is authenticated using the same third party trust mechanism that is used to authenticate software images. In accordance with a particular embodiment of the invention, after a whitelist is loaded into the STB, a new list only from the same signing authority (serial number) can replace the earlier-downloaded list. As mentioned earlier, the initial whitelist that is loaded into a STB can be put in place explicitly before STB delivery, or may be loaded on first-boot in the host network. In one possible implementation, when an STB boots without any whitelist in place, then any STB-authorized Third Party Certificate may be accepted. However, once a whitelist has been received and stored, only the third party key serial number for the LSK used to sign the stored list will be recognized for list replacement.
White List Removal
A List Maintenance Code Signing Key (“LMCSK”) may always be authorized even if not included in the whitelist. More specifically, a utility may be provided to account for when it is necessary to remove the whitelist in, for example, a customer repair facility in order to allow diagnostic software to be loaded or to allow for repaired STBs to be re-deployed in a new network. For example, a “Whitelist Delete Application” may be created and signed by the LMCSK. Once the application is executing, it may contact a secure server on a local network to identify the STB and receive permission to remove the whitelist. The messages exchanged ensure mutual authentication and generate a delete request for that single STB. In a preferred implementation, only authorized repair centers will have such a secure server. Alternatively, the server may be operated by a third party, e.g., the STB hardware vendor, and the authentication may be performed over a network. The LMCSK is the same as a 3 d party Code Signing Key except that it has a special or unique serial number recognized by the Bootloader.
On occasion, it may also be desirable to remove the whitelist of a large population of STBs in the field to facilitate the authorized acquisition of assets containing conflicting whitelists or to recover from a lost LSK. For example, one service provider may legitimately acquire the customers and assets of another service provider and thus acquire all of the STBs of the other service provider.
In this scenario, a “WhiteList Delete Message” may be signed by the List Removal Key (“LRMK”) and be placed on the STB Download Server. The message preferably contains the list of the LSK serial numbers targeted for removal. For security purposes, after the use of such a WhiteList Delete Message the targeted LSK Keys mentioned in the message should no longer be used. The LRMK is the same as a LSK except that it has a special or unique serial number recognized by the Bootloader.
To summarize, when no whitelist or blacklist is loaded in an STB, any authentic third party certificate can be used to download Software or whitelists/blacklists. When either list is already loaded in an STB, it is preferable that only the third party certificate that signed the saved list can be used to replace it. Further, in accordance with a preferred embodiment, only third party certificate serial numbers listed in the whitelist/blacklist may be accepted for authentication.
There is also a scenario where a repair facility may obtain STBs from several different system operators, where the STBs would have different whitelists/blacklists stored. It may be desirable for the repair facility to restore the STBs back to their “factory-fresh” state (i.e. no whitelist/blacklist at all). However, it would be unlikely that all operators could be convinced to white-list the serial number of the repair software (and, in fact, from a security perspective, it would be prudent if they excluded it). Further, if the STB hardware vendor had a master-key to remove the lists (or any software for that matter), that would represent a security vulnerability. To address these issues, embodiments of the present invention provide the following method to remove whitelists/blacklists at a repair facility.
In accordance with an embodiment, the list-removal software application, before it will actually remove the list, communicates with a PC-based “Authentication Server” to get permission. The Authentication Server can be located anywhere physically, e.g., at the repair facility or at a central location.
The server itself may include complex rules regarding which serial numbers are permitted. An audit trail of the server's activities is preferably kept. The server also preferably has a private-key token card of some sort that can be used to encrypt or sign data. The practical effect of the token is that “private key” encryption allows a client (i.e., the STB in this case) to authenticate that the server it is talking to has a valid private key by using the compiled-in public key to authenticate it. Private keys are presumed to be tightly controlled, never exposed, and mathematically impractical to reverse-engineer. Accordingly, if there is evidence that an entity correctly performed an encryption using the private key, that entity can be trusted.
The removal software application running in the STB may generate a random block of data, send it to the authentication server along with serial number information and challenge it to return a valid response. The Authentication server then uses the private key to encrypt (or sign) the random data and send it back to the STB software. The STB software uses the public key to decrypt (or signature check) the response to confirm that whomever it is talking to does indeed have the private key. The random data prevents a “record-and-playback” attack—ensuring every exchange will be unique.
Once the STB software authenticates, it can communicate with the Authorization Server and, with permission, it will then execute the function to remove the list(s) from secure storage.
A goal of the sequence described above is to make sure that the list-removal software application in the STB that is signed with the LMCSK (always white-listed) becomes inert in the absence of the authentication server. In other words, if someone at a repair facility were to steal the software signed with the LMCSK, it would be of no use without the Authentication Server. The Authentication server is preferably secured in a locked room and may be local or at an offsite location.
In one implementation, a STB hardware vendor-Signed Delete Message may be used to remove a specific whitelist, and a STB hardware vendor-Signed Delete Application may be used to remove individual whitelists in a repair facility with a secure server.
The systems and methods described herein may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative and not meant to be limiting.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5224161Nov 8, 1989Jun 29, 1993Laboratoir Europeen De Recherches Electroniques Avancees, Societe En Nom CollectifMethod of scrambling and of unscrambling composite video signals, and device for implementationUS5349641Aug 12, 1993Sep 20, 1994France Telecom Establissement Autonome De Droit PublicProcess for the transmission and reception of conditional access programmes with a reduced programme switching timeUS5742677Apr 3, 1995Apr 21, 1998Scientific-Atlanta, Inc.Information terminal having reconfigurable memoryUS5870474Dec 29, 1995Feb 9, 1999Scientific-Atlanta, Inc.Method and apparatus for providing conditional access in connection-oriented, interactive networks with a multiplicity of service providersUS5933503Mar 15, 1996Aug 3, 1999Novell, IncControlled modular cryptography apparatus and methodUS6005938Dec 16, 1996Dec 21, 1999Scientific-Atlanta, Inc.Preventing replay attacks on digital information distributed by network service providersUS6012068 *Jun 30, 1997Jan 4, 2000International Business Machines CorporationMedia manager for access to multiple media typesUS6020982Oct 8, 1993Feb 1, 2000Kabushiki Kaisha ToshibaImage data processing apparatus for digitally reproducing optical image dataUS6105134Jul 31, 1998Aug 15, 2000Scientific-Atlanta, Inc.Verification of the source of program information in a conditional access systemUS6148082Jan 14, 1998Nov 14, 2000Skystream CorporationScrambling and descrambling control word control in a remultiplexer for video bearing transport streamsUS6157719Jul 31, 1998Dec 5, 2000Scientific-Atlanta, Inc.Conditional access systemUS6173400Jul 31, 1998Jan 9, 2001Sun Microsystems, Inc.Methods and systems for establishing a shared secret using an authentication tokenUS6230269Mar 4, 1998May 8, 2001Microsoft CorporationDistributed authentication system and methodUS6246767Jan 20, 2000Jun 12, 2001Scientific-Atlanta, Inc.Source authentication of download information in a conditional access systemUS6252964Jan 20, 2000Jun 26, 2001Scientific-Atlanta, Inc.Authorization of services in a conditional access systemUS6292568Jan 19, 2000Sep 18, 2001Scientific-Atlanta, Inc.Representing entitlements to service in a conditional access systemUS6345307Nov 12, 1999Feb 5, 2002General Instrument CorporationMethod and apparatus for compressing hypertext transfer protocol (HTTP) messagesUS6356971Mar 4, 1999Mar 12, 2002Sony CorporationSystem for managing multimedia discs, tracks and files on a standalone computerUS6424714Aug 18, 1998Jul 23, 2002Scientific-Atlanta, Inc.Method and apparatus for providing conditional access in connection-oriented interactive networks with a multiplicity of service providersUS6424717Dec 16, 1999Jul 23, 2002Scientific-Atlanta, Inc.Encryption devices for use in a conditional access systemUS6510519Jun 14, 2001Jan 21, 2003Scientific-Atlanta, Inc.Conditional access systemUS6516412Mar 16, 2001Feb 4, 2003Scientific-Atlanta, Inc.Authorization of services in a conditional access systemUS6526508Dec 26, 2000Feb 25, 2003Scientific-Atlanta, Inc.Source authentication of download information in a conditional access systemUS6560340Jan 28, 2000May 6, 2003Scientific-Atlanta, Inc.Method and apparatus for geographically limiting service in a conditional access systemUS6574609Sep 14, 1998Jun 3, 2003International Business Machines CorporationSecure electronic content management systemUS6727944Feb 26, 1999Apr 27, 2004Fuji Photo Film Co., LtdDigital electronic still-video camera and method of controlling operation of sameUS6744892Mar 3, 2003Jun 1, 2004Scientific-Atlanta, Inc.Method and apparatus for geographically limiting service in a conditional access systemUS6748080May 24, 2002Jun 8, 2004Scientific-Atlanta, Inc.Apparatus for entitling remote client devicesUS6804357Apr 28, 2000Oct 12, 2004Nokia CorporationMethod and system for providing secure subscriber content dataUS6937729Aug 16, 2001Aug 30, 2005Scientific-Atlanta, Inc.Representing entitlements to service in a conditional access systemUS6970564Jun 7, 2000Nov 29, 2005Sony CorporationData multiplexing device, program distribution system, program transmission system, pay broadcast system, program transmission method, conditional access system, and data reception deviceUS6971008Nov 5, 2002Nov 29, 2005Scientific-Atlanta, Inc.Authorization of services in a conditional access systemUS7062658Sep 10, 2001Jun 13, 2006Cisco Technology, IncSecure digital appliance and method for protecting digital contentUS7065216Aug 11, 2000Jun 20, 2006Microsoft CorporationMethods and systems of protecting digital contentUS7124303Jan 2, 2002Oct 17, 2006Sony CorporationElementary stream partial encryptionUS7127619Jan 2, 2002Oct 24, 2006Sony CorporationDecoding and decryption of partially encrypted informationUS7151831 *Jan 2, 2002Dec 19, 2006Sony CorporationPartial encryption and PID mappingUS7155609Jun 14, 2001Dec 26, 2006Microsoft CorporationKey exchange mechanism for streaming protected media contentUS7181010Mar 6, 2003Feb 20, 2007Scientific-Atlanta, Inc.Apparatus for entitling remote client devicesUS7200868Sep 12, 2002Apr 3, 2007Scientific-Atlanta, Inc.Apparatus for encryption key managementUS7287168Jun 26, 2006Oct 23, 2007Sony CorporationPartial encryption and PID mappingUS7505592Feb 6, 2007Mar 17, 2009Scientific-Atlanta, Inc.Apparatus for entitling and transmitting service instances to remote client devicesUS7515712Mar 25, 2005Apr 7, 2009Cisco Technology, Inc.Mechanism and apparatus for encapsulation of entitlement authorization in conditional access systemUS7636846 *Jun 5, 1998Dec 22, 2009Uqe LlcGlobal conditional access system for broadcast servicesUS7949133May 24, 2011Pinder Howard GControlled cryptoperiod timing to reduce decoder processing loadUS20010006400Dec 5, 2000Jul 5, 2001Hiroaki KuboCameraUS20020013772Jun 27, 2001Jan 31, 2002Microsoft CorporationBinding a digital license to a portable device or the like in a digital rights management (DRM) system and checking out / checking in the digital license to / from the portable device or the likeUS20020018130Jan 11, 2001Feb 14, 2002Kazunori SuemotoApparatus for capturing image, its method of recording data, and recording mediumUS20020026582Aug 30, 2001Feb 28, 2002Sony CorporationPerson authentication system, person authentication method and program providing mediumUS20020099663Oct 31, 2001Jul 25, 2002Kenji YoshinoContent delivery system and content delivery methodUS20020101990Feb 27, 2001Aug 1, 2002Harumi MorinoData receiving apparatus and data reproducing apparatusUS20020108122 *May 16, 2001Aug 8, 2002Rachad AlaoDigital television application protocol for interactive televisionUS20020146237Apr 6, 2001Oct 10, 2002General Instrument CorporationPortable content by way of a set-top device/home-gatewayUS20020196939 *Jan 2, 2002Dec 26, 2002Unger Robert AllanDecoding and decryption of partially encrypted informationUS20030009668Jun 14, 2001Jan 9, 2003Chan Shannon J.Key exchange mechanism for streaming protected media contentUS20030021412Jan 2, 2002Jan 30, 2003Candelore Brant L.Partial encryption and PID mappingUS20030026423Jan 2, 2002Feb 6, 2003Unger Robert AllanCritical packet partial encryptionUS20030035543Aug 15, 2001Feb 20, 2003Gillon William M.System and method for conditional access key encryptionUS20030046686Jan 2, 2002Mar 6, 2003Candelore Brant L.Time division partial encryptionUS20030081776 *Jan 2, 2002May 1, 2003Candelore Brant L.Elementary stream partial encryptionUS20030093680Nov 13, 2001May 15, 2003International Business Machines CorporationMethods, apparatus and computer programs performing a mutual challenge-response authentication protocol using operating system capabilitiesUS20030145329Dec 13, 2002Jul 31, 2003Candelore Brant L.Selective encryption for video on demandUS20030159140Dec 13, 2002Aug 21, 2003Candelore Brant L.Selective encryption to enable multiple decryption keysUS20030174837Dec 13, 2002Sep 18, 2003Candelore Brant L.Content replacement by PID mappingUS20030182579Aug 24, 2001Sep 25, 2003David LeporiniTransmitting and processing protected contentUS20030188164Mar 27, 2002Oct 2, 2003General Instrument CorporationSmart card mating protocolUS20030233558 *Jun 13, 2002Dec 18, 2003Microsoft CorporationSystem and method for securely booting from a networkUS20040022307Jul 31, 2002Feb 5, 2004Broadcom CorporationTurbo-coding DOCSIS information for sate ilite communicationUS20040052377Sep 12, 2002Mar 18, 2004Mattox Mark D.Apparatus for encryption key managementUS20040073917Mar 31, 2003Apr 15, 2004Sony CorporationSystem and method for partially encrypted multimedia streamUS20040098591Nov 15, 2002May 20, 2004Fahrny James W.Secure hardware device authentication methodUS20040098603Jun 6, 2003May 20, 2004Corinne Le BuhanMethod and device for the recognition of the origin of encrypted data broadcastingUS20040123094Nov 13, 2003Jun 24, 2004Eric SprunkEfficient distribution of encrypted content for multiple content access systemsUS20040128499Dec 30, 2002Jul 1, 2004General Instrument CorporationSystem for digital rights management using distributed provisioning and authenticationUS20040187014Mar 18, 2003Sep 23, 2004Molaro Donald JosephMethod and system for implementing digital rights managementUS20040228175Mar 31, 2004Nov 18, 2004Candelore Brant L.Configurable cableCARDUS20050080497Oct 8, 2003Apr 14, 2005Rao Ram R.Gradually degrading multimedia recordingsUS20050091173Oct 24, 2003Apr 28, 2005Nokia CorporationMethod and system for content distributionUS20050100162Nov 11, 2003May 12, 2005Jukka AlveSystem and method for using DRM to control conditional access to DVB contentUS20050102513Nov 10, 2003May 12, 2005Nokia CorporationEnforcing authorized domains with domain membership vouchersUS20050102702Feb 9, 2004May 12, 2005Candelore Brant L.Cablecard with content manipulationUS20050105732Nov 12, 2004May 19, 2005Hutchings George T.Systems and methods for delivering pre-encrypted content to a subscriber terminalUS20050169473Oct 13, 2004Aug 4, 2005Candelore Brant L.Multiple selective encryption with DRMUS20050180568Mar 31, 2005Aug 18, 2005Krause Edward A.Time-multiplexed multi-program encryption systemUS20050192904Apr 1, 2005Sep 1, 2005Candelore Brant L.Selective encryption with coverage encryptionUS20050201559Apr 23, 2003Sep 15, 2005Van Der Heijden Gerardus Wilhelmus T.Conditional access systemUS20050237396Apr 26, 2005Oct 27, 2005Kabushiki Kaisha ToshibaData recording apparatus and electronic cameraUS20050240974Mar 28, 2005Oct 27, 2005Takuji HiramotoProcessing terminal, receiving terminal and received data processing systemUS20060020786Jul 20, 2004Jan 26, 2006William HelmsTechnique for securely communicating and storing programming material in a trusted domainUS20060039256May 25, 2005Feb 23, 2006Taku NakamuraStoring apparatusUS20060041905Aug 18, 2004Feb 23, 2006Wasilewski Anthony JRetrieval and transfer of encrypted hard drive content from DVR set-top boxesUS20060072752Sep 27, 2005Apr 6, 2006Hiroyuki NakanoBroadcast receiving apparatus and broadcast receiving methodUS20060074807Oct 6, 2004Apr 6, 2006Sony CorporationMethod and system for content sharing and authentication between multiple devicesUS20060115083Nov 18, 2005Jun 1, 2006Candelore Brant LPartial encryption and PID mappingUS20060153379Nov 18, 2005Jul 13, 2006Candelore Brant LPartial encryption and PID mappingUS20060179478Dec 15, 2005Aug 10, 2006Samsung Electronics Co., Ltd.Method of controlling content access and method of obtaining content key using the sameUS20060187951Feb 1, 2005Aug 24, 2006Intel CorporationApparatus and method of controlling transmission of response frameUS20060200865Mar 7, 2005Sep 7, 2006International Business Machines CorporationSystem, service, and method for enabling authorized use of distributed content on a protected mediaUS20060262926Jun 26, 2006Nov 23, 2006Candelore Brant LTime division partial encryptionUS20060269060Jun 26, 2006Nov 30, 2006Candelore Brant LPartial encryption and PID mappingUS20070099694 *Oct 31, 2005May 3, 2007Sbc Knowledge Ventures L.P.System and method to deliver video gamesUS20070150960Dec 23, 2003Jun 28, 2007Gilles DubroeucqMethod and system for conditional access applied to protection of contentUS20070189525Feb 14, 2007Aug 16, 2007Irdeto Access B.V.Method and system providing scrambled contentUS20070192586Mar 9, 2004Aug 16, 2007Mcneely David LSecure data transmission via multichannel entitlement management and controlUS20070204146Apr 30, 2007Aug 30, 2007Pedlow Leo M JrSystem and method for partially encrypted multimedia streamUS20070291940Feb 20, 2007Dec 20, 2007Candelore Brant LSelective encryption encodingUS20070294170Jun 2, 2006Dec 20, 2007Luc VantalonSystems and methods for conditional access and digital rights managementUS20070294178Jun 16, 2006Dec 20, 2007Scientific Atlanta, Inc.Securing media content using interchangeable encryption keyUS20080005030Jun 30, 2006Jan 3, 2008Scientific-Atlanta, Inc.Secure Escrow and Recovery of Media Device Content KeysUS20080137852May 2, 2007Jun 12, 2008Rajesh MamidwarMethod and system for a transport single key change point for all package identifier channelsUS20080170687Apr 25, 2006Jul 17, 2008Koninklijke Philips Electronics, N.V.Device for and a Method of Processing an Encrypted Data StreamUS20080177998 *Jan 24, 2007Jul 24, 2008Shrikant ApsangiApparatus and methods for provisioning in a download-enabled systemUS20090028327Jul 27, 2007Jan 29, 2009Scientific-Atlanta, Inc.Secure content key distribution using multiple distinct methodsUS20090031409Jul 23, 2007Jan 29, 2009Murray Mark RPreventing Unauthorized Poaching of Set Top Box AssetsUS20090080648Sep 26, 2007Mar 26, 2009Pinder Howard GControlled cryptoperiod timing to reduce decoder processing loadEP0782296A2Dec 9, 1996Jul 2, 1997Ncr International Inc.Securing transmission and receipt of electronic dataEP1014715A2Dec 13, 1999Jun 28, 2000NEC CorporationDevice for recording video signals and device for displaying electronic program guideEP1447983A1Jan 22, 2004Aug 18, 2004Thomson Licensing S.A.Method of recording scrambled digital data, storage medium and method of reading such dataEP1760619A1Aug 19, 2005Mar 7, 2007STMmicroelectronics Ltd.System for restricting data accessEP2403586A1Mar 5, 2010Jan 11, 2012Neuralieve, Inc.Method and apparatus to record and analyze tms treatments and resultsWO2000050978A Title not availableWO2009015116A1Jul 22, 2008Jan 29, 2009Scientific-Atlanta, Inc.Preventing unauthorized poaching of set top box assets* Cited by examinerNon-Patent CitationsReference1"Explorer 8300 Series Digital Recorder" ScientificAtlanta.com [online] Oct. 2005, XP002459851, Retrieved from Internet: URL:http://www.cisco.com/application/pdf/en/us/guest/products/ps8613/c1650/cdc-cont-0900aecd806c6913.pdf [retrieved Nov. 22, 2007].2"Explorer 8300 Series Digital Recorder" ScientificAtlanta.com [online] Oct. 2005, XP002459851, Retrieved from Internet: URL:http://www.cisco.com/application/pdf/en/us/guest/products/ps8613/c1650/cdc—cont—0900aecd806c6913.pdf [retrieved Nov. 22, 2007].3Canadian Office Action dated Aug. 24, 2011 cited in Application No. 2,655,114.4Canadian Office Action dated Aug. 29, 2011 cited in Application No. 2,655,530.5EP Communication dated May 6, 2010 in Application No. 08 833 391.9-1244.6EP Summons to Attend Oral Proceedings dated Apr. 4, 2011 in Application No.7European Decision to Refuse dated Jul. 26, 2011 cited in Application No. 07 815 092.7-1245.8European Office Action mailed Jun. 9, 2009 in Application No. 07 815 092.7.9European Office Action mailed May 7, 2009 in Application No. 07 840 308.6.10European Office Action mailed Sep. 9, 2010 in Application No. 07 840 308.6.11Gilo: "Do It Yourself Making an External Hard Drive Guide" Notebookreview.com [online], Jun. 2, 2006, XP002459852, Retrieved from Internet: URL:http://www.notebookreview.com/default.asp?newsID=2972 [retrieved on Nov. 22, 2007].12International Preliminary Report mailed Jan. 6, 2009 in PCT/US2007/072328.13International Preliminary Report on Patentability dated Mar. 30, 2010 in PCT/US2008/077157.14International Search Report and Written Opinion mailed Sep. 16, 2008 in PCT/US2008/070707.15International Search Report dated Apr. 28, 2009 in PCT/US2008/077157.16International Search Report dated Dec. 12, 2008 in PCT/US2008/070690.17International Search Report dated Jan. 31, 2008 in PCT/US2007/070680.18International Search Report for PCT/US2008/070707, Sep. 16, 2008.19Korean Notice of Final Rejection dated Jul. 28, 2011 cited in Application No. 10-2008-7030549.20Korean Notice of Rejection dated Oct. 25, 2010 in Application No. 10-2008-7030549.21Office Action mailed Apr. 13, 2010, in U.S. Appl. No. 11/454,421.22Office Action mailed Apr. 14, 2010, in U.S. Appl. No. 11/428,367.23Office Action mailed Oct. 7, 2009, in U.S. Appl. No. 11/428,367.24Office Action mailed Sep. 22, 2009, in U.S. Appl. No. 11/454,421.25U.S. Appl. No. 09/111,958, filed Jul. 8, 1998, entitled "Mechanism and Apparatus for Encapsulation of Entitlement Authorization in Conditional Access System," Inventor: Defreese.26U.S. Appl. No. 10/789,337, fled Feb. 27, 2004, "Secure Negotiation and Encryption Module," Inventor: Sedacca.27U.S. Appl. No. 10/981,347, filed Mar. 25, 2003, entitled "Mechanism and Apparatus for Encapsulation of Entitlement Authorization in a Conditional Access System," Inventor: Defreese.28U.S. Appl. No. 11/428,367, filed Jun. 30, 2006, entitled "Secure Escrow and Recovery of Media Device Content Keys," Inventor: Schlarb.29U.S. Appl. No. 11/464,421, filed Jun. 16, 2006, entitled "Securing Media Content Using Interchangeable Encryption Key," Inventor: Pinder.30U.S. Appl. No. 11/671,506, filed Feb. 6, 2007, entitled "Apparatus for Entitling and Transmitting Service Instances to Remote Client Devices," Inventor: Russ.31U.S. Appl. No. 11/829,674, filed Jul. 27, 2007, entitled "Secure Content Key Distribution Using Multiple Distinct Methods," Inventor: Pinder.32U.S. Appl. No. 11/861,328, filed Sep. 28, 2007, entitled "Controlled Cryptoperiod Timing to Reduce Decoder Processing Load, " Inventor: Pinder.33U.S. Official Action mailed Aug. 16, 2010 in U.S. Appl. No. 11/829,647.34U.S. Official Action mailed Aug. 31, 2010 in U.S. Appl. No. 11/861,328.35U.S. Official Action mailed Feb. 2, 2011 in U.S. Appl. No. 11/829,647.36U.S. Official Action mailed Jun. 17, 2010 in U.S. Appl. No. 11/781,412.37Written Opinion dated Dec. 12, 2008 in PCT/US2008/070690.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8385545Jul 27, 2007Feb 26, 2013Howard G. PinderSecure content key distribution using multiple distinct methodsUS8788839Oct 10, 2012Jul 22, 2014Google Inc.Securely replacing boot loadersUS9137480Jun 30, 2006Sep 15, 2015Cisco Technology, Inc.Secure escrow and recovery of media device content keysUS9277295Jun 16, 2006Mar 1, 2016Cisco Technology, Inc.Securing media content using interchangeable encryption keyUS20070294178 *Jun 16, 2006Dec 20, 2007Scientific Atlanta, Inc.Securing media content using interchangeable encryption keyUS20080005030 *Jun 30, 2006Jan 3, 2008Scientific-Atlanta, Inc.Secure Escrow and Recovery of Media Device Content KeysUS20090028327 *Jul 27, 2007Jan 29, 2009Scientific-Atlanta, Inc.Secure content key distribution using multiple distinct methods* Cited by examinerClassifications U.S. Classification713/176International ClassificationH04L9/32Cooperative ClassificationG06F21/575, H04N21/8166, H04N21/443, H04N21/42684, H04N21/25816, H04N21/462, G06F21/51, G06F21/572European ClassificationH04N21/81W, H04N21/426N, H04N21/258C1, H04N21/443, H04N21/462, G06F21/57B, G06F21/51, G06F21/57ALegal EventsDateCodeEventDescriptionAug 8, 2007ASAssignmentOwner name: SCIENTIFIC-ATLANTA, INC., GEORGIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MURRAY, MARK R.;REEL/FRAME:019667/0324Effective date: 20070723Jul 27, 2009ASAssignmentOwner name: SCIENTIFIC-ATLANTA, LLC, GEORGIAFree format text: CHANGE OF NAME;ASSIGNOR:SCIENTIFIC-ATLANTA, INC.;REEL/FRAME:023012/0703Effective date: 20081205Owner name: SCIENTIFIC-ATLANTA, LLC,GEORGIAFree format text: CHANGE OF NAME;ASSIGNOR:SCIENTIFIC-ATLANTA, INC.;REEL/FRAME:023012/0703Effective date: 20081205Nov 19, 2014ASAssignmentOwner name: SCIENTIFIC-ATLANTA, LLC, GEORGIAFree format text: CHANGE OF NAME;ASSIGNOR:SCIENTIFIC-ATLANTA, INC.;REEL/FRAME:034299/0440Effective date: 20081205Owner name: CISCO TECHNOLOGY, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SCIENTIFIC-ATLANTA, LLC;REEL/FRAME:034300/0001Effective date: 20141118Jul 31, 2015FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services