`
`IN THE 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 No. IPR2020-00614
`U.S. Patent 7,295,673
`––––––––––
`
`PETITIONERS’ REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`
`I.
`
`II.
`
`Frame Encryption/Decryption Function ........................................................ 3
`A.
`The Petition is consistent with the Board’s construction. .................... 3
`B.
`The Board’s construction does not exclude encryption
`algorithms, nor should it. .................................................................... 5
`The challenged claims do not require location to be specified in
`bytes. .................................................................................................. 6
`PO contradicts its own arguments. .................................................... 10
`Using bytes was not a “unique approach.” ........................................ 11
`The claims cannot be limited to using bytes, regardless of
`purported benefits. ............................................................................ 12
`Synchronized Frame Decryption Stream ..................................................... 14
`A.
`PO admits this limitation is met by Ground 1.................................... 14
`B.
`Lossy channels are irrelevant to synchronization. ............................. 16
`C.
`Ground 1 includes sending decryption information with each
`frame. ............................................................................................... 16
`1.
`Demos provides express and unrebutted motivation................ 17
`2.
`Ground 1 improved reliability. ................................................ 18
`3.
`The combination improves security. ....................................... 19
`The claims do not require including decryption information
`with each frame................................................................................. 24
`III. Claims 5, 18 ................................................................................................ 25
`IV. Claims 10, 19 .............................................................................................. 26
`V.
`PO attempts at distraction fail. .................................................................... 26
`A.
`PO does not argue secondary considerations. .................................... 26
`B.
`Computer security and encryption were not unpredictable. ............... 27
`VI. Conclusion .................................................................................................. 29
`
`
`C.
`
`D.
`E.
`F.
`
`D.
`
`
`
`
`
`
`
`
`-2-
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`PO only disputes two limitations: frame encryption/decryption function and
`
`synchronized frame decryption stream. PO’s arguments fail with respect to both
`
`because they are contradicted by the evidence and PO’s previous admissions.
`
`I.
`
`Frame Encryption/Decryption Function
`A. The Petition is consistent with the Board’s construction.
`The ID construed “frame encryption function” to require “specifying the
`
`location, by layout or offset, of a portion in a frame to which encryption is applied
`
`and the pattern of application of each layout or offset with respect to each type of
`
`frame in a set of frames.” Paper 11 (“DDI”), 7-11; Paper 13 (“ID”), 7. The Board
`
`correctly held that this construction is satisfied by Ground 1. ID, 13-16.1
`
`Petitioners explained how Ground 1 satisfies the frame
`
`encryption/decryption function by teaching, e.g., two aspects: (1) encryption
`
`algorithms and (2) a selection process that specifies portions of selected frames to
`
`encrypt/decrypt, e.g., with encryption parameters. Pet., 33-35; ID, 14-16; Ex-1019,
`
`¶¶15-16. This meets the Board’s construction because the selection process
`
`specifies the location, by layout and/or offset, of a portion in a frame to
`
`
`1
`Petitioners do not agree that the claims require “specifying … the pattern of
`application of each layout or offset with respect to each type of frame.” The ’673
`patent uses permissive rather than restrictive language in describing this feature.
`Ex-1001, 8:5-18 (“It may also be desired ….”). Nonetheless, this limitation is
`satisfied by Ground 1 (Ex-1019, ¶¶2-14), which PO does not dispute.
`
`
`
`
`
`
`-3-
`
`
`
`
`
`

`

`
`
`
`
`
`encrypt/decrypt (a selected portion) and the pattern of application for each layout
`
`
`
`or offset with respect to each type of frame in a set of frames (selected frames,
`
`including I and P frames). Ex-1019, ¶¶2-14; Paper 12, 2-11.
`
`For “frame encryption function,” Fetkovich and Demos teach the use of
`
`encryption algorithms “to encrypt selected portions of selected frames in
`
`accordance with encryption parameters.” Pet., 33;2 Ex-1003, ¶153. Demos teaches
`
`selecting frames, and “Fetkovich teaches encryption parameters to select which
`
`slices or macroblocks in a frame are encrypted…” Pet. 33; Ex-1003, ¶¶155-156.
`
`The combination therefore specifies location by layout and offset. Ex-1019, ¶5.
`
`Alternatively, Demos by itself specifies the location, by layout, of encrypted
`
`portions by, e.g., “using DES, Triple DES, or Blowfish to encrypt selected portions
`
`of selected frames.” Pet. 35; Ex-1003, ¶¶162-169; Ex-1019, ¶¶6, 16. For both
`
`alternatives, Demos specifies the pattern of application for I and/or P frame types.
`
`Ex-1019, ¶¶7-14; Ex-1003, ¶163; Ex-1006, 23:17-24:18.
`
`Petitioners analyzed the portions of the ’673 specification the Board also
`
`relied on. Pet., 34-35 (citing Ex-1001, 5:25-43, 8:5-18, 9:62-10:11); Ex-1003,
`
`¶161; cf. DDI, 7-11. Providing an implicit claim construction (ID, 7-8) is
`
`consistent with Federal Circuit precedent, which holds that petitions are not
`
`2 All emphasis added.
`
`
`
`
`
`
`
`
`-4-
`
`
`
`
`
`

`

`
`
`
`
`
`required to explicitly construe every term. See Ericsson Inc. v. Intelectual.
`
`
`
`Ventures I LLC, 901 F.3d 1374, 1381 (Fed. Cir. 2018).
`
`PO mischaracterized Dr. McDaniel’s declaration by omitting the portions of
`
`those sentences that explain, e.g., that DES is used “to encrypt selected portions of
`
`selected frames in accordance with encryption parameters.” See POR 16-17; Ex-
`
`1003, ¶153, ¶162; Ex-1019, ¶17. PO also cites to a discussion of Ueno’s
`
`encryption algorithm, while omitting the preceding and subsequent sentences, both
`
`of which discuss the use of encryption parameters because the frame encryption
`
`function includes both components. See POR, 21; Pet. 35; Ex-1019, ¶18.
`
`This was explained in Petitioners’ request for rehearing, which was timely
`
`and did not raise new arguments or evidence. Paper 12, 2-11. Liberty Mutual is
`
`inapposite because Petitioner’s position was not ambiguous. Regardless, “[p]arties
`
`are not barred from elaborating on their arguments on issues previously raised.”
`
`Chamberlain Grp., Inc. v. One World Techs., Inc., 944 F.3d 919, 925 (Fed. Cir.
`
`2019); Ericsson Inc. v. Intellectual Ventures I LLC, 901 F.3d 1374, 1381 (Fed. Cir.
`
`2018).
`
`B.
`
`The Board’s construction does not exclude encryption algorithms,
`nor should it.
`Consistent with the claims’ “comprising” transitions, the Board held that
`
`frame encryption function does not exclude “a combination that includes
`
`conventional encryption algorithms” and invited the parties to address this further.
`
`
`
`
`
`
`-5-
`
`
`
`
`
`

`

`
`
`
`
`
`ID, 14. PO declined the Board’s invitation, contending the frame encryption
`
`
`
`function “is not the same thing as an encryption transformation, such as … DES.”
`
`POR at 17. Notably, PO did not argue, and the ’673 patent never suggests, that the
`
`frame encryption function cannot include AES/DES.3
`
`The ’673 specification uses DES/AES to encrypt selected portions of frames.
`
`Ex-1001, 3:30-33, 8:19-30 (“[O]nce the encryption offset has been generated[,]”
`
`DES/AES “may be applied to the frame portion encrypted pursuant to step 718.”);
`
`Ex-1019, ¶¶15-21. Experts for Petitioners and PO agree that an encryption
`
`algorithm is required for encrypting selected portions of frames. Ex-1003, ¶¶75,
`
`115, 159-160; Ex-1019, ¶19; Ex-1029, 208:18-209:2.
`
`C. The challenged claims do not require location to be specified in
`bytes.
`For frame encryption/decryption function, PO only disputes whether Ground
`
`1 specifies the location by layout or offset. PO and Dr. Nielson argue that “[t]he
`
`Patent leaves no ambiguity that ‘offset’ refers to a byte offset.” POR, 59; Ex-2008,
`
`¶144. However, Dr. Nielson contradicted this opinion during his deposition. Ex-
`
`1029, 202:19-203:14 (“Q. Is it your opinion that when the claims refer to offset,
`
`
`3
`PO’s infringement contentions cite AES to argue that the frame encryption
`function is met. Ex-1024, 24-25; Ex-1023, 0022; Ex-1029, 171:22-172:6.
`
`
`
`
`
`
`-6-
`
`
`
`
`
`

`

`
`
`
`
`
`offset refers to nothing more than a byte offset? … A. … so I suppose that could
`
`
`
`be not in bytes.”).
`
`Dr. Nielson’s deposition answer was correct: while bytes are used in some
`
`embodiments, the ’673 specification uses broader language of “units” and makes
`
`clear that bytes are just one non-limiting example of the units in an encryption
`
`layout. Ex-1001, 6:25-38 (“In an exemplary embodiment… twelve data units (e.g.,
`
`bytes) would be encrypted at the location consistent with the applicable encryption
`
`layout format”); Ex-1019, ¶23. The specification provides an example where the
`
`“unit” is significantly larger than a byte: “if five units of data are to be encrypted
`
`and the frame size is ten units, any resulting offset will be constrained to be
`
`between one and five units.” Ex-1001, 7:53-8:4.4
`
`The ’673 patent allows location and size to be specified based on “units,”
`
`which PO admits includes slices and macroblocks. POR, 7 (“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).”). Therefore, PO
`
`
`4 Here, the frame is 10 units. The “unit” cannot be a byte because 10 bytes would
`be on the order of pixels, not a frame. A pixel is 8, 16, or 32 bits (1-4 bytes), and
`typical frames had 640x480 (307,200) pixels. Ex-1001, 1:35-40. Ex-1019, ¶¶23-24.
`
`
`
`
`
`
`-7-
`
`
`
`
`
`

`

`
`
`
`
`
`admits the prior art specifies location, consistent with the Board’s construction and
`
`
`
`the ’673 specification.
`
`A POSITA would have understood “unit” as a broad term that includes
`
`known units in video data. Ex-1019, ¶¶22-25. The ’673 specification discloses
`
`encryption/decryption of MPEG video. See Ex-1001, 5:55-6:24, 7:15-52, 9:23-39,
`
`10:52-55, 10:60-11:16, FIG. 5. MPEG video frames are organized around units
`
`that determine the location of data within the frame. Ex-1019, ¶25. Slices and
`
`macroblocks are common units of video data. Id.; Ex-1006, 22:63-23:7 (“Such
`
`units may consist of … sub-frame units (such as … macro blocks…)”); Ex-1005
`
`(Fetkovich), 4:30-44 (“… an MPEG stream can be described as including the
`
`following units: … picture, slice, and macroblock.”).
`
`When asked whether slices were MPEG “video units,” Dr. Nielson referred
`
`to Demos and stated, “I would say that slices are either a unit in MPEG-4 or there
`
`is a similar concept.” Ex-1029, 148:22-149:20. “So for the timeframe for Demos
`
`here… definitely macroblocks are a unit in the MPEG-4 standard …” Ex-1029,
`
`150:5-19.
`
`Beyond offset, the ’673 patent explains that “[f]rames may support
`
`numerous encryption layout approaches” (Ex-1001, 5:41-43), including header,
`
`middle, and as Dr. Nielson admits, other layouts. Ex-1029, 198:12-199:6.
`
`Dr. Nielson admitted that “layout” is not synonymous with “offset”. Ex-1029,
`
`
`
`
`
`
`-8-
`
`
`
`
`
`

`

`
`
`
`
`
`201:12-202:15. Therefore, the ’673 patent encompasses broader notions of location
`
`
`
`that are not limited to bytes.
`
`Ignoring the broader disclosures in the specification, PO asks the Board to
`
`limit “frame encryption/decryption function” to specific examples. This is
`
`improper, and the Federal Circuit has repeatedly warned against it. See, e.g.,
`
`Phillips v. AWH Corp., 415 F.3d 1303, 1323 (Fed. Cir. 2005); Nazomi
`
`Communications, Inc. v. ARM Holdings, PLC, 403 F.3d 1364, 1369 (Fed. Cir.
`
`2005).
`
`PO concedes that Fetkovich “specif[ies] portions of the frame to be
`
`encrypted…” POR, 23, 31. PO only disputes whether it specifies “location” in
`
`bytes—which, as explained above, is not required by the claims. Therefore,
`
`Fetkovich satisfies the Board’s construction of frame encryption function.
`
`Demos teaches “location” because it specifies a location to encrypt based on
`
`“units” of video data including AC and DC coefficients. Ex-1006, 23:37-42 (“Sub-
`
`units of frames may be encrypted….”), 23:37-24:19. The ’673 patent states that the
`
`location of encrypted portions may be specified based on “units.” Ex-1001, 6:31-
`
`35, 8:1-4, 8:21-24. As noted in the ID, Demos specifies the portions to be
`
`encrypted by layout or offset. ID, 15-16. Therefore, Demos satisfies this limitation.
`
`Ex-1019, ¶6.
`
`
`
`
`
`
`-9-
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`PO contradicts its own arguments.
`D.
`PO argues that slices and macroblocks do not “have a fixed ‘location’ in the
`
`frame.” POR, 23. However, the ’673 patent does not require the location of the
`
`encrypted portion to be the same for each frame—in some embodiments the
`
`location of the encrypted portion for each frame varies. See, e.g., Ex-1001, FIG. 5.
`
`6:3-24.
`
`Moreover, PO contradicts its own district court allegations, which rely on
`
`encrypting portions of slices within a frame (which, according to PO, change
`
`location). For the frame encryption function, PO accuses H.265 encryption of
`
`selected NAL units (slices), including parameters that specify portions of NAL
`
`units within a frame to encrypt. Ex-1024, 17-21 (“… For example, within the first
`
`sample, subsample 8 is an IDR slice (as shown below), a NAL unit containing
`
`video information. This subsample contains 80 encrypted bytes and 11
`
`unencrypted bytes.”). As PO admits, a NAL unit is a slice. Ex-1024, 22 (“The IDR
`
`slice and TRAIL_R slices discussed above are VCL NAL units and carry frame
`
`information.”); Ex-1025, 0023, 0029; Ex-1029, 178:14-180:17, 187:25-189:22.
`
`Therefore, PO alleged the frame encryption function is satisfied by
`
`specifying the location of encrypted portions of a frame based on slices. Those
`
`slices (NAL units) are variable in size and not “fixed” bytes that PO now contends
`
`are necessary. Ex-1025, 0052, 0082; Ex-1029, 193:10-194:8.
`
`
`
`
`
`
`-10-
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`Even if “fixed” location were required, it is nonetheless met. Fetkovich
`
`teaches a delay parameter that includes a delay of zero. Ex-1005, 5:57-60
`
`(“Delay… This number is zero-origin”). In other words, encryption is applied to
`
`the first macroblock or slice of the selected frame—which has a fixed location.
`
`E. Using bytes was not a “unique approach.”
`PO concedes that partial encryption was known, contending the ’673 patent
`
`had a “unique approach” of using bytes instead of frame sub-structures. POR, 26.
`
`However, PO’s specification support does not mention bytes; it vaguely references
`
`“various encryption techniques” and an “encryption layout.” Ex-1001, 5:25-29.
`
`Indeed, the phrase “frame sub-structures” appears nowhere in the ’673 patent.
`
`During prosecution, the Applicant never mentioned bytes or sub-frame
`
`structures. The sole Office Action, in describing the “frame encryption function,”
`
`cited portions of Nardone that do not explicitly specify location/size using bytes.
`
`Ex-1002, 0072-0073; Ex-1010, 4:14-5:9. In response, the Applicant appears to
`
`have conceded that Nardone teaches the frame encryption function by amending
`
`claim 1 to add other limitations including, e.g., a key table. Ex-1002, 0092.
`
`The prior art is replete with partial frame encryption based on bytes. O’Brien
`
`encrypts a portion of selected frames “from one byte to an entire frame.” Ex-1007,
`
`¶¶0041-0042. Matsuda encrypts a fixed data length of N bytes in each I frame. Ex-
`
`1026, 145:3-8. Dr. Nielson’s opinion regarding the novelty of using bytes did not
`
`
`
`
`
`
`-11-
`
`
`
`
`
`

`

`
`
`
`
`
`include analysis of O’Brien, Matsuda, or other references (see Ex-2008, ¶80; Ex-
`
`
`
`1029, 231:21-233:7, 235:22-236:4, 237:18-238:24), even though O’Brien was
`
`discussed in the Petition. Pet., 7, 16-17.
`
`F.
`
`The claims cannot be limited to using bytes, regardless of
`purported benefits.
`None of the challenged claims mention byte-based encryption. The Board’s
`
`construction does not mention bytes. PO seeks to limit the Board’s construction to
`
`specific examples in the ’673 specification. Even if those examples had benefits, it
`
`would still be improper to limit the claims to those examples because none of the
`
`purported benefits constitute “clear and unmistakable” disavowal of embodiments
`
`lacking the benefits. i4i Ltd. P'ship v. Microsoft Corp., 598 F.3d 831, 844 (Fed.
`
`Cir. 2010), aff'd, 564 U.S. 91, 131 S. Ct. 2238, 180 L. Ed. 2d 131 (2011).
`
`PO’s supposed benefits are irrelevant and also incorrect. First, PO argues
`
`that “the main embodiment of the ’673 patent”—“header layout”—cannot function
`
`if modified to use sub-frame structures. POR, 27. But “header layout” is not a main
`
`embodiment; it is one of “numerous encryption layout approaches.” Ex-1001,
`
`5:41-43; Ex-1019, ¶27. Furthermore, Ground 1 combines prior art—it does not
`
`
`
`
`
`
`-12-
`
`
`
`
`
`

`

`
`
`
`
`
`modify the ’673 patent and does not require encrypting both the header and
`
`
`
`selected macroblocks/slices.5
`
`Second, PO claims that Fetkovich does not allow CPU processing to be
`
`bounded. POR, 27-28. Fetkovich states otherwise, explaining that “the ability to
`
`partially encrypt a transmission allows a system to control the amount of resources,
`
`for example, CPU cycles …” Ex-1005, 3:15-39. PO admits Fetkovich’s inventor
`
`was a POSITA “and more likely an expert in the field.” POR, 48; Ex-1029, 89:3-
`
`16. Therefore, experts in the field agreed that Fetkovich provided bounded
`
`encryption years before the ’673 patent.
`
`Third, without support, PO argues the ’673 patent enabled “generic
`
`decoders,” in contrast with “specialized decoder[s]” that “could perform both the
`
`decryption and decompression.” POR, 7-9. However, the only decoder in the ’673
`
`specification includes decryption and decompression—a specialized decoder
`
`according to PO. Ex-1001, 10:60-11:16 (“[V]ideo decoder 1230 containing a video
`
`decryption module 1237 … the decrypting digital video decoder 1230 also includes
`
`an entropy decompression unit 1235 and a video processing unit 1240.”), FIG. 12.
`
`Byte-based encryption would not enable “generic decoders” because it still
`
`
`5
`Even if required, the entire frame does not have to be decrypted at once—the
`frame header can readily be decrypted before slices/macroblocks within the frame
`are. Ex-1019, ¶¶26-27.
`
`
`
`
`
`
`-13-
`
`
`
`
`
`

`

`
`
`
`
`
`requires parsing the video structure to identify the frame boundaries of variable-
`
`
`
`sized frames—this requires both video decryption and decompression capabilities.
`
`Ex-1029, 156:14-16, 156:25-157:6, 156:13-22; Ex-1001, 2:5-7.
`
`II.
`
`Synchronized Frame Decryption Stream
`PO admits this limitation is met by Ground 1.
`A.
`Claim 1 recites “generating frame decryption information” and then
`
`“assembling” that information with video frames “to produce the protected
`
`stream.” PO stated in district court that frame decryption information is
`
`synchronized with encrypted frames by interleaving the information with
`
`corresponding frames, e.g., as opposed to appending the information after all video
`
`frames. Pet., 50; Ex-1011, ¶276 (“…Netflix synchronizes the frame decryption
`
`information by interleaving the PIFF Sample Encryption Boxes (uuid) and media
`
`data, or ‘mdat,’ boxes throughout the MP4 file.”); Pet., 50.
`
`Petitioners analyzed this element consistent with the PO’s admissions and
`
`the plain and ordinary meaning of “synchronized,” including express teachings of
`
`“synchronizing signals” in Ueno. See Pet., 46-51. PO does not dispute that Ground
`
`1 teaches generating, assembling, and interleaving the frame decryption
`
`information with corresponding video frames. Incredibly, PO argues against
`
`Ground 1 in direct contradiction of its district court representations, arguing that
`
`“[e]ven if the combination interleaves encryption keys with frames … that is not
`
`
`
`
`
`
`-14-
`
`
`
`
`
`

`

`
`
`
`
`
`shown to synchronize the two.” POR, 55. PO makes no attempt to explain this
`
`
`
`contradiction and cannot do so for the first time on Sur-Reply.
`
`PO argues frame decryption data must be sent with each frame and include
`
`frame numbers. POR, 45, 57-58. But PO never explains why this would be
`
`necessary, other than suggesting the claim should be limited to the embodiment of
`
`FIG. 9. POR, 33. This would be improper under Federal Circuit precedent. See
`
`supra, 9.
`
`PO also makes vague references to the word “stream” even though its expert
`
`Dr. Nielson admitted that “stream” has “little meaning” when interpreted by itself.
`
`Ex-1029, 216:19-217:8. Dr. McDaniel explained that the combination of Ground 1
`
`includes a synchronized stream. When asked “what makes [the frame encryption
`
`information] a stream,” Dr. McDaniel explained, “I would have to think about that
`
`some. You know, certainly what’s disclosed in the combination represents a stream
`
`of information which is sent with the video.” Ex-2009, 95:5-15. The POR omitted
`
`the italicized sentence, without ellipses or any other indication, and represented to
`
`the Board that Dr. McDaniel was unable to provide an answer. POR, 37. That is
`
`untrue.
`
`Lastly, contrary to PO’s representations (POR, 34-36), “synchronized frame
`
`decryption stream” was not the sole reason for allowance. It was but one of several
`
`
`
`
`
`
`-15-
`
`
`
`
`
`

`

`
`
`
`
`
`amendments including the addition of a “table of encryption keys.” Ex-1002, 0141-
`
`
`
`0148; Ex-1003 ¶¶84-85.
`
`Lossy channels are irrelevant to synchronization.
`B.
`PO argues about lossy channels, implying the requirements for synchronized
`
`frame decryption stream vary depending on whether it is sent over lossy or lossless
`
`channels. POR, 55-59. However, the challenged claims do not mention channels at
`
`all. Nor does the specification say anything about networking protocols, packets, or
`
`channels, either lossy or lossless. Thus, synchronization cannot include
`
`requirements about network delivery or packet ordering.
`
`There is simply no basis to argue that a synchronized frame decryption
`
`stream would need particular features to account for lossy or lossless channels.
`
`Instead, as PO admitted, synchronization is accomplished by interleaving frame
`
`decryption information with corresponding video frames. Ex-1011, ¶276.
`
`C. Ground 1 includes sending decryption information with each
`frame.
`The combination of Ground 1 starts with Ueno as the primary reference,
`
`with Ueno’s general encryption framework as a base and adding details of partial
`
`encryption and video streaming from Fektovich and Demos. Pet., 18; Ex-1003
`
`¶110. Therefore, the combination begins with Ueno’s key table and its teaching
`
`that, “in some cases, the cipher key number is … transmitted with each of frames.”
`
`Ex-1004, 2:5-9; Pet., 50-51. Fetkovich’s encryption parameters are included with
`
`
`
`
`
`
`-16-
`
`
`
`
`
`

`

`
`
`
`
`
`Ueno’s key number, which is sent with each frame. Pet., 20; Ex-1003, ¶115. Given
`
`
`
`that Ueno provides this teaching in the background section, there is no ambiguity
`
`that this feature was known in the art.6
`
`Petitioners explained at least three motivations for applying Ueno’s
`
`teachings, one of which remains entirely unrebutted. Pet., 50; Ex-1003 ¶186.
`
`Demos provides express and unrebutted motivation.
`1.
`Sending decryption information with each frame facilitated Demos’
`
`teachings of only encrypting frames from I and P frames, every other minute of
`
`frames, or frames of particularly important plot or action scenes. Ex-1003 ¶¶128-
`
`132, ¶188 (citing discussion for claim 3), ¶¶194-195; ID, 15; Pet., 51; Ex-1006,
`
`22:29-44, 23:26-24:18; Ex-1019, ¶¶7-9.7 Ueno provides a straightforward
`
`mechanism, which PO did not dispute, for turning encryption on/off using key
`
`number zero. Ex-1003 ¶195. Sending this information with each frame provides a
`
`simple mechanism that is flexible enough to turn encryption on/off on a per-frame
`
`basis for Demos’s selection of individual frames and potentially arbitrary selection
`
`of important frames or alternating periods. Ex-1003 ¶195; Ex-1019, ¶12. The
`
`
`6
`The ID found that Ueno explicitly teaches this limitation. ID, 19.
`7
`Fetkovich reinforces Demos with additional motivation: “an MPEG stream
`may be transmitted using varying levels of encryption depending upon the
`sensitivity of the video material.” Ex-1005, 4:30-63; Pet., 24.
`
`
`
`
`
`
`-17-
`
`
`
`
`
`

`

`
`
`
`
`
`combination of Ueno, Fetkovich, and Demos provides this synergy with small
`
`
`
`overhead in terms of bytes/second. Ex-1003 ¶195; Ex-1019, ¶¶10-13.
`
`PO ignored this motivation from Demos, which therefore remains
`
`unrebutted. PO cannot attempt to address it for the first time on Sur-Reply. Based
`
`on the unrebutted evidence, a POSITA had at least one motivation—all KSR
`
`requires. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 419-422 (2007).8
`
`2. Ground 1 improved reliability.
`Sending the key number with each frame minimizes data loss because any
`
`synchronization discrepancies would be automatically recovered at the next frame.
`
`Pet., 51; Ex-1003, ¶187. PO argues that the same number of frames would be lost
`
`“on average” compared to sending the key only when updated. POR, 50. However,
`
`PO’s focus on “average” loss ignores the number of consecutive lost frames. In
`
`PO’s example, sending the key when updated would result in 100 consecutive lost
`
`frames, until the next key update (over 3 seconds of interruption for 30 fps video).
`
`Sending the key with each frame results in randomly-distributed lost frames, with
`
`each loss recovered at the next frame—a barely noticeable 1/30 of a second. Ex-
`
`1019, ¶¶28-29.
`
`
`8
`Hulu v. Sound View is inapposite because the Petitioners explained several
`motivations to apply Ueno’s explicit teachings.
`
`
`
`
`
`
`-18-
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`The prior art knew how to account for channel loss. Both Ueno and
`
`Fetkovich maintain synchronization in lossy channels, including, for example, with
`
`synchronization signals. Pet., 23, 43-48; Ex-1004, 1:67-2:9, 4:13-17, 6:34-39,
`
`7:28-32, Figs. 17, 4, 6; Ex-1005, 7:35-67.
`
`Moreover, the combination is not limited to lossy channels.9 Ueno and
`
`Demos both state that their teachings are not limited to any particular transmission
`
`system. Ex-1004, 1:21-31 (“A transmission line 3 connecting the transmitter 1 and
`
`the receiver 2 is not particularly limited …”); Ex-1006, 29:9-14.
`
`The combination improves security.
`3.
`Regular key changes make cracking the keys more difficult because
`
`cryptographic attacks rely on having large amounts of data encrypted using the
`
`same key. Ex-1003 ¶116. Ueno allows rapid key changes by sending a key
`
`number, rather than the key itself, and managing keys in a key table. Ex-1003
`
`¶116; Ex-1019 ¶¶32-33. Sending decryption information with each frame improves
`
`security by allowing frequent key changes. Ex-1003 ¶¶186-188.
`
`PO does not dispute that this method would improve security; PO only
`
`argues it was “not common”10 because of limited device capabilities in 2002,
`
`
`9 POSITAs knew how to use lossless channels for video streaming. Ex-1019, ¶30.
`10 Dr. Nielson could not provide any criteria to determine whether technology is
`“common.” Ex-1029, 104:8-106:8. He admitted he did no investigation before
`
`
`
`
`
`
`
`-19-
`
`
`
`
`
`

`

`
`
`
`
`
`including limited dial-up Internet connections in 2002. POR, 40-42. This argument
`
`
`
`is unsupported. In fact, Dr. Nielson admitted that broadband Internet, such as DSL,
`
`was available in 2002. Ex-1029, 224:19-21, 225:8-13. Moreover, PO did not cite
`
`any authority (it cannot) for the notion that a combination must be “common.”
`
`Regardless of whether sending key numbers with each frame was common,
`
`it makes sense for this particular combination as Petitioners explained based on the
`
`specific teachings of the references (Pet., 18-28), which PO did not address.
`
`Notably, PO argues that “[i]n downloadable systems, security was improved by
`
`increasing key size, not by changing the key with every frame.” POR, 40. This is
`
`irrelevant because the combination is based on video streaming, which PO
`
`distinguished from video downloads. Pet., 18; Ex-1030, 40 (“Lindahl is not even
`
`about streaming media… Lindahl utilizes a system that downloads an entire
`
`media…”), 40-43.
`
`Moreover, Fetkovich teaches changing the key frequently, including
`
`multiple times a frame: “the key is to be updated every n slices” (there are many
`
`slices per frame), or “the key is to be updated every n bytes” (there are many bytes
`
`per frame). See Ex-1005, 5:61-6:2; Ex-1019, ¶31. Fetkovich thus provides express
`
`motivation.
`
`
`arguing “it was not generally common in or around 2002 to send the encryption
`key with each and every frame of video.” Ex-1029, 107:9-22; Ex-2008, ¶127.
`
`
`
`
`
`
`-20-
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`PO argues that three times as many processor cycles are needed to setup a
`
`key as compared to one decryption operation, which for AES encrypts a 128-bit
`
`block of data. POR, 43. However, many blocks are decrypted for each frame, and
`
`Dr. Nielson admits the “key setup cost” would only be incurred once “for each
`
`frame.” Ex-2008 ¶108; Ex-1019, ¶¶32-33. This would not have discouraged a
`
`POSITA—it certainly did not discourage Fetkovich, who PO admits was a
`
`POSITA. POR, 48.
`
`PO’s argument—that changing keys per frame was uncommon—is
`
`contradicted by positions it took in district court (CDCA-2:19-cv-1602), which
`
`allege infringement based on AES in CTR mode—the predominant mode for the
`
`most widely-used encryption algorithm in 2002. Ex-1027, 71:15-16; Ex-1023,
`
`0022-0023; Ex-1029, 173:6-18. According to PO, AES-CTR (prior art from before
`
`2002) changed encryption keys multiple times a frame, or even every byte
`
`according to Dr. Nielson. Ex-1029, 167:21-171:9. PO alleges that “[t]he AES-CTR
`
`cipher generates frame encryption keys (i.e., the key stream output of the AES-
`
`CTR cipher)” where each frame encryption key generated this way encrypts one
`
`block (128 bits) of data.11 Ex-1024, 25-26. Dr. Nielson testified that AES in CTR
`
`
`11 AES-CTR is an AES operation mode with 128-bit (16-byte) block size. Ex-
`1029, 169:11-15.
`
`
`
`
`
`
`-21-
`
`
`
`
`
`

`

`
`
`
`
`
`mode encrypts one byte of data using one byte of the keystream, “us[ing] one byte
`
`
`
`of the keystream and then the next[.]” Ex-1029, 171:22-172:14.
`
`PO argues at length against “sending the key” with each frame. POR, 39, 41,
`
`44, 45, 47-48, 50-58. For example, PO contends “keys should not be multiplexed
`
`in the stream in an ‘overt[]’ manner because that would reduce the ‘overall
`
`security.’” POR, 51.12 But PO ignores its own exhibit. PO relies on “security
`
`through obscurity,” which its exhibit admits is considered “a Bad Thing” in
`
`cryptography. Ex-2019, 2. “There are really no compelling arguments against
`
`public disclosure of security algorithms and protocols.” Id. Fetkovich never
`
`mentions “security through obscurity,” and PO offers no reason Fetkovich would
`
`follow a “Bad Thing.” Id.
`
`Moreover, Ground 1 is based on Ueno, which “changes keys by sending key
`
`numbers, rather than keys themselves.” Pet., 21. Sending key numbers are smaller
`
`and safer than keys. By storing keys in tables and using corresponding key
`
`numbers, Ueno enables rapid key changes (Ex-1003, ¶116) with less initialization
`
`time than using newly-received keys. Dr. McDaniel explained that, given the small
`
`size of key numbers, “the security and reliability benefits … far outweighed the
`
`
`12
`PO misrepresents Fetkovich, which cautions that overt transmissions may
`have less overall security but nonetheless teaches sending parameters in defined
`PES or transport packets. Ex-1005, 8:11-26.
`
`
`
`
`
`
`-22-
`
`
`
`
`
`

`

`
`
`
`
`
`miniscule increase in data size.” Ex-1003, ¶187, ¶138 n. 5. PO does not dispute
`
`
`
`this fact.
`
`Therefore, PO’s arguments about the difficulty of sending keys are irrelevant
`
`to the combination, which uses Ueno’s key tables and numbers.13 PO attacks
`
`Fetkovich by itself without consi