`
`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-00648
`U.S. Patent 9,998,515
`––––––––––
`
`PETITIONERS’ REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`TABLE OF CONTENTS
`
`B.
`
`C.
`
`V.
`
`
`Introduction ...................................................................................................... 3
`I.
`Dr. Zeger’s opinions are not credible. ............................................................. 4
`II.
`III. The ’515 patent’s explanation of the “retrieving” and “filtering”
`limitations is commensurate with the teachings of Pyle, Lewis and
`Marusi. ............................................................................................................. 5
`IV. The Challenged Claims Are Unpatentable in View of Pyle and Marusi ........ 8
`A.
`Pyle teaches generating manifest file(s) in response to a request
`for content. ............................................................................................. 8
`The combination of Pyle and Marusi teaches the “retrieving”
`and “filtering” limitations. ..................................................................... 9
`Pyle teaches generating a top level index file describing each
`asset in the filtered list of assets. ......................................................... 15
`The combination of Pyle and Marusi teaches limitation 1[c]. ............ 16
`D.
`The Challenged Claims Are Unpatentable in View of Lewis and
`Marusi ............................................................................................................ 18
`A.
`Lewis teaches “retrieving…a list of assets…wherein each asset
`is a different stream associated with the piece of content.” ................ 18
`Lewis teaches “filtering…the list of assets.” ...................................... 22
`Lewis Renders Limitations 1[c] and 1[e] Obvious ............................. 25
`1.
`In addition to Marusi, Lewis teaches a “device software
`version” or “version number for an adaptive streaming
`software component” ................................................................ 25
`Lewis teaches “filtering…based on the [device type and
`the recited device software version].” ....................................... 26
`Lewis renders limitation [1f] obvious. ................................................ 26
`D.
`102(e) Prior Art Is Still Prior Art Under the Law ......................................... 26
`VI.
`VII. Unconstitutionality ........................................................................................ 28
`VIII. Conclusion ..................................................................................................... 28
`
`
`B.
`C.
`
`2.
`
`
`
`
`
`
`-2-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`I.
`
`Introduction
`Unable to dispute that the instituted grounds teach generating top-level index
`
`files that take into account the capabilities of different playback devices, DivX
`
`avoids directly addressing the instituted grounds and evidence. DivX’s arguments
`
`suffer from various deficiencies, most notably the failure to address the proposed
`
`combinations as a whole, misrepresenting that the grounds rely solely on the
`
`teachings of one reference when they do not, relying on improperly narrow
`
`constructions of claim terms (while not proposing any terms for construction), and
`
`arguing that the Petition needed to further describe implementation details that are
`
`neither disclosed by the ’515 patent nor explained by its expert.
`
`Further eroding DivX’s arguments is the lack of credible expert testimony.
`
`Dr. Zeger was unable to explain opinions included in his declaration, repeatedly
`
`professing an inability to answer even the most basic questions concerning the art,
`
`such as the use of databases in 2011. While criticizing Petitioners for not
`
`addressing certain claim language (such as “generating”, “retrieving” and
`
`“filtering”) both Dr. Zeger and DivX painstakingly avoid taking any position as to
`
`the meaning of those terms to in order to preserve broader interpretations for the
`
`district court.
`
`
`
`
`
`
`-3-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`II. Dr. Zeger’s opinions are not credible.
`DivX suggests disregarding Dr. Reader’s opinions because some of his prior
`
`testimony has been found conclusory. And, DivX makes the unfounded claim that
`
`Dr. Reader “parrots” the Petition when, in fact, the Petition was based on his
`
`declaration. DivX’s complaints pale in comparison to the record of its expert. In
`
`another case where Dr. Zeger represented a patent owner against Netflix, the Board
`
`found “several significant problems with Dr. Zeger’s testimony.” Netflix, Inc. v.
`
`Realtime Adaptive Streaming, LLC, IPR2018-01189, Paper 42 at 28 (Jan. 15,
`
`2020). Specifically, his testimony was “significantly at odds with the evidence of
`
`the state of the art at the time of the invention” (id., 29), was “based on either a
`
`significant misunderstanding or unfair representation of [a reference]” (id.), and
`
`“appears to be based on an oversimplification of the state of the art at the time of
`
`the invention, which undermines his testimony” (id., 30).
`
`Dr. Zeger’s opinions here should similarly be accorded little weight. To
`
`start, he would not even admit that Pyle or Lewis teach adaptive bit rate streaming
`
`systems – he would “have to think about it.”1 Ex. 1010, 89:6-91:14. Despite being
`
`a professor of electrical and computer engineering, Dr. Zeger was unable or
`
`
`1 It could not be any clearer that the references teach adaptive bitrate streaming.
`See, e.g., Ex. 1005 7:45-53; Ex. 1006 [0028] (describing support for HTTP Live
`Streaming)
`
`
`
`
`
`
`-4-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`unwilling to describe the state of the art in 2011. For example, he was unable to
`
`define what a “database” meant to a POSITA in 2011. Id., 26:16-28:3. Dr.
`
`Zeger’s declaration suggests that a “list” or “retrieving list” is something that a
`
`POSITA would need to have explained. But, at his deposition, he admitted that
`
`lists are a “very well-known concept” occurring in “engineering,” “computer
`
`science, in programming languages.” Ex. 1010, 113:19-114:10. He also admitted
`
`that “a programmer that understands lists as I do would certainly know how to
`
`construct a list” and that there is even a programming language “LISP”, which
`
`“stands…for list processing,” that “specifically deals with lists.” Ex. 1010,
`
`114:12-23. And, despite the “retrieving” and “filtering” limitations being the focus
`
`of his opinions, Dr. Zeger did not consider what the patent says about these
`
`limitations. Supra, Section III.
`
`III. The ’515 patent’s explanation of the “retrieving” and “filtering”
`limitations is commensurate with the teachings of Pyle, Lewis and
`Marusi.
`DivX has not proposed constructions for “retrieving,” “filtering,” or
`
`“generating,” and Dr. Zeger’s declaration does not explain what those terms mean.
`
`This was no accident because DivX seeks to impress the Board with the idea that
`
`these terms have a specific, narrower meaning for determining invalidity while
`
`preserving its ability to argue that the challenged claims are broader in the co-
`
`pending infringement lawsuits.
`
`
`
`
`
`
`-5-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`The ’515 patent does not describe in detail (let alone provide an algorithm),
`
`for “retrieving…a list of assets” (1[d]) or “filtering…the list of assets.” The patent
`
`discusses these limitations in three columns under the headings “Automatic
`
`Generation of Top Level Indexes” and “Filtering Assets for Inclusion in Top Level
`
`Index Files.” Ex. 1001, 11:12-12:38, 12:39-13:55. None of the examples provide
`
`any more detail for how to perform the retrieving or filtering limitations as
`
`compared to the Petition (see Ex. 1003 ¶¶81, 93-96, 106, 116):
`
`•
`
`First (Ex. 1001, 11:13-57): The patent describes maintaining “a
`
`database of assets” that can be configured “to retrieve and filter
`
`information concerning assets” for generating a top level index. But,
`
`it does not describe how the database performs retrieving or filtering,
`
`and merely gives non-limiting examples of information about assets
`
`that may be stored in the database.
`
`•
`
`Second (12:8-12 and FIG. 4): The patent states that the playback
`
`server retrieves assets (not a list) associated with a request for content,
`
`and then states that the assets are filtered.
`
`•
`
`Third (12:56-65): The patent states that a playback server “can
`
`initially gather information concerning the assets associated with a
`
`specific piece of content…” and in the next sentence states that the
`
`
`
`
`
`
`-6-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`playback server can then “apply one or more filters to the list of
`
`available assets….”
`
`•
`
`Fourth (12:66-13:10 and FIG. 5): The patent refers to a process for
`
`“producing” (not retrieving) “a list of assets” that involves retrieving
`
`assets and “filter[ing] the assets to exclude assets that are not capable
`
`of being played back….”
`
`Over the course of more than an hour, Dr. Zeger was given repeated
`
`opportunities to read columns 11-13 and was asked to identify where the patent
`
`specifically teaches how to perform the “retrieving” and “filtering” limitations.
`
`Ex. 1010, 154:17-199:17. The short answer – reached after a tedious 45 pages of
`
`questioning – is that Dr. Zeger doesn’t know. Even though the gravamen of his
`
`rebuttal opinions is that Dr. Reader didn’t adequately show that the prior art
`
`performs the “retrieving” or “filtering” limitations, Dr. Zeger admitted that he
`
`never even considered what the ’515 patent explains about performing the
`
`retrieving or filtering limitations. Id., 197:21-198:12 (retrieving step), 199:6-
`
`199:18 (filtering step). Despite claiming to have spent tens of hours reviewing the
`
`patent (in addition to the time spent in the deposition), Dr. Zeger was unable (or
`
`more likely unwilling) to identify any other portions of the patent that explain
`
`implementing the retrieving or filtering limitations. Ex. 1010, 197:1-22. In
`
`
`
`
`
`
`-7-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`contrast, Dr. Reader considered the patent’s disclosures in detail. Ex. 1003, 73-116
`
`(describing the lack of disclosure for a number of limitations).
`
`IV. The Challenged Claims Are Unpatentable in View of Pyle and Marusi
`Pyle teaches generating manifest file(s) in response to a request
`A.
`for content.
`DivX’s argument that Pyle only “teaches sending a pre-existing manifest file
`
`in response to a request for content” and thus is “fundamental[ly] different” (POR
`
`2-6) ignores the teachings of FIG. 4 and impermissibly narrows Pyle’s teachings.
`
`The Petition and Dr. Reader relied upon FIG. 4, which depicts responding to
`
`a request for content with a selected manifest or a new manifest (e.g., Pet. 34-35;
`
`Ex. 1003 ¶184):
`
`
`
`DivX and Dr. Zeger did not address FIG. 4 in the POR or declaration.
`
`While admitting that Pyle at 10:57-11:10 teaches creating a new manifest
`
`(POR 4), DivX attempts to distinguish Pyle’s teachings by arguing that the new
`
`manifest is stored after it is created. POR 4-5. Regardless, there is nothing in the
`
`
`
`
`
`
`-8-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`claims that precludes storing a new manifest after it is created in response to a
`
`request, and DivX did not request a construction imposing such a limitation.
`
`DivX’s arguments do not overcome Pyle’s teachings (Pet. 27-29, 32, 34-35).
`
`Dr. Reader explained that Pyle 10:57-11:10 teaches creating a new manifest file
`
`that is customized to the requesting device and the device’s capabilities. Pet. 27-
`
`29; Ex. 1003 ¶165 (explaining how the product identifier in the request is used to
`
`customize the manifest file for limitation 1[c]), 179-181, 184. Dr. Zeger’s opinion
`
`that “a POSITA would not be motivated to modify Pyle’s system to create
`
`customized manifest files for a requesting device on-demand” (POR 5-6) is flatly
`
`contradicted by Pyle’s express teaching that “new manifest file 422 is optimized
`
`for” factors that arise when a request is received, such as “a particular network or
`
`network conditions (e.g., bandwidth, latency, quality of service, etc.)” or
`
`“particular setting or preference or a particular set of settings or preferences (e.g.,
`
`French-speaking, hearing impaired, ratings-based content block…).” Ex. 1004,
`
`10:57-11:10.
`
`B.
`
`The combination of Pyle and Marusi teaches the “retrieving” and
`“filtering” limitations.
`DivX’s arguments ignore the Petition’s explanation that the challenged
`
`claims “are rendered obvious by the combination of Pyle’s system for dynamically
`
`composing manifest files with Marusi’s database teachings” and instead argues
`
`that Pyle does not teach the retrieving, filtering, and generating limitations.
`
`
`
`
`
`
`-9-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`Pet. 19. Notably, the POR and Dr. Zeger failed to rebut the Petition’s (Pet. 19-22)
`
`and Dr. Reader’s (Ex. 1003 ¶¶143-151) explanations of the combination or even
`
`the motivation to combine.
`
`But the Federal Circuit has rejected this line of attack—obviousness cannot
`
`be overcome by attacking references individually. See In re Merck & Co., 800
`
`F.2d 1091, 1097 (Fed. Cir. 1986); Bradium Techs. LLC v. Iancu, 923 F.3d 1032,
`
`1050 (Fed. Cir. 2019) (“A finding of obviousness, however, cannot be overcome
`
`by attacking references individually…”). The Board has rejected numerous past
`
`attempts by DivX’s lead counsel to raise this improper argument. See Google
`
`LLC. v. Seven Networks, IPR2018-01116, Paper 36 at 29 (PTAB Feb. 25, 2019)
`
`(“On this record, Patent Owner’s argument is not persuasive because it addresses
`
`Srinivasan individually, not the combination of Tian, Zhang, and Srinivasan
`
`proposed by Petitioner.”); TCL Corp. v. Polaris Powerled Techs., IPR2020-00961,
`
`Paper 11 at 50 (PTAB Jan. 21, 2021); Apple Inc. v. MPH Technologies Oy,
`
`IPR2019-00820, Paper 37 at 61 (PTAB Sept. 24, 2020); Apple Inc. v. MPH
`
`Technologies Oy, IPR2019-00819, Paper 37 at 35 (PTAB Sept. 24, 2020); Apple
`
`Inc. v. Seven Networks, IPR2020-00280, Paper 10 at 19 (PTAB Aug. 14, 2020).
`
`The Board should do so again.
`
`DivX and Dr. Zeger’s arguments should be rejected because they did not
`
`address the specific combination of Pyle and Marusi laid out by the Petition
`
`
`
`
`
`
`-10-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`(Pet. 19-22) and Dr. Reader’s declaration (Ex. 1003 ¶¶143-151). In fact, DivX and
`
`Dr. Zeger appear to have ignored those portions altogether, leaving the explanation
`
`of the combination and the motivation to combine unrebutted.
`
`The fact that DivX’s arguments do not address the combination as a whole is
`
`reflected by its blatant mischaracterization that “[t]he Petition relies entirely on
`
`Pyle for the ‘list of assets’….” POR 7 (emphasis added). Petitioner never
`
`contended that Pyle teaches all of the necessary implementation details for
`
`performing list or database operations. Pet. 20; Ex. 1003 ¶146 (“Because storing
`
`and tracking different representations of the same multimedia content using lists or
`
`a database was well-known, Pyle assumes that a POSITA had such knowledge and
`
`does not explicitly describe these basic implementation details. Marusi is an
`
`example of a reference that does describe such techniques.”).
`
`As explained in the Petition and by Dr. Reader, “[i]t would have been
`
`obvious that Pyle’s server retrieves a list of assets when it receives a request for
`
`content because the server must know what assets are available in order to select
`
`the optimal content presentations for the requesting client.” Pet. 30-31; Ex. 1003
`
`¶170. Pyle’s server maintains manifests (a list of assets) associated with an
`
`identified piece of content, where each representation in the manifests is a different
`
`stream associated with a piece of content. Id.; Ex. 2010, 18:22-20:14, 59:5-20,
`
`65:11-24.
`
`
`
`
`
`
`-11-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`
`
`The Petition explains why each manifest file is “a list of assets,” and further
`
`explains why a POSITA “would have found it obvious that all of the manifests
`
`associated with an identified piece of content also forms a list of assets associated
`
`with the identified piece of content because a compilation of lists is itself a list.”
`
`Id., 31-32 (citing Ex. 1003 ¶171).
`
`As to “filtering…the list of assets,” the Petition explains why this limitation
`
`is rendered obvious by Pyle’s teaching of using multiple manifest files to provide a
`
`new or optimized manifest. Pet. 33-34; Ex. 1003 ¶¶178-181. Further, the Petition
`
`explains that the retrieving and filtering limitations are rendered obvious by
`-12-
`
`
`
`
`
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`Marusi’s database teachings. Pet. 20-22, 33-34; Ex.1003 ¶¶144-151, 177, 182; Ex.
`
`1005, [0143]. The Board should reject any argument that the Petition does not
`
`adequately describe the claimed features because the Petition’s teachings are
`
`commensurate with the ’515 patent’s disclosure. It is well-established that aspects
`
`of claimed features that are not described by a patent itself demonstrates that they
`
`are within the skill and knowledge of a POSITA. Uber Techn., Inc. v. X One, Inc.,
`
`957 F.3d 1334, 1339 (Fed. Cir. 2020); In re Epstein, 32 F.3d 1559, 1568 (Fed. Cir.
`
`1994).
`
`Turning to DivX’s arguments, Section II.B.2 comes closest to addressing
`
`Ground 1 but falls short because DivX does not address any of Marusi’s teachings.
`
`DivX’s first argument (POR §II.B.2.a) is premised on improperly construing “a list
`
`of assets” to mean “a single ‘list of assets’” (POR 12-13; Ex. 2016 ¶38) as opposed
`
`to the correct construction “one or more list of assets.” The only evidence DivX
`
`offers to support its narrow construction that “a” means “single” is the claim text
`
`and the ipse dixit of its expert. Id. The Board should reject DivX’s construction
`
`because it goes against decades of precedent finding that “a” means “one or more”
`
`except in limited circumstances that are not present here. See KCJ Corp. v. Kinetic
`
`Concepts, Inc., 223 F.3d 1351, 1355 (Fed. Cir. 2000) (“This court has repeatedly
`
`emphasized that an indefinite article ‘a’ or ‘an’ in patent parlance carries the
`
`meaning of ‘one or more’ in open-ended claims containing the transitional phrase
`
`
`
`
`
`
`-13-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`‘comprising.’ Unless the claim is specific as to the number of elements, the article
`
`‘a’ receives a singular interpretation only in rare circumstances when the patentee
`
`evinces a clear intent to so limit the article. Under this conventional rule, the claim
`
`limitation ‘a,’ without more, requires at least one.”) (citations omitted). Thus, the
`
`Board should reject DivX’s flawed argument that multiple manifests in Pyle cannot
`
`not satisfy “a list of assets” because it is premised on an improperly narrow
`
`implicit construction.
`
`DivX’s second argument (POR §II.B.2.b) similarly lacks merit. DivX points
`
`to one paragraph in the Petition (while ignoring the other paragraphs addressing
`
`the same limitation) to argue that the Petition relies on inherency for the
`
`“retrieving” limitation when the limitation is rendered obvious by Pyle’s and
`
`Marusi’s teachings (Pet. 30-33; Ex. 1003 ¶¶169-177). In paragraph 175,
`
`Dr. Reader explained that a POSITA would have found it “obvious for Pyle’s
`
`server to retrieve a list of assets associated with the identified piece of content”
`
`because it uses the multiple manifests to choose an optimal manifest for a
`
`requesting device. In paragraph 176, he explains how another passage of Pyle
`
`“suggests retrieving all of the manifests associated with requested content” so that
`
`the server could choose among manifests and the representations contained in the
`
`manifests. Finally, in paragraph 177, Dr. Reader explains how the retrieving
`
`limitation is also taught by Marusi.
`
`
`
`
`
`
`-14-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`C.
`
`Pyle teaches generating a top level index file describing each asset
`in the filtered list of assets.
`DivX’s arguments that the combination of Pyle and Marusi does not teach
`
`“generating” ignores that Pyle teaches generating a top level index in two ways.
`
`First, Pyle teaches generating a top level index file by creating a new manifest file
`
`in response to the request for content that is transmitted to the requester. Pet. 34-
`
`35; Ex. 1003 ¶184; see supra Section IV.A. DivX does not address that evidence
`
`or explain how creating a new manifest in response to a request for content does
`
`not teach “generating.” Second, Dr. Reader identifies another way that Pyle
`
`teaches the generating limitation – when Pyle transmits either a new manifest file
`
`or a selected manifest file (one that existed before the request for content), a copy
`
`of the new or selected manifest file is placed in memory for transmission. Pet. 35;
`
`Ex. 1003 ¶184. Dr. Zeger made no attempt to disagree with this opinion.
`
`DivX’s argument that the Petition fails to demonstrate that the generated top
`
`level index file describes each asset is without merit, and is not supported by expert
`
`testimony. The Petition explains that the new manifest file or the selected manifest
`
`file is the result of the earlier retrieving and filtering limitations, and Pyle expressly
`
`teaches that its manifest files describe the location of the included representations
`
`along with other attributes, giving an XML document as an example of a manifest
`
`file. Pet. 35; Ex. 1003 ¶¶185-186. The Petition explains that it would have been
`
`
`
`
`
`
`-15-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`obvious to include a bitrate along with the location so that a device can switch
`
`between tracks. Id.
`
`D. The combination of Pyle and Marusi teaches limitation 1[c].
`In view of the combined teachings of Pyle and Marusi, as well as
`
`Dr. Reader’s supporting explanations, a POSITA would have found it obvious to
`
`identify, based on the product identifier, device capabilities including a device type
`
`and a device software version indicating a version number for an adaptive
`
`streaming software. For example, the Petition points to Marusi’s teaching of
`
`terminal identification information:
`
`The TAC code is a portion of the 15-digit international
`mobile equipment identity (IMEI) code or the 17-digit
`international mobile equipment identity and Software
`Version (IMEISV) code used to uniquely identify
`wireless devices.
`Ex. 1005, [0113], [0017-0020]; Pet. 26-27, 29. Marusi teaches that the IMEI or
`
`IMEISV code is the terminal identification information transmitted by the mobile
`
`device. Id., [0114]. DivX argues that Marusi and Dr. Reader have it wrong that
`
`the TAC code indicates a software version. But, whether Marusi correctly
`
`describes IMEISV and TAC codes is irrelevant because Marusi expressly teaches a
`
`POSITA to use terminal identification information that includes a software version.
`
`See In re Clark, 420 F. App’x 994, 998 (Fed. Cir. 2011). Regardless, the rationale
`
`for considering a device type and software version is expressly taught by Marusi’s
`-16-
`
`
`
`
`
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`paragraph 6. Id., [0006] (“Content providers…used to give a list of mobile phones
`
`which support the proposed content…. This does not solve the problem of
`
`incompatibility and not all users know the exact model they have, because the
`
`formats supported sometimes vary for the same model according to the version,
`
`i.e., the last software upgrade of the actual phone.”); Pet. 29.
`
`Despite Marusi’s teaching that a software version is relevant for selecting
`
`compatible media content, Dr. Zeger stated that he is “not really aware of why [a
`
`POSITA would have known that the software version of a media player is a
`
`relevant concern in choosing media for playback] would be true.” Ex. 1010,
`
`234:14-235:1. Dr. Zeger’s answer either: (1) demonstrates his lack of knowledge
`
`in this field or is (2) a false statement.
`
`Consistent with Dr. Reader’s explanation of the state of the art, the Thoen
`
`reference, filed seven years before the priority date, describes providing different
`
`versions of video content depending upon the version of the media player2
`
`(e.g., Windows Media Player version 6.4 versus version 7.1 or higher). Ex. 1009,
`
`3:66-14:7 (“For instance, there may be two versions of the video content…, but
`
`one version of the video can be played by the computer 14 operating the Windows
`
`
`2 Dr. Zeger was unable to describe any difference between a media player and an a
`adaptive streaming software component (Ex. 1010, 237:15-238:4), which is a term
`that is only used in the claims of the patent.
`
`
`
`
`
`
`-17-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`Media Player® version 6.4 and the other version of the video can be played by
`
`operating the Windows Media Player® version 7.1 or higher.”). Unsurprisingly,
`
`when confronted with the Thoen reference and its express teachings, Dr. Zeger had
`
`no response. Ex. 1010, 247:15-248:3.
`
`V. The Challenged Claims Are Unpatentable in View of Lewis and Marusi
`A. Lewis teaches “retrieving…a list of assets…wherein each asset is a
`different stream associated with the piece of content.”
`The Institution Decision correctly found that DivX misapprehended the
`
`Petition’s theory of obvious: “it does not appear that Petitioner proposes retrieving
`
`and filtering different lists of assets in the manner argued by [DivX].” ID 46.
`
`DivX has not shown any error in the Board’s correct assessment, and instead
`
`persists in mischaracterizing the positions set forth in the Petition.
`
`As explained by Dr. Reader, a POSITA would have understood that stored
`
`video files 375, such as F4F Flash video files and MPEG transport video files, are
`
`assets (media files) because MPEG transport stream video files and F4F Flash
`
`video files are well-known types of container files for digital multimedia.
`
`Ex. 1006, [0027-0029]; Pet. 62; Ex. 1003 ¶¶267-269. Stored video segments 375
`
`are associated with video segments 315a-c that exist in different formats.
`
`Ex. 1006, [0027-0029]; Pet. 61-62; Ex. 1003 ¶¶267-269. Each of these assets is a
`
`different stream because each asset is optimized for different client players
`
`supporting different platform types. Ex. 1003 ¶¶258-259; Ex. 1006, [0026-0027];
`
`
`
`
`
`
`-18-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`Pet. 58. Lewis also gives other examples of assets that are different streams, such
`
`as multiple bit-rate streams (Ex. 1006, [0030]; Pet. 15; Ex. 1003 ¶138), which is
`
`also an example given in the ’515 patent. Ex. 1001, 1:38-41.
`
`DivX mischaracterizes the Petition, contending that it “equates ‘format’ with
`
`‘stream’”, and concludes that “the Petition itself contradicts” its own allegations
`
`because the “processed video segments 315a-c are not each in a different format.”
`
`POR 32. However, the Petition does not equate “format” with “stream.”
`
`Importantly, 315b and 315c are shown to be distinct assets, and each are different
`
`streams because each has a different resolution. Ex. 1003 ¶¶267, 136-138. In
`
`Lewis’ example, 315b is “resized and cropped…to optimally fit the 960 by 640
`
`resolution provided by display 360b” (Ex. 1006, [0028]), while 315c is optimized
`
`to fit “1280 by 720 resolution” for display 360c (Ex. 1006, [0029]). Ex. 1003
`
`¶¶267, 136-138. In addition, Lewis notes that video segment 315b is optimized for
`
`client device 350b (a device that supports HTTP Live Streaming), while video
`
`segment 315c is optimized for client device 350c (a device connected to a set top
`
`box). Ex. 1006, [0028-0029]. In terms of resolution and other device-specific
`
`requirements, 315b and 315c are certainly in different formats although they may
`
`both be based on the MPEG transport stream video file standard.
`
`DivX disingenuously points to FIG. 3 to contend that “315b and 315c are
`
`expressly alleged to be the same format.” POR 29. But, eighteen pages later,
`
`
`
`
`
`
`-19-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`DivX admits that “different processed video segments 315b and 315c, hav[e]
`
`different resolutions.” POR 47. Dr. Zeger conceded that if an encoder produces
`
`streams that each use different resolutions, “that certainly could be a way of
`
`creating two different streams.” Ex. 1010, 77:11-12.
`
`Contrary to DivX’s claim that Lewis does not teach a list and that there is no
`
`reason to modify Lewis’ system (POR 30-32), the Petition and Dr. Reader clearly
`
`explain why lists and database operations would have been obvious to a POSITA.
`
`Pet. 62; Ex. 1003 ¶¶266-270, 235. As Dr. Reader explains, it would have been
`
`“obvious to retrieve a list of assets using the playback server system because Lewis
`
`teaches that…a dynamic manifest file contains a list of URLs to container files
`
`containing content.” Ex. 1003 ¶¶270, 272; Ex. 1006, [0032], [0037]; Pet. 62-63.
`
`DivX’s argument is wrong as Lewis itself explains that it was well-known that
`
`manifest files contain a list of media assets to be played. Ex. 1006, [0020]
`
`(“Manifest file 257 includes entries 258a through 258f”), and FIG. 2 (showing
`
`entries pointing to video segments).
`
`DivX contends that “no list of these processed video segments 315a-c is
`
`taught to be retrieved in Lewis” (POR 35). In fact, the Petition and Dr. Reader
`
`explained that each “asset is…stored video segments 375 associated with
`
`processed video segments 315a-c,” not just the processed video segments 315a-c.
`
`Ex. 1003 ¶¶267-268; Ex. 1006, [0027-0029], FIG. 3; Pet. 61. As Dr. Reader
`
`
`
`
`
`
`-20-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`explained, “Lewis teaches that stored video segments 375 are associated with
`
`processed video segments 315(a) to (c). There are each in different formats of the
`
`stored video segments 375. So we have a relationship” as required by the
`
`limitation. Ex. 2010, 108:4-23. Thus, it would have been obvious (as the Petition
`
`and Dr. Reader explain) to retrieve a list of assets in order to “rewrite the URLs
`
`within a manifest file to point to the content delivery network in closest proximity
`
`to the client device, providing improved network performance and responsiveness”
`
`Ex. 1006, [0032].
`
`DivX’s argument fails both for relying on this incorrect contention and Dr.
`
`Zeger’s testimony that “there is no need to retrieve a list with processed video
`
`segments 315a-c.” POR 35; Ex. 2016 ¶80. Under a correct application of
`
`obviousness jurisprudence, whether a method or step is obvious does not depend
`
`on whether it is necessary or not. Rather, it depends on what the reference teaches
`
`and what is known to a POSITA. As discussed above, Lewis teaches a list and it is
`
`known that manifest files each contain a list of assets, which is sufficient.
`
`Hence, DivX’s arguments do not overcome the Petition’s demonstration that
`
`Lewis teaches “retrieving…a list of assets associated with the identified piece of
`
`content, wherein each asset is a different stream associated with the piece of
`
`content.” Ex. 1003 ¶¶266-270; Ex. 1006, [0027-0029]; Pet. 61-62.
`
`
`
`
`
`
`-21-
`
`
`
`
`
`

`

`IPR2020-00648 (515) Reply
`
`Lewis teaches “filtering…the list of assets.”
`B.
`Regarding limitation 1[e], DivX claims that “Lewis makes clear there is no
`
`filtering of a manifest file to produce a final manifest file” because the flowchart in
`
`FIG. 4 does not mention video segments. POR 41; Ex. 2016 ¶87-88.
`
`This is incorrect for two reasons. First, even if filtering was not carried out
`
`in the example singled out by DivX, Lewis FIG. 4, that does not mean it must
`
`always be true. Second, despite FIG. 4 not mentioning stored video segments, it
`
`was known that the final, optimized manifest files contains a list of URLs. Pet. 62;
`
`Ex. 1003 ¶233. The process of optimization would involve selecting some and
`
`rejecting others, i.e., filtering asset files from a larger number of assets. It would
`
`have been obvious that these data were stored and filtered, and is further obvious in
`
`view of Marusi’s teachings of using a database to manage content in multiple
`
`representations. Ex. 1003 ¶¶273-275, 277, 149-150.
`
`As Dr. Reader explains, Lewis teaches that “additional rules may further
`
`customize the final manifest file…as shown in FIG. 3…to optimize video delivery
`
`for specific devices and display configurations.” Ex. 1003 ¶273; Ex. 1006, [0037];
`
`Pet. 63. In fact, FIG.3 confirms that stored video segments