METHODS AND APPARATUSES FOR PERFORMING DIGITAL RIGHTS

MANAGEMENT (DRM) IN A HOST DEVICE THROUGH USE OF A

DOWNLOADABLE DRM SYSTEM

TECHNICAL FIELD OF THE INVENTION

[0001] The invention relates to digital rights management (DRM). More particularly, the invention relates to enabling different types of DRM systems to be used by various types of host devices, such as, for example, a set-top box (STB) or similar device without having to implement DRM system-specific code in the host processor of the host device.

BACKGROUND OF THE INVENTION

[0002] Digital rights management (DRM) generally refers to systems and technologies used to control access to and distribution of digital information, such as digital content. DRM generally includes three components: expression, authentication and protection. Expression typically involves the description of the content, the ownership of the content, and the terms and conditions of use of the content. Authentication typically involves some form of verification that a user of the content has the right to use the resources. Protection typically involves mechanisms, such as encryption and digital keys, used to prevent unauthorized persons from accessing the content.

[0003] Many user devices, such as STBs, wireless telephones, personal digital assistants (PDAs), laptop computers, and personal computers (PCs), have the capability of rendering content (e.g., movies, video games, music, audio books, audio news articles, image files, text files, etc.). Content is distributed by a content provider to various types of user devices over various types of networks. The user devices typically have one or more content Tenderers on them, such as media player application programs, which render the content (e.g., display the content on a display device and/or playback the content on an audio playback device). For example, a cable television provider or multiple service operator (MSO) may allow a user (typically a paying customer) to download or stream a movie to the user's STB that the user then watches on a display

device of, for example, a television set, a laptop computer, a wireless telephone, etc. Similarly, an Internet online service may allow a user (typically a paying customer) to download content files, such as new articles, video games, music, etc., to a user device for playback or rendering by an appropriate media player program residing on the user device.

[0004] Content providers sometimes manage the distribution of content (e.g., downloading, streaming, etc.) by using one or more of a variety of conditional access (CA) systems to prevent unauthorized users from gaining access to content while allowing authorized users to access the content. Most CA systems encrypt digital content so that the content can only be accessed by equipment at the subscriber's premises that has the proper hardware and/or software configuration for decrypting the digital content stream. Therefore, the CA system can be viewed as having a first portion external to the subscriber premises somewhere in the network that encrypts the digital content stream, and a second portion located at the subscriber's premises, which decrypts the digital content stream to enable the subscriber to acquire the service. The second portion is typically located in a STB at the subscriber's premises, but may also be incorporated into a Cablecard or Smartcard that interfaces with a digital cable-ready television or other device.

[0005] Recently, downloadable CA systems (DCASs) have been proposed that will enable STBs to be used with different CA systems, provided the STBs employ standard DCAS capability. Such DCASs have not, however, been proposed for use specifically in DRM. DCAS technology eliminates the need to implement a particular CA-system specific hardware architecture in the STB or in a cable card at the subscriber's premises in order to decrypt the encrypted content stream. Instead, a CA system software module is securely downloaded from the network to the subscriber's STB. The downloaded software module is executed by a programmable secure processor within the STB to enable the STB to decrypt the digital content stream to enable the user to access the content.

[0006] FIG. 1 illustrates a block diagram of a known proposed DCAS configuration intended to be employed in a STB 11. A host processor 12 of the STB 11 is programmed to execute a DCAS kernel that is specific to the particular CA system to be used. The

STB 11 sends a request to download a DCAS software module to a downloading facility 14, which is typically operated by the network operator that services the subscriber's premises. The DCAS software module transmitted in response to the request is downloaded to the STB 11. The downloaded DCAS software suite is made up of separate modules that are executed by a secure processor 13 and the host processor 12. [0007] The CA system software module executed by the host processor 12 controls sending and receiving of messages and commands to and from the secure processor 13 and to and from a transport processor 15. The CA system software module executed by the secure processor 13 responds to messages from the host processor 12. Commands received by the transport processor 15 from the host processor 12 are performed by the transport processor 15 to cause the transport processor 15 to configure itself to look for particular Entitlement Control Messages (ECMs) and Entitlement Management Messages (EMMs) that are transported either as part of the encrypted content stream, or in logically-related data streams. The ECM contains access criteria and a CAS-encrypted content decryption key called a control word (CW). The EMM is an encrypted message that contains private conditional access information about the authority a subscriber has to acquire content.

[0008] When the transport processor 15 locates the EMM and ECM, it forwards these messages to the host processor 12. The host processor 12 forwards the ECM and EMM to the secure processor 13, which is executing the downloaded CA system software module. The secure processor 13 checks the EMM to determine whether the subscriber is authorized to access the content. If so, the secure processor 13 decrypts the ECM and obtains the CW, which is then sent to the host processor 12. The host processor 12 sends the CW to the transport processor 15, which it uses to decrypt the content. If the EMM does not indicate that the subscriber has authorization to access the content, the encrypted content will not be decrypted.

[0009] One of the disadvantages of the DCAS technology described above is that the host processor 12 must be configured to execute some portion of the DCAS kernel. Different STBs use different types of host processors. Therefore, a DCAS kernel designer is faced with potentially having to design a different DCAS kernel for each different type of host processor, which increases the amount of work and the costs

associated with implementing a given DCAS. Another disadvantage of the DCAS technology described above is that it allows CA system-specific code to reside in the host processor 12. This increases the observability of certain aspects of the CA system, and could potentially lead to the disclosure of security vulnerabilities that may be exploited by individuals who are attempting to break the CA system to gain unauthorized access. Another disadvantage of the DCAS technology described above is that because specific code must reside on the host processor, the code cannot be written only once, but must be ported for each instance of the host processor and operating system that will be encountered in the field.

[0010] Accordingly, a need exists for a downloadable DRM system that does not require that the host processor execute system-specific code or functionality and that is not vulnerable to security risks.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 illustrates a block diagram of a known proposed DCAS. [0012] FIG. 2 illustrates a block diagram of the DDRM CAS in accordance with one illustrative embodiment.

[0013] FIG. 3 illustrates a block diagram of the configurable secure (CS) processor shown in FIG. 2 in accordance with an illustrative embodiment. [0014] FIG. 4 illustrates a block diagram of the DDRMS in accordance with an embodiment, wherein the host processor and CS processor are integrated in a single integrated circuit.

[0015] FIG. 5 illustrates a flowchart that represents the CAS method performed by the CS processor shown in FIG. 3.

[0016] FIG. 6 illustrates a flowchart that represents the DRM method performed by the CS processor shown in FIG. 3.

[0017] FIG. 7 illustrates a block diagram of host device having components that are configurable to execute a DDRMS.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS [0018] FIG. 2 illustrates a block diagram of a host device 20 having components that are configurable to execute a downloadable digital rights management conditional access system, hereinafter referred to as a DDRM CAS. The DDRM CAS comprises a CA domain and a DRM domain. The CA domain relates to operations performed by components of the host device 20 to decrypt and render content of the type that is normally protected by CA systems. The DRM domain relates to operations performed by components of the host device 20 to decrypt, encrypt and render content of the type that is normally protected by DRM systems. The processes associated with performing operations in these two domains may be mutually exclusive or they may be integrated into a single CA process, as will be described below in detail.

[0019] In accordance with the preferred embodiment, the host processor 30 of the host device 20 (e.g., an STB, laptop computer, mobile phone, PDA, etc.) does not execute any CAS-specific or DRM-specifϊc code. Rather, all CAS-specific code and DRM- specifϊc code is implemented in a configurable secure (CS) processor 40 of the host device 20. The CS processor 40 and the host processor 30 are in communication with each other via a communications channel 50. Benefits associated with implementing all DRM-specific code and all CAS-specific code in the CS processor 40 rather than in the host processor 30 are described below in detail.

[0020] It should be noted that although the downloadable DRM system (DDRMS) has been described thus far herein as being used in conjunction with a CAS, this is because it is likely in many scenarios that the DDRMS will be used in conjunction with a CAS. For example, in cases where the host device 20 is a STB, the DDRMS will likely be used in combination with a DCAS because programming is typically protected by some type of a CAS. However, the DDRMS may be used without a CAS, as will be described below with reference to FIG. 7. For example, if the content was being delivered to a host device such as a PC from a server on a network, the content will typically be protected by a DRM system, but not by a CAS. In that case, the DDRMS will typically be downloaded to the PC, but a DCAS will not. For purposes of describing an illustrative embodiment in which the host device is a STB, the DDRMS will be

described as being used in conjunction with a DCAS. In this example, the DCAS is downloaded prior to downloading the DDRMS, or concurrently therewith. [0021] To download a DCAS, the host device 20 sends a request to download a DCAS software module to the DCAS downloading facility 14, which may be the same as the DCAS downloading facility 14 shown in FIG. 1. In response to this request, the DCAS downloading facility 14 transmits a DCAS software module to the STB 20, which is downloaded into the CS processor 40 of the invention. The host processor 30 executes an application program interface (API) software module that communicates with the CS processor 40 via the channel 50 to cause the CS processor 40 to configure itself. Through this API, the host processor 30 sends generic CAS commands and stream processing commands to the reconfϊgurable CS processor 40, which instruct the CS processor 40 to configure itself to look for the EMMs and ECMs based on the DCAS, and which inform the CS processor 40 of the manner in which the encrypted content stream 51 is to be processed to decrypt the content in the CA domain.

[0022] To download a DDRMS, the host device 20 sends a request to download a DDRMS software module to a downloading facility, which may be the same as the DCAS downloading facility 14 shown in FIG. 1. In response to this request, the downloading facility 14 transmits a DDRMS software module to the STB 20, which is downloaded into the CS processor 40 of the invention. The host processor 30 executes an API software module that communicates with the CS processor 40 via the channel 50 to cause the CS processor 40 to configure itself. Through this API, the host processor 30 sends generic DRM commands to the reconfϊgurable CS processor 40, which instruct the CS processor 40 to configure itself to encrypt and decrypt content files in the DRM domain.

[0023] Thus, the CS processor 40 preferably configures itself to perform decryption in a CA domain and to perform encryption and decryption in a DRM domain. As mentioned above, the processes of configuring the CS processor 40 in these domains will typically be performed as a single process if the DRM software modules are delivered to the host processor 30 along with the DCAS software modules as part of the DCAS software suite. Alternatively, the processes of configuring the CS processor 40 in these

domains are performed as separate processes if the DRM software modules are delivered to the host processor 30 separate from the DCAS software modules. [0024] After the CS processor 40 has been configured in the CA and DRM domains, the CS processor 40 will execute one or more DCAS and DDRMS software modules. The DCAS software modules look for and extract the corresponding EMMs and ECMs in the encrypted content stream 51 delivered to the host device 20. The encrypted content stream 51 includes DRM content as well as other types of content. As the CS processor 40 extracts the EMMs and ECMs from the encrypted content stream, the CS processor 40 processes them to obtain the CW, and then uses the CW to decrypt the encrypted content stream 51. The CS processor 40 then encrypts the decrypted content in the DRM domain and saves the encrypted DRM content in a storage device 60 via a storage channel 61. At some later time, the CS processor 40 may be instructed by the host processor 30 to retrieve particular encrypted content from the storage device 60, decrypt it and render it on a display device 70 via a rendering channel 71.

[0025] Under control of the host processor 30, the CS processor 40 will permit the host processor 30 to specify DRM actions desired by the user of the host device 20. For example, upon receiving a command from a user via a user interface 80 of the host device 20, the host processor 30 will instruct the CS processor 40 to display a list on the display device 70 of the DRM content stored in the storage device 60. The content titles have previously been designated by the user via the user interface 80 and the host processor 30 and recorded in the storage device 60 along with the encrypted content. The host processor 30 may instruct the CS processor 40 through the aforementioned API to allow the user to perform tasks such as, for example, purchase requests, content copy requests, content delete requests, etc. The DRM software would then access the hardware of the CS processor 40 and utilize the appropriate cryptographic functions to achieve the requested DRM action using methods specific to the downloaded DDRMS. [0026] In a typical scenario, the user will enter a request via the user interface 80 to have a list of content titles to be displayed on the display device 70. The host processor 30 will then instruct the CS processor 40 to retrieve the list of content titles and display them on the display device 70. After the CS processor 40 has retrieved the titles and caused them to be displayed on the display device 70, the user will make a selection from

the list via the user interface 80. The host processor 30 will receive this request and instruct the CS processor 40 to render the selected content to the display device 70. Because the CS processor 40 is executing the downloaded DDRM software module, the CS processor 40 will perform operations in accordance with this module, such as, for example, verifying that the user has authorization to use the requested content in the manner requested. For example, the user may have authorization to view the requested content as many times as desired during a twenty- four hour period starting at the instant in time when the user purchased the content. In this case, the CS processor 40 might determine whether the user has purchased the content, and if so, whether twenty- four hours have lapsed since the content was purchased.

[0027] If the CS processor 40 determines that the requested use is authorized, the CS processor 40 will retrieve the metadata associated with the encrypted content from the storage device 60, decrypt the encrypted content, and cause it to be displayed on the display device 70. If the requested use is not authorized, the CS processor 40 will inform the host processor 30, which will then inform the user by, for example, displaying a message on the display device 70 that informs the user of conditions for using the content (e.g., cost, time period over which the content will be available to the user, whether or not copies can be made, whether or not the user can use the content on other devices, etc.). [0028] Although the only rendering device described above is a display device 70, a variety of rendering devices are available for rendering content in a variety of forms (e.g., audio, video, text, images, etc.). The rendering device may, but need not be, part of the host device 20. For example, in the case where the host device 20 is a STB, the STB typically does not include rendering devices, but is connected to and operates in conjunction with a rendering device, such as a television set, a stereo system, a home entertainment system, etc. The display device 70 is shown merely for illustrative purposes.

[0029] The host device 20 may include one or more other input/output (I/O) interfaces 90, such as one or more Universal Serial Bus (USB) interfaces, for example, to enable the host device 20 to communicate with other devices. For example, if the user has DRM permission to play back a requested movie on a mobile telephone (not shown) or laptop computer, the user may connect a USB connection on the telephone or laptop

computer to the I/O interface 90 to enable the movie to be downloaded into a memory device of the telephone or laptop computer for subsequent play back on those devices. [0030] Examples of DRM tasks that may be performed by the DDRMS software module executed by the CS processor 40 include (1) content management, (2) provisioning management, and (3) device management. Content management typically involves administering rules regarding, for example, the number of "plays" requested by user, the number of "copies" requested by user, the output copy format requested (e.g., small format for a phone, home theatre quality format for a digital video recorder), and the playability lifetime (e.g. one day, one week, one month, forever, etc.). Provisioning management typically involves administering rules that synchronize the DDRMS client being executed by the CS processor 40 with the network "back office" server, which in this case might be the DCAS downloading facility 14. These commands will be used to communicate, for example, rights requested by the user, rights authorized to the user, and configuration of the user's account. Device management typically involves administering rules regarding the list of authorized devices for DRM-enabled content, adding, deleting, updating, the list, and specifying device parameters (e.g., storage capacity, decryption /DRM supported, etc.).

[0031] Some examples of generic DRM commands (API Command Request) that are sent from the host processor 30 to the CS processor 40 and returned from the CS processor 40 to the host processor 30 (CSP Response) include the following: API Command Request CSP Response query rights (content URL) rights_response() modify rights (content URL usage right) modify_rights_response() modify_account(account_ID, Device lD) modify_account_response()

The first exemplary command, query usage(content URL) would be used to obtain a content description, existing permissible actions, such as play three times, copy to a DVD, etc. The related DRM module being executed by the CS processor 40 would obtain the file from the location provided in the URL, evaluate the DRM usage rules associated with the content, and return the result in the response to host processor 30. The second illustrative command would enable the host processor 30 to request the CS processor 40 to modify a DRM usage right associated with a particular content asset. In response to receiving such a command, the DDRMS client would update the corresponding usage rights to enable the request right, for example, to make a copy of a movie to DVD. Finally, the last illustrative command would cause the CS processor 40 to a specified device to update an internal list of recognized, authorized-use devices. [0032] As stated above, one of the benefits of the DDRMS is that no system-specific code is implemented in the host processor 30. Because no system-specific code is implemented in the host processor 30, the host processor 30 is not vulnerable to security risks. All CA-specific code and DRM-specific code are executed entirely within the CS processor 40. In addition, because it is not necessary for a DDRMS or DCAS kernel to be executed by the host processor 30, different DDRMS and DCAS kernels do not have to be designed for different host processors. Consequently, the amount of work and costs associated with implementing a given DDRMS and or DCAS are reduced. Another benefit is that different DDRMSs can be implemented by simply reconfiguring the configurable CS processor 40 in accordance with the new DDRMS, and downloading a new DDRMS software module to the reconfigured CS processor 40. [0033] Some examples of generic CAS commands (API Command Request) that are sent from the host processor 30 to the CS processor 40 and returned from the CS processor 40 to the host processor 30 (CSP Response) include the following: API Command Request CSP Response acquire auth stream (module) module auth status extract_services (module) service list (e.g., PAT) acquire_service (module, service) service_status

The above commands are shown in a generic fashion to highlight the point that the host processor 30 and the CS processor 40 could be working with data in different formats,

such as, for example, MPEG packets or IP datagrams. The first command, acquire auth stream, would be used to acquire system-level module authorization status. The related DCAS module being executed by the CS processor 40 would seek and acquire its related system authorization stream and individual module authorization status, and return the resultant status in the response to the host processor 30. [0034] The second illustrative command, extract services, would be used by the host processor 30 to obtain a listing of services available to the CS processor 40. In the case of MPEG data streams, the service list would be represented by the presence of the Program Association Table (PAT). After returning the service list to the host processor 30, the user could make a selection from the list, thus causing the host processor 30 to communicate an acquire service message to the CS processor 40. It is envisioned that the illustrative acquire service message would result in decryption of the encrypted content stream if the downloaded CAS client module being executed by the CS processor 40 were authorized for the selected service. In cases where the client module is not authorized, the service status would return an appropriate error status message.

[0035] As described above with reference to FIG. 2, once the CS processor 40 has been configured in the CA domain, it detects the corresponding EMM and ECM and analyzes the EMM to determine whether the user is authorized to access the content. If the EMM indicates that the user is authorized, the CS processor 40 decrypts the ECM and obtains the CW. The CS processor 40 then uses the CW to decrypt the encrypted content stream. If the EMM does not indicate that the subscriber has authorization to access the content, the encrypted content stream will not be decrypted. In the known proposed DCAS system shown in FIG. 1 and described above, the CWs are transmitted between the host processor IC 12 and the transport processor IC 15. Consequently, the CWs are subject to being accessed by a hacker and used to obtain unauthorized access to restricted content. In contrast to the configuration shown in Fig. 1, with the configuration shown in Fig. 2, the CWs are never transmitted outside of the CS processor 40. This makes it extremely difficult or impossible for a hacker to obtain access to the CWs, and therefore makes the DCAS more secure and less vulnerable to attacks. Likewise, all DRM

encryption and decryption tasks are performed solely within the CS processor 40, which makes it extremely difficult or impossible for a hacker to obtain access to the DRM- protected content.

[0036] FIG. 3 illustrates a block diagram of the CS processor 40 of the invention in accordance with an illustrative embodiment. The CS processor 40 typically includes an input/output (I/O) interface 101 for communicating with the host processor 30, a CS controller 100 for controlling the operations of the CS processor 40, a memory element 110 for storing the downloaded DCAS software module and data, a stream parsing component 120 for parsing the encrypted content stream to locate the ECMs and EMMs, a CAS decrypting component 130 for decrypting the encrypted content stream, a DRM encrypting component 140 for encrypting the decrypted component in the DRM domain, and a DRM decrypting component 150 for decrypting the DRM-domain encrypted content. The DRM encryption technique performed by component 140 may be the same as the CAS encryption technique used by the downloading facility 14, in which case the DRM encrypting component 140 is not needed. Likewise, the DRM decryption technique performed by DRM decrypting component 150 may be the same as the CAS decryption technique performed by CAS decrypting component 130, in which case the component 150 is not needed. If the DRM encryption technique is different from the CAS encryption technique, then the DRM encrypting and decrypting components 140 and 150 are needed.

[0037] The host processor 30 and the CS processor 40 are typically integrated circuits (ICs) mounted on a printed circuit board (PCB) or the like, and are in communication with each other via the communications channel 50, which is typically a PCB bus. The I/O interface 101 of the CS processor 40 receives the CAS and stream processing commands sent over the bus 50 from the host processor 30. Some of the commands are used by the CS processor 40 to configure the stream parsing component 120. Some of the commands are used by the CS processor 40 to configure the CAS decrypting component 130. Some of the commands are used by the CS processor 40 to configure the DRM encrypting component 140. Some of the commands are used by the CS processor 40 to configure the DRM decrypting component 150. Commands and data are typically stored in memory element 110. The memory element 110 also stores the

downloaded DDRMS and DCAS software modules. The DDRMS and DCAS software modules comprise CAS and DRM software programs for performing the CAS and DRM tasks. The CS controller 100 executes this software and controls the operations of the components 110, 120, 130, 140, and 150 in accordance with the software. As stated above, these programs can be part of a single software module or they can be separate software modules. For ease of discussion, it will be assumed that the DRM and CAS software is all part of a single software module.

[0038] The stream parsing component 120 executes code of the DCAS software module that enables it to parse the encrypted content stream to locate the EMMs and ECMs, check the EMM to determine whether the subscriber is authorized to access the corresponding content, and extract the CW from the ECM in cases where the EMM indicates that the subscriber is authorized to access the content. The extracted CW is sent to the CAS decrypting component 130, which uses the CW to decrypt the encrypted content stream. The decrypted content stream output from the decrypting component 130 is then ready to be rendered on a rendering device. Some of the decrypted content may then be output from the CS processor 40 and sent to a rendering device (e.g., display device 70). However, the decrypted content that is to be managed by DRM is input to the DRM encrypting component 140, which encrypts the content in the DRM domain. [0039] After the DRM encrypting component 140 has encrypted the content in the DRM domain, the DRM-encrypted content is output from the CS processor 40 and sent over communications channel 61 to the storage device 60 (Fig. 2), which stores the DRM-encrypted content. At some later time, if the host processor 30 receives a request for content, it will forward a corresponding request over bus 50 to the CS processor 40. The CS controller 100 will process the request and determine whether the requested use is authorized. The CS controller 100 typically accomplishes this task by analyzing the metadata associated with the requested file, which is also stored in the storage device 60, in accordance with the aforementioned DRM rule set to determine whether the requested use is authorized. If so, the controller 100 will cause the requested content to be retrieved from the memory device 60 and sent to the DRM decryption component 150 for decrypting. The DRM-decrypted content will then be sent to a location designated by the controller 100 via the I/O interface 101 and bus 50.

[0040] As stated above, the CS processor 40 is capable of being reconfigured if a new or different DDRMS is to be used. To reconfigure the CS processor 40, the host processor 30 downloads the DDRMS software module and forwards it to the CS processor 40, which stores it in memory element 110. The host processor 30 then sends commands that are specific to the DDRMS to the CS processor 40, which it uses to reconfigure the components 100, 110, 120, 130, 140, and 150.

[0041] It should also be noted that the CS processor 40 may have multiple DDRMS software modules corresponding to different DDRMSs stored in memory element 50. The host processor 30 is capable of configuring the CS processor 40 to execute any one of these software modules based on the encryption scheme being used at the headend. For example, if certain cable television headend signals are protected by two conditional access systems, DDRMSl and DDRMS2, and if a user desires to tune between the services protected by DDRMSl and DDRMS2, then the host processor 30 will configure the CS processor 40 to use the appropriate DDRMS for each respective service. The CS processor 40 will switch back and forth as required to respond to tuning requests by the user. Furthermore, if a user wishes to view or record services protected by DDRMSl and DDRMS2 simultaneously, such as for the purpose of watching a service protected by DDRMSl, while at the same time recording a service protected by DDRMS2, then the host processor 30 will configure the CS processor 40 to simultaneously process services protected by DDRMSl and DDRMS2.

[0042] The CS processor 40 is typically an integrated circuit (IC), such as, for example, an application specific integrated circuit (ASIC). However, the CS processor 40 may be any device capable of performing the functions described herein, including, for example, a microprocessor, a microcontroller, a field programmable gate array (FPGA), a programmable logic array, etc. Also, the CS processor 40 may be implemented in hardware, software, firmware, or a combination of hardware, software and/or firmware. The term "processor", as that term is used herein, is intended to denote these and any other implementations of suitable computational devices. [0043] Likewise, the host processor 30 may be any device capable of performing the functions described herein with reference to the host processor 30, including, for example, a microprocessor, a microcontroller, a field programmable gate array (FPGA), a

programmable logic array, etc. Also, the host processor 30 may be implemented in hardware, software, firmware, or a combination of hardware, software and/or firmware. The host processor 30 is typically a microprocessor. In addition, it is not necessary for the host processor 30 and the CS processor 40 to be separate ICs. Rather, the functionality performed by both processors 30 and 40 may be implemented in a single IC, such as, for example, in a system on a chip (SOC) IC. For example, FIG. 4 illustrates a host device 160 in accordance with an embodiment in which the host processing logic 180 that performs the functions described above with respect to host processor 30 and CS processing logic 190 that performs the functions described above with reference to CS processor 40 are incorporated into a single SOC IC 170.

[0044] FIG. 5 illustrates a flowchart that demonstrates the method in accordance with an illustrative embodiment for processing an encrypted content stream in the CA domain. It should be noted that the steps represented by the blocks in the flowchart do not have to be performed in the order depicted in FIG. 5, or in any particular order. A DCAS software module is downloaded to the CS processor, as indicated by block 201. Subsequently, CAS and stream processing commands are sent from the host processor to the CS processor, as indicated by block 203. The CS processor configures itself in accordance with the received DCAS commands, as indicated by block 205. The encrypted content stream is then parsed and the EMMs and ECMs are located, as indicated by block 207. A determination is then made as to whether the EMM indicates that access to the content is authorized, as indicated by block 209. If so, the CW is extracted and the encrypted content stream is decrypted using the CW, as indicated by block 211. If not, the CS processor continues to parse the content stream and look for the EMMs and ECMs.

[0045] Fig. 6 illustrates a flowchart that demonstrates the method of the invention in accordance with an illustrative embodiment for processing an encrypted content stream in the DRM domain. It should be noted that the steps represented by the blocks in the flowchart do not have to be performed in the order depicted in FIG. 6, or in any particular order. A DDRMS software module is downloaded to the CS processor, as indicated by block 221. This step assumes that the DRM system is separate from the DCAS system downloaded in step 201 in Fig. 4, which is not necessarily the case. DRM commands are

sent from the host processor to the CS processor, as indicated by block 223. The CS processor configures itself in accordance with the received DRM commands, as indicated by block 225. If the commands include a usage request for DRM-protected content, or if a usage request command is subsequently received by the CS processor, a determination is made in CS processor as to whether the usage is authorized, as indicated by block 227. As stated above, this is typically accomplished by processing information contained in the metadata stored in the storage device 60 in association with the requested content file. If so, the DRM-protected content is retrieved from memory, as indicated by bock 229, and decrypted and output for rendering, as indicated by block 231. The manner in which the decrypted content is treated after it has been decrypted depends on the usage requested, and so is not shown in Fig. 5. If a determination is made at bock 227 that the requested usage is not authorized, a message is sent to the host processor indicating that the request is to be denied, as indicated by block 233.

[0046] As stated above, it is not necessary for the DDRMS to be used in conjunction with a CAS, as will now be described with reference to FIG. 7. FIG. 7 illustrates a block diagram of host device 300 having components that are configurable to execute a DDRMS. In accordance with the preferred embodiment, the host processor 330 of the host device 300 (e.g., an STB, laptop computer, mobile phone, PDA, etc.) does not execute any DRM-specific code. Rather, all DRM-specific code is implemented in the CS processor 340 of the host device 300. The CS processor 340 and the host processor 330 are in communication with each other via a communications channel 350. Benefits associated with implementing all DRM-specific code in the CS processor 340 rather than in the host processor 330 are described below in detail.

[0047] In accordance with this embodiment, the DDRMS and DRM-encrypted content are being delivered to a host device such as a PC, for example, from a content provider such as a server on a network, for example. In this example, the content is not protected by a CAS, but is only protected in the DDRMS. To download a DDRMS, the host device 300 sends a request to download a DDRMS software module to a downloading facility 314, which, as stated above, may be a content provider that distributes content from one or more servers on a network. In response to this request, the downloading facility 314 transmits a DDRMS software module to the host device

300. The host processor 330 then controls the downloading of the DDRMS to the CS processor 340. The host processor 330 executes an API software module that communicates with the CS processor 340 via the channel 350 to cause the CS processor 340 to configure itself. Through this API, the host processor 330 sends generic DRM commands to the reconfigurable CS processor 340, which instruct the CS processor 340 to configure itself to encrypt and decrypt DRM-encrypted content files. [0048] After the CS processor 340 has been configured in the DRM domain, the CS processor 340 will execute one or more DDRMS software modules. DRM-encrypted content received by the host device 300 from the content provider, which may or may not be the same as the DRM downloading facility 314, is sent by the host processor 330 to the CS processor 340. The CS processor 340 decrypts the DRM-encrypted content in the DRM domain and saves the decrypted DRM content in a storage device 360 via a storage channel 361. Alternatively, the CS processor 340 may save the content in the storage device 360 in its encrypted form. At some later time, the CS processor 340 may be instructed by the host processor 330 to retrieve particular content from the storage device 360 and render it on a display device 370 via a rendering channel 371. If the content retrieved from the storage device 360 has previously been decrypted by the CS processor 340, the CS processor 340 will render the content if the CS processor 340 determines that such action is authorized. If the content retrieved from the storage device 360 has not previously been decrypted by the CS processor 340, the CS processor 340 will decrypt the content and then render the content if the CS processor 340 determines that such action is authorized.

[0049] Under control of the host processor 330, the CS processor 340 will permit the host processor 330 to specify DRM actions desired by the user of the host device 300. For example, upon receiving a command from a user via a user interface 380 of the host device 300, the host processor 330 will instruct the CS processor 340 to display a list on the display device 370 of the DRM content stored in the storage device 360. The content titles have previously been designated by the user via the user interface 380 and the host processor 330 and recorded in the storage device 360 along with the encrypted content. The host processor 330 may instruct the CS processor 340 through the aforementioned API to allow the user to perform tasks such as, for example, purchase requests, content

copy requests, content delete requests, etc. The DRM software would then access the hardware of the CS processor 340, which would then determine whether the requested action is authorized, and if so, utilize the appropriate cryptographic functions to perform the requested DRM action.

[0050] It should be noted that the invention has been described with reference to particular examples and that the invention is not limited to the examples described herein. For example, although the CS processor has been described with reference to FIGS. 2, 3 and 7 as being a single IC, it may instead be made up of a combination of ICs or other devices that operate in conjunction with each other to perform the aforementioned operations. The configuration shown in FIG. 3 is merely an example of one way in which the host device may be configured to perform the DRM, or DRM plus CAS, processing tasks. Those skilled in the art will understand that modifications may be made to the examples described above and that all such modifications are within the scope of the invention.