I lllll llllllll II llllll lllll lllll lllll lllll lllll lllll lllll 111111111111111111111111111111111
`US 20060200415Al
`
`c19) United States
`c12) Patent Application Publication
`Lu
`
`c10) Pub. No.: US 2006/0200415 Al
`Sep. 7, 2006
`(43) Pub. Date:
`
`(54) VIDEONLINE SECURITY NETWORK
`ARCHITECTURE AND METHODS
`THEREFOR
`
`(52) U.S. Cl. ................................................................ 705/50
`
`(76)
`
`Inventor: Priscilla M. Lu, San Carlos, CA (US)
`
`(57)
`
`ABSTRACT
`
`Correspondence Address:
`IPSG, P.C.
`P.O. BOX 700640
`SAN JOSE, CA 95170-0640 (US)
`
`(21) Appl. No.:
`
`111357,777
`
`(22) Filed:
`
`Feb. 16, 2006
`
`Related U.S. Application Data
`
`(60) Provisional application No. 60/654,030, filed on Feb.
`16, 2005.
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`G06Q 99100
`
`(2006.01)
`
`A method for transmitting a multimedia content file
`encrypted with a multimedia content key to a rendering
`device, the rendering device further including a private
`license key, I is disclosed. The method includes configuring
`a license server with a set of rights associated with the
`multimedia content file and with a rendering device user.
`The method also includes requesting that a requested right
`for the multimedia content file be exercised on the rendering
`device. The method further includes, if the requested right is
`included in the set of rights, encrypting the content key with
`a public license key, wherein the private license key is
`configured to decrypt the content key. The method also
`includes transmitting the content key to the rendering
`device; transmitting the multimedia content file; decrypting
`the multimedia content file; and rendering the multimedia
`content file.
`
`102
`
`DIGITIZE CONTENT
`
`104
`
`COMPRESS/ENCODE
`
`106
`
`108
`
`110
`
`112
`
`WATERMARK
`
`ENCRYPT
`
`FRAGMENT
`
`DISTRIBUTE
`
`DISH, Exh. 1018, p. 1
`
`

`
`Patent Application Publication Sep. 7, 2006 Sheet 1 of 4
`
`US 2006/0200415 Al
`
`102
`
`DIGITIZE CONTENT
`
`104
`
`COMPRESS/ENCODE
`
`106
`
`108
`
`110
`
`112
`
`WATERMARK
`
`ENCRYPT
`
`FRAGMENT
`
`DISTRIBUTE
`
`FIG. 1
`
`DISH, Exh. 1018, p. 2
`
`

`
`CMS
`(202)
`
`LICENSE
`SERVER
`(203)
`
`SUBSCRIBER
`MANAGEMENT
`SERVER
`(204)
`
`BILLING
`SERVER
`(206)
`
`214a
`
`NAS
`(208a)
`
`NAS
`(208b)
`
`NAS
`(208c)
`
`MOBILE
`GATEWAY
`(210)
`
`CACHE SERVER
`(212)
`
`213
`
`214e
`
`220~jl' ) $
`il I"' ~
`
`FIG. 2
`
`(')
`
`~ ......
`
`""O
`~ ......
`('D = ......
`~ 'e -....
`.... 0 =
`""O = O" -....
`.... 0 =
`
`(')
`
`~ ......
`
`1J1
`('D
`'?
`~......:i
`N
`0
`0
`0-.,
`
`1J1 =(cid:173)
`
`('D
`('D
`......
`N
`0 ......
`.i;...
`
`c
`
`1J1
`N
`0
`0
`..._
`0-.,
`0
`N
`0
`0
`.i;...
`......
`Ul
`> ......
`
`DISH, Exh. 1018, p. 3
`
`

`
`PUBLIC PART (308)
`
`PRIVATE DEVICE PART (306)
`
`PRIVATE LICENSE PART (310)
`
`VIDEO PORTION 303
`
`AUDIO PORTION 304
`
`CONTENT HEADER(302)
`
`MULTI-MEDIA DIGITAL CONTENT (305)
`
`FIG. 3
`
`(')
`
`~ .....
`
`""O
`~ .....
`('D = .....
`~ 'e -....
`.... 0 =
`""O = O" -....
`.... 0 =
`
`(')
`
`~ .....
`
`1J1
`('D
`'?
`~-....J
`N
`0
`0
`0-.,
`
`1J1 =(cid:173)
`.....
`
`('D
`('D
`
`(.H
`
`0 .....
`
`.i;...
`
`c
`
`1J1
`N
`0
`0
`..._
`0-.,
`0
`N
`0
`0
`.i;...
`
`Ul
`
`....
`> ....
`
`DISH, Exh. 1018, p. 4
`
`

`
`Patent Application Publication Sep. 7, 2006 Sheet 4 of 4
`
`US 2006/0200415 Al
`
`402
`
`404
`
`406
`
`408
`
`410
`
`412
`
`CONFIGURE A LICENSE SERVER WITH A SET OF
`RIGHTS ASSOCIATED WITH THE
`MULTIMEDIA CONTENT FILE AND WITH A
`RENDERING DEVICE USER
`
`REQUEST A RIGHT TO RENDER THE
`MULTIMEDIA CONTENT ON THE RENDERING
`DEVICE
`
`IF THE RIGHT IS INCLUDED IN THE SET OF
`RIGHTS, ENCRYPT THE CONTENT KEY
`WITH A PUBLIC LICENSE KEY
`
`TRANSMIT THE CONTENT KEY TO THE
`RENDERING DEVICE
`
`TRANSMIT THE MULTIMEDIA CONTENT FILE
`
`DECRYPT AND RENDER THE MULTIMEDIA
`CONTENT FILE
`
`FIG.4
`
`DISH, Exh. 1018, p. 5
`
`

`
`US 2006/0200415 Al
`
`Sep. 7,2006
`
`VIDEONLINE SECURITY NETWORK
`ARCHITECTURE AND METHODS THEREFOR
`
`RELATED APPLICATIONS
`
`[0001] This application claims the benefit of U.S. Ser. No.
`60/654,030, filed Feb. 16, 2005, of U.S. Ser. No. 10/949,825,
`filed Sep. 24, 2004, and of U.S. Ser. No. 11/179,361, filed
`Jul. 11, 2005. All applications incorporated herein by refer(cid:173)
`ence and all priorities claimed.
`
`BACKGROUND OF THE INVENTION
`
`[0002] The present invention relates in general to personal
`communication systems. More particularly, the present
`invention relates to a videonline security network and meth(cid:173)
`ods therefor.
`[0003] The Internet has become an efficient mechanism
`for globally distributing digital content, such as movies.
`However, the advantage of easy digital communication has
`also allowed the digital content to be easily pirated by just
`about anyone with a computer and Internet access. The
`combination of high-speed broadband Internet access, digi(cid:173)
`tal content compression software (which reduces the size of
`digital content files), peer-to-peer file trading networks
`(which allows users to post content files), and lack of viable
`digital rights standards, has caused the content owners to
`lose control of their content. Consequently, content owners
`are experiencing a loss of potential revenue.
`
`[0004] What is needed are advanced techniques for con(cid:173)
`trolling the purchase and use of digital content, such that
`content owners are fairly compensated without discouraging
`buyers from purchasing the digital content.
`
`SUMMARY OF THE INVENTION
`
`[0005] The invention relates to an a method for transmit(cid:173)
`ting a multimedia content file encrypted with a multimedia
`content key to a rendering device, the rendering device
`further including a private license key. The method includes
`configuring a license server with a set of rights associated
`with the multimedia content file and with a rendering device
`user. The method also includes requesting that a requested
`right for the multimedia content file be exercised on the
`rendering device. The method further includes, if the
`requested right is included in the set of rights, encrypting the
`content key with a public license key, wherein the private
`license key is configured to decrypt the content key. The
`method also includes transmitting the content key to the
`rendering device; transmitting the multimedia content file;
`decrypting the multimedia content file; and rendering the
`multimedia content file.
`[0006] The invention relates to an a method of transmit(cid:173)
`ting a multimedia content file encrypted with a multimedia
`content key to a rendering device, the rendering device
`further including a private license key. The method includes
`configuring a license server with a set of rights associated
`with the multimedia content file and with a rendering device
`user. The method also includes requesting that a requested
`right for the multimedia content file be exercised on the
`rendering device. The method further includes, if the
`requested right is included in the set of rights, encrypting the
`content key with a public license key, wherein the private
`license key is configured to decrypt the content key. The
`
`method also includes, if the requested right is not included
`in the set of rights, billing the rendering device user for the
`requested right and encrypting the content key with the
`public license key. The method further includes adding a
`watermark to the multimedia content file; transmitting the
`content key to the rendering device; transmitting the multi(cid:173)
`media content file; decrypting the multimedia content file;
`rendering the multimedia content file.
`[0007] The invention relates to an apparatus for transmit(cid:173)
`ting a multimedia content file encrypted with a multimedia
`content key to a rendering device with a smart key, the
`rendering device further including a private license key. The
`apparatus includes means of configuring a license server
`with a set of rights associated with the multimedia content
`file and with a rendering device user. The apparatus also
`includes means of requesting that a requested right for the
`multimedia content file be exercised on the rendering
`device. The apparatus further includes, ifthe requested right
`is included in the set of rights, means of encrypting the
`content key with a public license key, wherein the private
`license key is configured to decrypt the content key. The
`apparatus also includes, if the requested right is not included
`in the set of rights, means of billing the rendering device user
`for the requested right and encrypting the content key with
`the public license key. The apparatus further includes means
`of adding a watermark to the multimedia content file; means
`of transmitting the content key to the rendering device;
`means of transmitting the multimedia content file; means of
`decrypting the multimedia content file; and means of ren(cid:173)
`dering the multimedia content file.
`[0008] These and other features of the present invention
`will be described in more detail below in the detailed
`description of the invention and in conjunction with the
`following figures.
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`[0009] The present invention is illustrated by way of
`example, and not by way of limitation, in the figures of the
`accompanying drawings and in which like reference numer(cid:173)
`als refer to similar elements and in which:
`[0010] FIG. 1 shows a simplified diagram of a process for
`encrypting a multimedia file, according to an embodiment of
`the invention;
`
`[0011] FIG. 2 shows a simplified diagram of a secured
`multimedia digital content delivery architecture, according
`to an embodiment of the invention;
`[0012] FIG. 3 shows a simplified diagram of a multimedia
`digital content stream, according to an embodiment of the
`invention; and
`
`[0013] FIG. 4 shows a simplified diagram of a method for
`transmitting a multimedia content file encrypted with a
`multimedia content key to a rendering device, according to
`an embodiment of the invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`[0014] The present invention will now be described in
`detail with reference to a few preferred embodiments thereof
`as illustrated in the accompanying drawings. In the follow(cid:173)
`ing description, numerous specific details are set forth in
`
`DISH, Exh. 1018, p. 6
`
`

`
`US 2006/0200415 Al
`
`Sep. 7,2006
`
`2
`
`order to provide a thorough understanding of the present
`invention. It will be apparent, however, to one skilled in the
`art, that the present invention may be practiced without some
`or all of these specific details. In other instances, well known
`process steps and/or structures have not been described in
`detail in order to not unnecessarily obscure the present
`invention.
`
`[0015]
`It is believed by the inventor herein that a digital
`rights management (DRM) scheme may be implemented,
`such that a digital multimedia content may be substantially
`protected by first securely transmitting a content key (CKey)
`to a trusted digital content rendering device (rendering
`device), and then transmitting a digital multimedia content
`encrypted with the CKey to that rendering device. Conse(cid:173)
`quently, the digital multimedia content stream may then be
`securely played by an authorized user. In an embodiment the
`digital multimedia content is transmitted as stream. In an
`embodiment the digital multimedia content is transmitted as
`a file. In an embodiment, the digital multimedia content is
`rendered on a DRM player. In an embodiment, the rendering
`device includes a license manager. In an embodiment, the
`license manager is integrated with the DRM player as a
`single application. In an embodiment, the license manager is
`separate from the DRM player. In an embodiment, the
`license manager is implemented using a separate processor,
`such as with a smart key.
`
`[0016] As previously described, content owners may
`experience a loss of potential revenue because of the lack of
`viable digital rights standards. By some estimates, the loss is
`about $5 billion a year. However, protecting digital rights
`should not discourage user purchases of digital content. A
`strongly designed DRM system that is poorly implemented
`may protect content, but it may also discourage utilization
`and hence also cause the loss of revenue. The present
`invention advantageously combines a strong DRM system
`with an intuitive and easy user interface, such that utilization
`is encouraged. In an embodiment, Microsoft, DIVX, Real
`and other industry supported DRM are supported.
`
`[0017] Referring now to FIG. 1. a simplified diagram
`showing a process for encrypting a multimedia file is shown,
`according to an embodiment of the invention. Initially, at
`102 the multimedia content, typically including a video
`portion and an audio portion, is digitized normally in an
`uncompressed format, such as uncompressed AVI, uncom(cid:173)
`pressed MOY, etc.
`
`[0018] At 104, the digital multimedia content is encoded
`and further compressed into the transmission format MPEG
`(1, 2, 4, etc.), audio (MP3, AAC), JPEG, WMA, RM,
`compressed AVI, etc. To compress video, for example, a
`complex mathematical formula breaks the video into indi(cid:173)
`vidual frames. Each frame is broken into moving and static
`components. Compression software takes each moving
`object and guesses where it will be in the next frame. By
`refreshing only the moving components of a frame, and
`recycling the static, compression reduces the size and trans(cid:173)
`mission time of the video file. In general, three factors that
`make up the quality of the video portion: frame rate, color
`depth and resolution.
`
`a relatively low bandwidth device, a lower frame rate, such
`as 10 fps, may be chose. An alternative technique may be a
`slideshow, in which the frame rate may be limited to one
`frame every five seconds.
`
`[0020] Color depth is generally the number of bits of data
`the computer assigns to each pixel of the frame. When there
`are more bits of data assigned to color each pixel, there are
`more colors that can be emulated on the screen. In general,
`most video may encoded with 8-bit 256 color, 16-bit 64,000
`color, or 24-bit 16.8 million colors. However, since greater
`color depth may increase the size of the streaming file, 8-bit
`or 16-bit is preferred.
`
`[0021] Resolution is typically a measure of the number of
`pixels. The greater the number of pixels, the higher the
`resolution of the video. For example, if your video is
`640x480, you have 640 pixels across each of the 480 vertical
`lines of pixels. Streamed video ranges in resolution from
`postage-stamp size (49x49 pixels) to 640x480 and beyond,
`which is considered full-screen video.
`
`[0022] At 106, a watermark is added to the digital multi(cid:173)
`media content in order to determine it origin, such as a
`particular distribution channel or network (e.g., Comcast,
`Cingular, China Telecom, etc.). In an embodiment, the
`watermark is added to the audio portion of the digital
`multimedia content. In an embodiment, the watermark is
`added to the video portion of the digital multimedia content.
`
`[0023] At 108, in an advantageous manner, the multimedia
`digital content is then encrypted with a particular CKey, for
`example using a symmetric block-ciphering encryption,
`such that it cannot properly rendered without first decrypting
`the digital multimedia content with the CKey. In an embodi(cid:173)
`ment, an audio portion of the digitized content is not
`encrypted. In an embodiment, the multimedia digital content
`is at least partially encrypted.
`
`[0024]
`In general, substantially encrypting the multimedia
`digital content would provide the greatest protection against
`unauthorized decryption. However, decrypting a fully
`encrypted may also be substantially time consuming. Con(cid:173)
`sequently, the use of a partially encrypted file may be
`quickly decrypted, yet still may not be rendered on a
`rendering device. In an embodiment, the rendering device
`includes a DRM enabled multimedia player (DRM player).
`In an embodiment, the DRM player is provided via a
`ViDeOnline service website.
`
`[0025] For example, a common encryption technique
`involves the use of symmetric block-ciphering encryption,
`such AES (Rijndael), DES, Triple DES, Lucifer, Blowfish,
`CAST, IDEA, RCS, RC2, etc. In general, symmetric block(cid:173)
`ciphering encryption involves dividing a plaintext M (digital
`multimedia content) into blocks of fixed length M=M1 , M2
`... MN. Each message block Mi is encrypted to ciphertext
`block, which, in turn, is concatenated into the ciphertext
`message (encrypted digital multimedia content). The more
`times this is done, that is the more rounds, the more resistant
`to cryptanalysis is the ciphertext. However, in general, as the
`number of rounds increase, so does the decryption time at
`the rendering device.
`
`[0019] Frame rate is generally the number of still images
`that make up one second of a moving video image. At 30
`frames per second (fps), images seem to move fluidly and
`naturally. However, if the video is going to be rendered on
`
`[0026] With appropriate strong encryption, the inventor
`believes that the cost of attacking a strongly encrypted
`digital multimedia content would far exceed the economic
`value of that content. Consequently, even a partial encryp-
`
`DISH, Exh. 1018, p. 7
`
`

`
`US 2006/0200415 Al
`
`Sep. 7,2006
`
`3
`
`tion would generally provide sufficient protection of the
`digital multimedia content, while still allowing that content
`to be quickly decrypted and rendered at the rendering
`device. In an embodiment, a single round is used. In an
`embodiment, every other block is encrypted. In an embodi(cid:173)
`ment, a set of blocks are encrypted based on a predetermined
`algorithm that is also known or transmitted to the rendering
`device.
`
`[0027] Next, at 110, the encrypted digital multimedia
`content is fragmented at 110. In general, in order to further
`decrease the likelihood that the digital multimedia content is
`compromised, and to facilitate bandwidth and load balanc(cid:173)
`ing during playback, the digital multimedia content file is
`divided in a set of sub-parts using a predetermined algo(cid:173)
`rithm. Each of those sub-parts may then be distributed
`among a set of content management servers, at 112. Con(cid:173)
`sequently, in response to an authorized request to transmit
`the multimedia digital content, each of the sub-parts would
`be properly assembled and transmitted to the requestor's
`rendering device. A table may be employed to trace the
`sub-parts and their location for subsequently assembly.
`
`[0028] However, if one of the content management servers
`is compromised, only a portion of the sub-parts may be
`obtained. In general, the value of digital multimedia content
`(e.g., movie, etc.) is substantially related to its complete
`renderability. For example, few users would be interested in
`seeing only every third minute of a movie. In an embodi(cid:173)
`ment, the digital multimedia content is fragmented into a set
`of substantially symmetric sub-parts. That is, each of the
`sub-parts is of the same size. In an embodiment, the digital
`multimedia content is fragmented into a set of asymmetric
`sub-parts. In an embodiment, the sub-parts may be interwo(cid:173)
`ven into the original digital multimedia content file after an
`authorized request is received.
`
`[0029] Referring now to FIG. 2, a simplified diagram of a
`secured multimedia digital content delivery architecture,
`according to an embodiment of the invention. As previously
`described, each encrypted digital multimedia content file is
`generally fragmented into a set of sub-parts, which are
`subsequently stored in a distributed manner on a set of
`content management system servers 202 (CMS). In an
`embodiment, the set of CMS servers 202 are coupled
`together in a secured peer to peer network, such that each
`may request any required sub-parts from the secured peer to
`peer network in order to first assemble, and then securely
`transmit a multimedia digital content file. In addition, a
`license server 203 may also be coupled to CMS servers 202.
`License server 203 is commonly configured to verify user
`rights with respect to specific multimedia digital content,
`authorize new access, and revoke access.
`
`[0030] As previously described, rendering devices 214
`may be configured with a DRM player. In general, a ren(cid:173)
`dering device may be any device capable of running a DRM
`player, a license manager, a user interface for rendering the
`particular multimedia digital content (e.g., personal com(cid:173)
`puter, laptop, MS Windows Mobile device, Palm device,
`etc.), and direct or indirect network access to CMS servers
`202 and licensing server 203.
`
`[0031] Commonly, rendering devices 214a-c are coupled
`to some type of network access server (NAS) 208. NAS is
`typically a computer server that enables an independent
`service provider (ISP) (e.g., Comcast, China Telecom, Cin-
`
`gular, etc.) to provide connected customers with Internet
`access. NAS 208 generally has interfaces to both the local
`telecommunication service provider such as the phone com(cid:173)
`pany and to the Internet backbone. Typically, NAS 208
`authenticates users requesting login, performing the neces(cid:173)
`sary steps to authenticate and authorize each user, usually by
`verifying a user name and password, and then allows
`requests to begin to flow between the user host and hosts
`(computers) elsewhere on the Internet. NAS 208 may be
`further configured to provide a host of services such as VoIP,
`etc.
`
`In an embodiment, rendering devices 214a is fur(cid:173)
`[0032]
`ther configured with smart key 213, such as a USB smart
`key, or any other processor-driven smart-key-type device
`that may be implemented using any protocol for I/O. Smart
`key 213 is generally a security authorization storage device
`configured to move authorizations from one rendering
`device 214a to another 214c. In general, if a smart key is
`used, an additional session key (SKey) is transmitted with
`the CKey, as previously described, in order to for that
`particular rendering device 214c to decode and render the
`digital multimedia content file. Generally, the SKey is tied to
`a unique identifier on the smart key, such that a combination
`of the CKey, the SKey is required to decode and render the
`digital multimedia content file. For example, if a user moves
`a smart key from rendering device 214a to rendering device
`214c, rendering device 214a can no longer render the digital
`multimedia content file, whereas rendering device 214c may
`render the digital multimedia content file.
`
`[0033]
`In another configuration, a mobile rendering device
`214d (e.g., mobile phone, Windows ME wireless device,
`Palm wireless device, etc.) is first coupled to a mobile
`gateway 210, which is in tum coupled to NAS 208. Mobile
`gateway 210 is generally configured to enable mobile
`devices that are not directly compatible with the Internet, to
`access resources on the Internet. For example, mobile gate(cid:173)
`way 210 may serve as the interface between NAS 208 and
`a micro browser in the mobile rendering device 214d,
`performing translations between HTML, HDML and WML
`coming from the Web.
`
`In an alternate configuration, rendering devices 214
`[0034]
`may be directly coupled to a cache server 212 that locally
`stores the multimedia digital content, for example for use in
`a kiosk. In general, cache server 212 securely stores the
`requested multimedia digital content locally, and also sends
`the multimedia digital content to rendering device 214e. The
`next time cache server 212 gets a request for the same
`multimedia digital content, it simply returns the locally
`cached data instead of retrieving the content from a CMS
`server 202, thus reducing Internet traffic and response time
`
`[0035]
`In addition, a rendering device with a DRM player,
`such as rendering device 214b, may also function as a trust
`proxy for other devices 220 that do not directly (indirectly)
`access the network, yet are still capable of rendering the
`particular multimedia digital content. In this instance,
`secured rendering device 214b would manage the authenti(cid:173)
`cation and authorization process for device 220, request that
`the multimedia digital content be securely transferred to
`secured rendering device 214b, and then transfer the mul(cid:173)
`timedia digital content to device 220.
`
`[0036]
`In a common configuration, a user desires to render
`(e.g., view, listen, etc.) a particular multimedia digital con-
`
`DISH, Exh. 1018, p. 8
`
`

`
`US 2006/0200415 Al
`
`Sep. 7,2006
`
`4
`
`tent file. The user would log on to a secured rendering device
`214a, and then be authenticated by the license manager. The
`license manager would, in turn, access a CMS server 202 in
`order to determine the user's then current rights. For
`example, the user may have the right to render on a
`particular rendering device 214 (e.g, DRM player, a Win(cid:173)
`dows ME device, a Palm OS device, and a personal com(cid:173)
`puter, etc.), the right to render before a particular end date,
`the right to render for a specified number of times, the right
`to render on a specified number of rendering devices 214a-e,
`the right to render in a specified resolution, the right to
`render if obtained through a specified distribution channel,
`etc. In an embodiment, an owner of the multimedia digital
`content may dynamically change the ability of a multimedia
`digital content file to be rendered on a particular rendering
`device, from a particular origin, or by a specific user.
`
`[0037]
`If sufficient rights exist, then the user is authorized
`to render the multimedia digital content in rendering device
`214a. If the content is locally stored, the user may imme(cid:173)
`diately begin rendering (e.g., viewing a movie, listening to
`a song, etc.). If the content is not locally stored, the DRM
`player requests that license server 203 authorizes CMS
`server 202 to transmit the content to rendering device 214a.
`
`[0038]
`If sufficient rights do not exist, but may be
`obtained, then the user is given an option to obtain those
`rights. For example, if a multimedia digital content file has
`already been licensed for a set number of rendering devices
`(e.g., home PC, work laptop, Windows ME device, etc.), the
`user may be given the option of disabling a previously
`authorized rendering device, in order to enable current
`rendering device 214a. Likewise the user may be given the
`option of purchasing another license to render the multime(cid:173)
`dia digital content file.
`
`[0039] For example, a user may want to purchase the right
`to play a movie on rendering device 214a. The license
`manager installed on rendering device 214a would contact
`license server 203, through NAS 208a, requesting authori(cid:173)
`zation. License server 203 would, in turn, contact the
`appropriate ISP's subscriber management server 204 in
`order to request that the user be billed for the movie.
`Subscriber management server 204 then would contact
`billing server 206 to initiate a charge that may appear on the
`user's bill. If the charge is successful, subscriber manage(cid:173)
`ment server 204 informs license server 203, which in tum,
`authorizes a CMS server 202 to begin to transmit the movie
`to rendering device 214a.
`
`[0040] Referring now to FIG. 3, a simplified diagram of a
`multimedia digital content stream is shown, according to an
`embodiment of the invention. As previously described, a
`multimedia digital content 305 is encrypted with a particular
`CKey, using a symmetric block-ciphering encryption, as
`well as being watermarked in order to determine origin.
`Prior to being transmitted to rendering device 214, addi(cid:173)
`tional security indicia may be added to the watermark, for
`example, a rendering device ID, a user ID, transmission
`timestamp, etc.
`
`[0041] Consequently, ifthe multimedia digital content file
`is compromised, stripped of DRM protection, and made
`publicly available on the Internet, the source of the com(cid:173)
`promised file may still be determined from the watermark.
`In an embodiment, the watermark may be added to an audio
`portion 304 of multimedia digital content file 305. In an
`
`embodiment, the watermark is periodically repeated in the
`audio portion 304 multimedia digital content file. In an
`embodiment, the watermark may be added to a video 303
`portion of multimedia digital content file 305. In an embodi(cid:173)
`ment, the watermark is periodically repeated in video por(cid:173)
`tion 303 of multimedia digital content file 305.
`
`In addition, a content header 302 is also generated
`[0042]
`and added to multimedia digital content file 305 including a
`public part 308, a private device part 306 and a private
`license part 310. Public part 308 generally includes unen(cid:173)
`crypted identification information that may be access by
`anyone, such as content ID, content description, copyright
`information, service URL, user readable DRM information,
`etc. In general, this information may be displayed in the
`DRM player. For example, if a user attempts to render
`multimedia digital content file 104 without authorization,
`the user would still be able to view public part 308 of content
`header 302.
`
`[0043] Private device part 306 generally includes an
`encrypted CKey, as well as an optional SKey if a smart key
`is used. In general, the CKey is encrypted with a set of public
`key infrastructure (PKI) keys and unique IDs that are issued
`or stored by the license server [not shown], such as media
`content ID, the device ID, the user's personal identification
`code (PIC), a transaction ID, etc.
`
`[0044] Media content ID is a unique identifier assigned to
`the particular multimedia digital content file. Device ID is a
`unique identifier assigned to the particular rendering device
`that is registered with the license server. PIC is a unique
`identifier identifying a user for billing and DRM purposes.
`Transaction ID is a unique identifier assigned to the specific
`purchase transaction associated with the particular multime(cid:173)
`dia digital content file.
`
`[0045] Private license part 310 generally includes specific
`rights and limitation for the specific multimedia digital
`content file 305, and is considered a complete license.
`Private license part 310 may include information related to
`the DRM attributes for the multimedia digital content file,
`and is generally used by the license manager to validate
`access to the multimedia digital content file, such as trans(cid:173)
`action type (e.g., purchase, rental, etc.), transaction specifics
`associated with that transaction type (e.g., end date, number
`of plays, etc.), a unique transaction key (TKey) associated
`with the transaction type, etc. In general, the TKey is
`uniquely generated for each issued multimedia digital con(cid:173)
`tent file license. Typically, private license part 310 is
`encrypted using the public key of the license manager. For
`example, if the user has purchased a multimedia digital
`content file 305, the number of plays may be unlimited.
`However, if a user rents multimedia digital content file 305,
`the number of plays may be limited, or the time in which to
`view the multimedia digital content file 305 is limited.
`
`[0046]
`In general, PKI key cryptography, as used in this
`invention, is based on the use of key pairs. When using a key
`pair, only one of the keys, referred to as the private key, must
`be kept secret and (usually) under the control of the owner.
`The other key, referred to as the public key, can be dissemi(cid:173)
`nated freely for use by any person who wishes to participate
`in security services with the person holding the private key.
`This is possible because the keys in the pair are mathemati(cid:173)
`cally related but it remains computationally infeasible to
`derive the private key from knowledge of the public key. In
`
`DISH, Exh. 1018, p. 9
`
`

`
`US 2006/0200415 Al
`
`Sep. 7,2006
`
`5
`
`an embodiment, the license server stores both a private and
`public key pair for each issued or used PKI key.
`[0047] After multimedia digital content file 305 has been
`authorized for transmission to a rendering device [not
`shown], the content header 302 is generated. In an embodi(cid:173)
`ment, private license part 310 is delivered when the down(cid:173)
`load occurs. In an embodiment, private license part 310 is
`delivered at a later time when a user wishes to access the
`multimedia digital content file.
`[0048] For example, when the user requests a DRM
`license for a multimedia digital content file, a content ID of
`the requested content file may be retrieved. Next, a unique
`T-Key may be created. A symmetric key may then be created
`by combining the content ID, device ID, PIC, and T-