`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`NETFLIX INC. AND HULU, LLC,
`Petitioners,
`
`v.
`
`DIVX, LLC,
`Patent Owner.
`____________
`
`Case IPR2020-00614
`Patent 7,295,673
`____________
`
`PATENT OWNER’S RESPONSE TO PETITION
`
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`TABLE OF CONTENTS
`
`I.
`II.
`
`C.
`
`D.
`
`INTRODUCTION .......................................................................................... 1
`THE CLAIMED INVENTION REDUCES PROCESSING AND
`SPECIALIZATION REQUIREMENTS FOR PROTECTED
`COMPRESSED VIDEO. ................................................................................ 2
`A.
`The Invention Permits “Bounded Partial Encryption.” ........................ 4
`B.
`The Invention Allows Efficient Decryption Of Partially Encrypted
`Frames Without Special Decoders. ....................................................... 7
`The Invention Allowed Partial Frame Encryption On Low Power
`Consumer Devices. ............................................................................. 10
`Licensed Products Enjoying The Benefits Of The Invention Were
`Incorporated Into Millions Of Popular Consumer Video Devices. .... 11
`III. THE PETITIONED GROUND FAILS TO SHOW THE “FRAME
`[ENCRYPTION][DECRYPTION] FUNCTION” (ALL CLAIMS). ........... 12
`The Board Correctly Construes “Frame Encryption Function” To
`A.
`Require Specifying The Encryption Location Within The Frame. ..... 13
`The Petition Disregards The Specification And Relies On An
`Unsupported Interpretation Of “Frame Encryption Function.” .......... 15
`The Rehearing Request’s Rewriting Of The Petition Is Untimely. .... 19
`Petitioner’s Rewritten Argument Fails Even On The Merits. ............ 23
`Demos And Ueno, Like Fetkovich, Are Not Shown To Disclose
`The Claimed “Frame Decryption Function.” ...................................... 29
`IV. THE PETITIONED GROUND FAILS TO SHOW THE
`“SYNCHRONIZED FRAME DECRYPTION STREAM” (ALL CLAIMS).
` ....................................................................................................................... 31
`The “Synchronized Frame Decryption Stream” Requires
`A.
`Decryption Information For Every Encrypted Frame. ....................... 32
`1.
`The Claim Language ................................................................ 32
`2.
`The Written Description ........................................................... 33
`3.
`The Prosecution History ........................................................... 34
`4.
`The Petition .............................................................................. 36
`Fetkovich Has No “Synchronized Frame Decryption Stream.” ......... 37
`
`B.
`
`C.
`D.
`E.
`
`B.
`
` i
`
`

`

`
`
`C.
`
`2.
`
`3.
`
`The POSITA Would Not Have Modified Fetkovich In View Of
`Ueno To Add “A Synchronized Frame Decryption Stream.” ............ 38
`The POSITA Would Not Have Modified Fetkovich To Achieve
`1.
`“Dynamically Changing Encryption Parameters” As Proposed.
` .................................................................................................. 40
`The POSITA Would Not Have Modified Fetkovich To Improve
`Synchronization As Proposed. ................................................. 44
`Ueno Does Not Teach Sending An Encryption Key With
`a.
`Each Frame To Achieve Synchronization. ..................... 45
`The POSITA Would Not Have Supplemented Or
`Replaced Fetkovich’s Own Solution In Light Of Ueno. 48
`Petitioner’s Modifications Are Reverse-Engineered Hindsight.
` .................................................................................................. 52
`Even If Motivation For It Were Shown, The Combination Is Not
`Shown To Meet The “Synchronized Frame Decryption Stream.” ..... 55
`PETITIONER FAILS TO SHOW CLAIMS 5 OR 18 ARE OBVIOUS. ..... 59
`V.
`VI. PETITIONER FAILS TO SHOW CLAIMS 10 OR 19 ARE OBVIOUS. ... 61
`VII. CANCELING THE CLAIMS WOULD BE UNCONSTITUTIONAL. ...... 62
`VIII. CONCLUSION ............................................................................................. 63
`
`
`D.
`
`b.
`
` ii
`
`

`

`
`
`TABLE OF AUTHORITIES
`
`
`Page(s)
`
`
`COURT DECISIONS
`Akamai Techs., Inc. v. Cable & Wireless Internet Servs., Inc.,
`344 F.3d 1186 (Fed. Cir. 2003) ............................................................................ 15
`Arthrex, Inc. v. Smith & Nephew, Inc.,
`941 F.3d 1320 (Fed. Cir. 2019) ............................................................................ 63
`Arthrex, Inc. v. Smith & Nephew, Inc.,
`953 F.3d 760 (Fed. Cir. 2020) (en banc) .............................................................. 63
`In re Dance,
`160 F.3d 1339 (Fed. Cir. 1998) ............................................................................ 55
`In re Dembiczak,
`175 F.3d 994 (Fed. Cir. 1999) .............................................................................. 55
`In re Magnum Oil Tools Int’l, Ltd.,
`829 F.3d 1364 (Fed. Cir. 2016) ............................................................................ 22
`In Touch Techs. v. VGo Communs.,
`751 F.3d 1327 (Fed. Cir. 2014) ............................................................................ 55
`Innova/Pure Water, Inc. v. Safari Water Filtration Sys.,
`381 F.3d 1111 (Fed. Cir. 2004) ............................................................................ 18
`Intelligent Bio-Systems, Inc. v. Illumina Cambridge, Ltd.,
`821 F.3d 1359 (Fed. Cir. 2016) ............................................................................ 22
`Key Pharms. v. Hercon Lab. Corp.,
`161 F.3d 709 (Fed. Cir. 1998) .............................................................................. 15
`Newell Window Furnishings, Inc. v. Springs Window Fashions Div., Inc.,
`15 F. App’x 836 (Fed. Cir. 2001) ......................................................................... 15
`Oakley, Inc. v. Sunglass Hut Int’l,
`316 F.3d 1331 (Fed. Cir. 2003) ............................................................................ 15
`Ward v. Vill. Of Monroeville,
`409 U.S. 57 (1972) ............................................................................................... 62
`Wasica Fin. GmbH v. Continental Automotive Sys., Inc.,
`853 F. 3d 1272 (Fed. Cir. 2017) ........................................................................... 22
`
`
`
` iii
`
`

`

`
`
`AGENCY DECISIONS
`Cisco Sys., Inc. et al. v. Oyster Optics, LLC,
`IPR2017-01719, Paper 31 (PTAB Jan. 24, 2019) ................................................ 19
`Comcast Cable Comm., LLC v. Promptu Sys. Corp.,
`IPR2018-00345, Paper 59 (PTAB June 28, 2019) ............................................... 23
`Comcast Cable Commc’ns v. Rovi Guides,
`IPR2017-00217, Paper 40 (PTAB May 14, 2018) ............................................... 55
`Ex Parte Beck,
`No. 2013-001609, 2014 WL 6737737 (PTAB Nov. 26, 2014) ............................ 15
`Hulu LLC v. Sound View Innovations LLC,
`IPR2018-00582, Paper 34 (PTAB Aug. 5, 2019)
`(informative) ........................................................................................................ 46
`Hulu LLC v. Sound View Innovations LLC,
`IPR2018-01023, Paper 15 (PTAB Aug. 14, 2019) .............................................. 18
`IBG LLC v. Trading Techs. Int’l,
`CBM2016-00032, Paper 16 (PTAB Aug. 16, 2016) ............................................ 55
`Liberty Mutual Ins. Co., v. Progressive Casualty Ins. Co.,
`CBM2012-00003, Paper 8 (PTAB Oct. 25, 2012) ............................................... 22
`ZTE (USA) v. Fundamental Innovation Sys. Int’l,
`IPR2018-00425, Paper 52 (PTAB Jul. 2, 2019) ................................................... 63
`
`
`
`STATUTES
`35 U.S.C. § 311 ....................................................................................................... 20
`35 U.S.C. § 313 ................................................................................................. 19, 20
`35 U.S.C. § 314(a) ................................................................................................... 20
`
`
` RULES, RULEMAKING, AND OTHER AGENCY AUTHORITIES
`37 C.F.R. § 42.107(a) .............................................................................................. 19
`Patent Trial and Appeal Board
`Consolidated Trial Practice Guide (Nov. 2019) ................................................... 19
`
` iv
`
`

`

`
`
`EXHIBIT LIST
`
`2001
`
`In re Campana, Jr., et al., Nos. 90/006,494 et al., Decision Denying
`Petition (Comm’r Pats. Feb. 23, 2007)
`
`2002 DivX, LLC v. Netflix, Inc., No. 2:19-cv-01602 (C.D. Cal.), Netflix, Inc.
`Invalidity Contentions, Exh. 673-A-1 (April 2, 2020) (excerpts)
`
`2003 DivX, LLC v. Hulu, LLC, No. 2:19-cv-01606 (C.D. Cal.), Hulu, LLC
`Invalidity Contentions, Exh. 673-A-1 (April 2, 2020) (excerpts)
`
`2004 DivX Networks, DivX Digital Rights Management: Software
`Development Kit, May 9, 2003
`
`2005 DivX Networks, Overview: Decoder Software Development Kit, May 9,
`2003
`
`2006 Project Blackhawk Summary Fact Sheet
`
`2007 Bruce Schneier et al., Performance Comparison of the AES Submissions
`(Feb. 1, 1999)
`
`2008 Declaration of Seth Nielson, Ph.D. [Nielson Decl.]
`
`2009 Deposition Transcript of Dr. Patrick D. McDaniel [McDaniel Dep.]
`
`2010 DivX Networks, File Formats: Decoder Software Development Kit, May
`8, 2003
`
`2011 Steven A. Hofmeyr, An Immunological Model of Distributed Detection
`and Its Application to Computer Security (May 1999) (Ph.D. dissertation,
`University of New Mexico) [Hofmeyr-1999]
`
`2012 Ben Rossi, 11 trends that will dominate cyber security in 2016,
`INFORMATION/AGE (Dec. 4, 2015), https://www.information-age.com/11-
`trends-will-dominate-cyber-security-2016-123460617/ [Rossi-2015]
`
`
`
`1
`
`

`

`
`
`2013
`
`Jelena Mirkovic et al., The DETER Project: Advancing the Science of
`Cyber Security Experimentation and Test in 2010 IEEE International
`Conference on Technologies for Homeland Security (Nov. 2010)
`[Mirkovic-2010]
`
`2014 Terry V. Benzel et al., Design Principles for Security, SecureCore
`Technical Report (Sept. 2005) [Benzel]
`
`2015 Excerpts from Ross Anderson, SECURITY ENGINEERING: A GUIDE TO
`BUILDING DEPENDABLE DISTRIBUTED SYSTEMS (2001) [Anderson-21001]
`
`2016 Shay Gueron et al., Where Does Security Stand? New Vulnerabilities vs.
`Trusted Computing, IEEE Computer Society (2007) [Gueron]
`
`2017
`
`2018
`
`I. Agi and L. Gong. An Empirical Study of Secure MPEG Transmission.
`In ISOC Symposium on Network and Distributed System Security, San
`Diego, CA (Feb. 1996)
`
`Jonathan Kilgallin & Ross Vasko, Factoring RSA Keys in the IoT Era in
`2019 First IEEE International Conference on Trust, Privacy and Security
`in Intelligent Systems and Applications, Los Angeles, CA (Dec. 2019)
`[Kilgallin-2019-IEEE]
`
`2019 Steven B. Lipner, Security and source code access: Issues and realities in
`2000 IEEE Symposium on Security and Privacy (Feb. 2000) [Lipner-
`2000]
`
`2020 Claim Chart
`
`2021 DivX, LLC v. Netflix, Inc., No. 2:19-cv-01602 (C.D. Cal.), Stipulated
`Protective Order (April 22, 2020)
`
`
`
`
`
`
`
`2
`
`

`

`
`
`I.
`
`INTRODUCTION
`
`As two of the hundreds of DivX employees who helped develop Patent
`
`Owner’s world-renowned video technology, inventors Eric Grab and Adam Li
`
`invented a unique approach to partial frame encryption, disclosed and claimed in
`
`patent No. 7,295,673 (“’673 Patent” or “Patent”), and incorporated into DivX’s
`
`Digital Rights Management (“DRM”) licensed and adopted for video codecs around
`
`the world. Ex. 2006 [DIVX-0073315], 1–2; see Section II, infra. Since the
`
`invention, DivX’s DRM using it has been deployed in over one billion consumer
`
`devices, including an increasing share of mobile devices. Ex. 2006, 2. More than
`
`43,000 professional titles have been protected by DivX’s DRM around the world.
`
`Ex. 2006, 1–2. Major consumer electronics manufacturers such as LG and Samsung
`
`have paid hundreds of millions of dollars to license DivX’s Software Development
`
`Kit, including this DRM practicing the invention. Id.
`
`The Board initially found that none of the references relied upon by the
`
`Petition, alone or in combination, disclose or render obvious the Patent’s unique
`
`approach to partial frame encryption. See Section III.B, infra. The Board’s basis of
`
`denial of institution was that Petitioner had not shown the limitation “frame
`
`encryption function” is disclosed as construed by the Board. Paper 11 (DDI), 18-
`
`19. Petitioner filed a Rehearing Request making new mappings of the claims to the
`
`references, and asserting that it had all along argued that its references disclose the
`
`
`
`1
`
`

`

`
`
`claimed “frame encryption function” based on the Board’s construction—which, to
`
`repeat, the Petition did not even address. Paper 12, 1. The Board did not allow
`
`Patent Owner to give any response to Petitioner’s Rehearing Request. Instead, the
`
`Board granted rehearing, and instituted review, in reliance on the Rehearing Request.
`
`Paper 13.
`
`As discussed herein, regardless of mapping, Petitioner’s references are
`
`fundamentally different from the claimed invention. See Sections III-VI, infra. The
`
`Board should issue a final decision confirming the patentability of Claims 1–6, 9–
`
`10 and 13–19, and again reject the sole proposed ground of review.
`
`II. THE CLAIMED INVENTION REDUCES PROCESSING AND
`SPECIALIZATION
`REQUIREMENTS
`FOR
`PROTECTED
`COMPRESSED VIDEO.
`
`The patent claims a novel approach for efficiently using partial encryption to
`
`protect compressed video from unauthorized access.
`
`The person of ordinary skill in the art (POSITA) at the time of the invention
`
`was aware that computer security is an unpredictable, “ever-changing” art in which
`
`there is no generally accepted measure of when a certain level of security has been
`
`achieved, EX2011 [Hofmeyr-1999], 2, and “researchers are still finding
`
`vulnerabilities in some of the oldest technologies used online,” EX2012 [Rossi-
`
`2015], 1. See EX2013 [Mirkovic-2010], 1, 3 (emphasizing “unpredictability and
`
`complexity” of cyber-security “challenges” and advocating “large-scale
`
`
`
`2
`
`

`

`
`
`experimentation” to address them) (emphasis in original); Ex2014 [Benzel], 18;
`
`EX2008 [Nielson Decl.], ¶¶ 45-46.
`
`Encryption to protect valuable data from unauthorized access is one
`
`unpredictable aspect of computer security. See Ex2015 [Anderson-21001], 51, 59-
`
`50, 70-71 (explaining that in data security “[i]n general, the boundary between
`
`crypto and access control is a fault line where things can easily go wrong”).
`
`Encrypting less than all of a data stream, while still making the data as a whole
`
`adequately secure, adds still more uncertainty. See Ex2016 [Gueron], 25 (noting
`
`that such “[a]rchitectural innovations bring performance gains but can also create
`
`new security vulnerabilities.”); see also EX2008 [Nielson Decl.], ¶¶ 47-48.
`
`Unsurprisingly, prior to the claimed invention there was a string of failed
`
`attempts to achieve efficient access protection without fully encrypting compressed
`
`video. In 1996, for example, an IEEE experimental study noted the need for an
`
`effective and efficient selective encryption method for secure video dissemination
`
`under the MPEG standard, and found that due to “[t]he very nature of MPEG
`
`encoding,” “commonly available software and hardware encryption mechanisms
`
`often c[ould] not encrypt entire MPEG streams without severely degrading
`
`performance and quality of service.” EX2017 [Agi], 1. The study’s authors tested,
`
`and rejected, numerous “previously proposed selective encryption schemes for
`
`MPEG video security” (including one the Petition cites as supposed evidence of
`
`
`
`3
`
`

`

`
`
`obviousness, Pet., 6 (citing Ex. 1008)), as “inadequate for sensitive applications,”
`
`explaining that their experiments showed that each of these proposed schemes
`
`actually left valuable data “clearly visible even if the video sequence [wa]s
`
`‘encrypted.’” Id., 1–5. The authors then experimented with further “obvious ways
`
`of improvement,” but found through further testing that their own proposed partial
`
`encryption scheme for effectively protecting video also failed. Id., 7–8. They
`
`recommended further experimentation on “a wide range of video samples” to gain
`
`“insight” into the “interesting issues” involved in making selective or partial video
`
`encryption “efficient” and “effective.” Id., 1, 7–8; see also EX2008 [Nielson Decl.],
`
`¶ 49.
`
`Overcoming this technological unpredictability, and despite others’ failures,
`
`the ’673 Patent’s inventors devised an undisputedly novel partial encryption
`
`approach for compressed video that solved some of these persistent problems.
`
`A. The Invention Permits “Bounded Partial Encryption.”
`
`One specific benefit of the claimed invention arises from its “bounded
`
`encryption approach.” Patent, 10:30. As the inventors’ disclosure explained, “the
`
`maximum processing power required to both decrypt and decode a frame increases
`
`proportionally to its size.” Patent, 3:39-41. In other words, the more data in a frame,
`
`the more processing power can be required to decrypt and decode it. Id. To ensure
`
`that the largest expected frames can be successfully decrypted at the playback
`
`
`
`4
`
`

`

`
`
`device, adequate decrypting/decoding processing power is needed. Patent, 3:42-45.
`
`“This requirement may significantly increase system cost and complexity, even
`
`though only a relatively small percentage of received frames may necessitate use of
`
`the full extent of available peak processing power.” Id., 3:45-48; EX2008 [Nielson
`
`Decl.], ¶ 51.
`
`The ’673 Patent addresses this longstanding problem with a “unique
`
`approach” to protecting streaming video that uses “bounded encryption,” which
`
`involves “bounding the resources consumed during decryption.” Id., 3:49-51, 5:25-
`
`27, 10:29-34. The invention, inter alia, allows the frame to be only partially
`
`encrypted and location and size of partial encryption specified for each frame, such
`
`as by byte offset and number of bytes, with frame decryption information being
`
`synchronized with the set of encrypted frames into a synchronized frame decryption
`
`stream. Patent, e.g., 6:25-35, 6:61-67, 7:25-8:4, 8:57-64, 9:23-39, 10:29-34. This
`
`“unique approach” of the invention allows processing power necessary to decrypt
`
`each frame to be bounded in advance, since each frame is only encrypted, for
`
`example, at the byte offset within the frame for a specified number of bytes so as to
`
`ensure decryption would not exceed a certain processing cap. EX2008 [Nielson
`
`Decl.], ¶ 52; see also Patent, 1:16-20, 3:49-51, 10:30-34. As discussed in detail in
`
`Section III.D, infra, the benefits of the Patent’s “bounded encryption” are not
`
`
`
`5
`
`

`

`
`
`possible with prior art partial frame encryption methods like Petitioner’s Fetkovich
`
`reference. EX2008 [Nielson Decl.], ¶¶ 53, 82.
`
`In the ’673 Patent, the inventors reported that their “[b]ounded encryption
`
`approach” resulted in “substantially less peak processing power... during the
`
`decryption process than would otherwise be required using standard encryption
`
`techniques.” Patent, 10:18-34, FIGS. 3, 10. In addition—and significantly, in light
`
`of the unpredictable effectiveness of partial or selective encryption, see EX2017
`
`[Agi], 8—the inventors reported that their invention may provide “adequate
`
`protection” when encrypting “only approximately 3% or less of the compressed
`
`video data.” Patent, 3:66-4:2; see also EX2008 [Nielson Decl.], ¶ 54.1
`
`Due to this aspect of the claimed invention, DivX players achieved wide
`
`adoption because they could be used on codecs utilizing limited-power consumer
`
`device processors of the time, where the processing demands of decrypting the DivX
`
`encrypted frames could be restricted so as not to exceed these components’ “peak
`
`processing power.” Patent, 10:29-34; Section II.C, infra.
`
`
`1 This does not mean that the invention always allows adequate security with
`
`as little as “approximately 3% or less” encryption. It simply says that it is able to
`
`allow adequate security with this small a percentage in certain circumstances. Id.
`
`
`
`6
`
`

`

`
`
`B.
`
`The Invention Allows Efficient Decryption Of Partially Encrypted
`Frames Without Special Decoders.
`
`As another benefit, the invention also permits efficient decryption of partially
`
`encrypted frames using a generic decoder (such as one suitable for full-encryption
`
`systems) rather than a specialized decoder.
`
`In traditional full-encryption decryption/decoding systems the receiver device
`
`first decrypts the fully encrypted frames, then feeds the decrypted frames to the
`
`codec for decoding and playback. Since no analysis is required to identify encrypted
`
`and unencrypted portions of the frame, decryption may be performed on a relatively
`
`fast hardware-implemented decryption engine. In contrast, in partial frame
`
`encryption the decrypting/decoding receiver needs to first identify which parts of the
`
`frame are encrypted. EX2008 [Nielson Decl.], ¶¶ 56-57.
`
`The partial frame encryption references raised by the Petition identify the
`
`partially encrypted portions of the frames based on frame sub-structures defined by
`
`video standards such as slices or macroblocks (or even more specialized units).
`
`Demos, 22:39-44, 23:37-24:19; Fetkovich, 4:37-42, 5:28-37; see Patent, 3:5-11.
`
`Fetkovich, for example, partially encrypts frames based on frame sub-structures by
`
`(for example) encrypting every fourth slice within the frame. Fetkovich, 6:24-40.
`
`In such systems, because encryption and decryption were performed based on frame
`
`sub-structures, decryption required those pre-defined frame sub-structures to be first
`
`identified in the playback device so that they could be decrypted. Id., Figure 1;
`
`
`
`7
`
`

`

`
`
`accord Ex. 2009 [McDaniel Dep.] 131:2-9. However, such an approach either
`
`required specialized decoders or was very inefficient, as explained below.
`
`Fetkovich uses specialized hardware/firmware to identify frame sub-
`
`structures and decrypt the frame before sending the frame to a conventional decoder,
`
`Fetkovich, Figure 1, 2:55-3:3, 4:37-42, 5:28-37, 6:66-7:7, 7:28-34, 10:54-58. This
`
`method is very inefficient because it essentially requires repeating a substantial part
`
`of the processing, by needing to identify the frame sub-structures, twice: first to
`
`perform decryption, then again in the decoder to perform decompression. Such
`
`duplication reduces or eliminate much of the processing savings from partial
`
`encryption. EX2008 [Nielson Decl.], ¶ 58. If one desired to avoid the duplication
`
`of a substantial part of the decompression process as Fetkovich would require, then
`
`a specialized decoder would be needed that could perform both the decryption and
`
`decompression. For example, Demos’ partial encryption requires specialized
`
`decoder arrangements to receive and analyze partial encryption parameters and then
`
`decrypt the partially encrypted frame in accordance with those parameters before
`
`decoding the frame. Demos, Figures 4, 10, 8:33-34, 10:62-11:7, 14:65-15:13, 16:38-
`
`17:36, 23:17-24:19; see also, e.g., Ex2017 [Agi], 3 (discussing prior-art selective
`
`encryption scheme requiring “special encoder and decoder”).
`
`The patented invention helps avoid this problem of partial frame encryption
`
`by performing partial frame decryption based not on frame sub-structures, but on,
`
`
`
`8
`
`

`

`
`
`inter alia, specifying the location of a portion in a frame to which encryption is
`
`applied. See Section III.D, infra. Because the invention’s decryption does not
`
`depend on frame sub-structure, it can be performed before the frame enters the
`
`decoder, allowing the decoder to receive the already-decrypted stream like in full-
`
`encryption systems, so generic decoders can be used with DivX-encrypted streams.
`
`Because identifying the encrypted portions of the frame does not require first
`
`identifying frame substructure, the Patent’s invention also avoids the duplicative
`
`processing of a system such as Fetkovich. EX2008 [Nielson Decl.], ¶ 59.
`
`Petitioner’s expert Dr. McDaniel did not consider these benefits of the
`
`invention when rendering his opinions. As he admitted at deposition, he does not
`
`even know the level of architecture of encryption or decryption engines in such
`
`systems at the time of the invention, or even whether they were generally designed
`
`for full or partial-frame encryption:
`
`Q. In 2002 was a decryption engine generally designed for either full
`encryption or partial-frame encryption or, alternatively, was the
`encryption engine designed as a general form and was able to
`perform either full-frame encryption or partial-frame encryption?
`
`A. Well, again, it would depend on the architecture of that individual
`system.
`
`Q. Was there a general practice?
`
`A. I don’t know the level of architectures of those devices in 2002.
`
`
`
`9
`
`

`

`
`
`Ex. 2009, 59:8-18. Dr. McDaniel’s opinions are thus premised on incomplete, or
`
`inaccurate, understanding of the invention’s technological context and benefits.
`
`C. The Invention Allowed Partial Frame Encryption On Low Power
`Consumer Devices.
`
`The invention’s partial frame encryption approach is useful in low-
`
`processing-power consumer electronic devices. As discussed above, in prior-art
`
`partial frame encryption systems that based partial encryption on frame substructure,
`
`the player device had to identify the particular encrypted sub-structures before
`
`starting decryption, which could consume substantial resources, especially given the
`
`limited processing power of consumer devices in, for example, 2002. The invention,
`
`in contrast, conveys information about where in a frame encryption is applied by
`
`specifying the location, by layout or offset, of the portion of the frame. The
`
`processing power required to identify a specified location within a frame is generally
`
`substantially less than is required to identify sub-structures within the frame and then
`
`identify which of those sub-structures are encrypted, as in the Petition’s partial
`
`encryption systems. As a result, the invention permits implementation of partial
`
`frame encryption on devices that would not otherwise possess the requisite
`
`decrypting/decoding processing power. Patent, 10:29-34; 3:66-4:2; EX2008
`
`[Nielson Decl.], ¶ 60.
`
`
`
`10
`
`

`

`
`
`D. Licensed Products Enjoying The Benefits Of The Invention Were
`Incorporated Into Millions Of Popular Consumer Video Devices.
`
`DivX implemented its inventive partial encryption approach into DivX’s
`
`Digital Right Management Systems. See, EX2008 [Nielson Decl.], ¶ 61; EX2020.
`
`DivX developer kits specifically highlighted the invention’s benefits, touting for
`
`example the fact that developers could cap the processing power needs of a DivX
`
`encrypted video based on manufacturer limits. See, e.g., Ex. 2004, DIVX-0001267
`
`(“Amount of decryption is bounded and deterministic to give consistent and low
`
`performance overhead.”); see also id., DIVX-0001280. This was possible because
`
`DivX’s method could specify, e.g., the layout and offset of bytes encrypted in each
`
`frame, unlike partial encryption schemes like those in Fetkovich and Demos. DivX
`
`developer kits also highlighted that DivX DRM could be used by components
`
`already in devices. See, e.g., Ex. 2005, DIVX-0001248 (“technology provided by
`
`the SDK is intended to be ported to an embedded environment or consumer
`
`device.”).
`
`DivX’s DRM, touting the benefits of the invention, was adopted across the
`
`consumer electronics industry. It has been deployed in over one billion consumer
`
`devices, including an increasing share of mobile devices. Ex. 2006, DIVX-0073315.
`
`More than 43,000 professional titles have been protected by DivX’s DRM
`
`worldwide.
`
` Ex. 2006, DIVX-0073313-14.
`
` Major consumer electronics
`
`manufacturers, including Samsung, LG and many others, have collectively paid
`
`
`
`11
`
`

`

`
`
`hundreds of millions of dollars to license the technologies in DivX’s SDKs,
`
`including DivX’s DRM technology. Id; see also EX2008 [Nielson Decl.], ¶ 62.
`
`*
`
`
`
`*
`
`
`
`*
`
`As discussed below, Petitioner’s references fail to disclose multiple
`
`limitations that help achieve to the claimed invention’s benefits.
`
`III. THE PETITIONED GROUND FAILS TO SHOW THE “FRAME
`[ENCRYPTION][DECRYPTION] FUNCTION” (ALL CLAIMS).
`
`Petitioner’s references fall far short of teaching the claimed “frame
`
`encryption/decryption functions.” First, challenged independent Claim 1 recites
`
`“encrypting at least selected portions of selected frames…in accordance with a
`
`frame encryption function.” Patent, cl. 1. Independent Claim 14 recites a
`
`corresponding limitation of a “frame decryption function.” Id., cl. 14. The Board
`
`has already construed frame encryption function (and made related determinations
`
`as to frame decryption function) at the institution stage. See DDI. As discussed in
`
`Section III.A, infra, the Board’s construction of frame encryption/decryption
`
`function is correct. However, the Petition chose to offer no construction of these
`
`limitations, and disregard the discussion of them in the Patent’s specification.
`
`Instead, the Petition relied only on a broad, unspoken construction of frame
`
`encryption/decryption function that neither addressed nor has any support in the
`
`specification. Thus, the Petition fails to meet its burden to show how these
`
`limitations should be construed, and to show unpatentability under that construction.
`
`
`
`12
`
`

`

`
`
`See Section III.B. Petitioner’s Rehearing Request rewrites the Petition’s grounds to
`
`target the Board’s claim construction, but these arguments are untimely. See
`
`Section III.C. And even if the Board considers Petitioner’s retargeted arguments,
`
`Petitioner fails to show that Fetkovich’s encryption/decryption-related disclosures
`
`meet the claimed frame encryption/decryption function. See Section III.D.
`
`Second, Petitioner also fails to show the Petition’s alternate theory based on
`
`Demos discloses the frame encryption/decryption function. See Section III.E.
`
`A. The Board Correctly Construes “Frame Encryption Function” To
`Require Specifying The Encryption Location Within The Frame.
`
`As the Board has found, the claimed “frame encryption function requires
`
`conveying information about where in a frame encryption is applied,” and
`
`“specifying the location, by layout or offset, of a portion in a frame to which
`
`encryption is applied.” DDI, 9. The Board’s grant of rehearing did not modify its
`
`construction of “frame encryption function” or its analysis supporting that
`
`construction. The record supports the Board’s construction, as already discussed,
`
`DDI, 7–11, POPR, 21–24, and as further discussed below.
`
`The Patent’s description of the invention expressly uses the term “frame
`
`encryption function” in connection with the “placement” of encrypted portions
`
`within the frame to identify the location of encryption, and to specify whether, for
`
`example, the encryption is placed at the beginning of the frame at the header:
`
`
`
`13
`
`

`

`
`
`Such selective placement of encrypted material consistent with an
`encryption layout function permits, for example, the recovered video
`stream to reflect a desired degree of perceived degradation or
`“scrambling.” For example, when the applicable encryption layout or
`frame encryption function prescribes that the header data of a given
`frame is encrypted, a sufficiently large amount of video information
`may become unusable such that the frame is effectively “blacked out”
`(i.e., is skipped during playback).
`
`Patent, 5:33-41. The Patent explains the encryption layout can be in the form of
`
`“header layout,” meaning encryption starts at an offset of zero from the beginning
`
`of the frame, or in the form of “middle layout,” meaning encryption starts at an offset
`
`of greater than zero from the beginning of the frame. Id., 5:44-54; 7:55-59; see also
`
`EX2008 [Nielson Decl.], ¶ 67.
`
`As the Board observes, the Patent also uses the phrase “function” in
`
`connection with encryption layout within the frame. DDI, 8–9, citing Patent, 8:5-
`
`18 (“Alternatively, a non-linear function could be used so that any pattern to the
`
`offsets would be difficult to detect.”); 9:66-10:1 (“As is illustrated by FIG. 9, second
`
`encrypted frame 960 is encrypted in accordance with a middle offset encryption
`
`function.”); EX2008 [Nielson Decl.], ¶ 68.
`
`Accordingly, as the specification confirms, the Board is correct that the
`
`claimed “frame encryption function” requires specifying the location of where in a
`
`f