`U.S. Patent No. 8,838,949
`
`
`
`
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`Intel Corporation
`Petitioner
`
`v.
`
`Qualcomm Incorporated
`Patent Owner
`
`
`
`IPR2018-013341
`U.S. Patent No. 8,838,949
`
`
`
`
`
`
`PETITIONER’S REPLY
`
`
`
`
`1 IPR2018-01335 and IPR2018-01336 have been consolidated with the instant
`
`proceeding.
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`
`I.
`II.
`
`TABLE OF CONTENTS
`INTRODUCTION ........................................................................................... 1
`PATENT OWNER’S PROPOSED CONSTRUCTIONS SHOULD BE
`REJECTED ...................................................................................................... 3
`A.
`“System Memory” ................................................................................. 3
`B.
`“Image Header” ..................................................................................... 6
`C.
`“Hardware Buffer” ................................................................................ 8
`D.
`“Scatter Loader Controller” ................................................................. 11
`E. Means-Plus-Function Limitations ....................................................... 13
`III. CLAIMS 1-23 ARE OBVIOUS .................................................................... 15
`A.
`Patent Owner Cannot Escape Invalidity Based On The
`Petitioner’s Use Of The Phrase “Bauer and Svensson
`Combined” ........................................................................................... 17
`Petitioner Has Established That A POSITA Would Have Been
`Motivated To Combine Bauer And Svensson ..................................... 19
`Petitioner Has Established That It Would Have Been Obvious
`To Transfer An Image In Bauer’s File Format To A System
`Memory Of A Secondary Processor Using Svensson’s Program
`Loader .................................................................................................. 21
`Bauer in Combination with Svensson Meets the “System
`Memory” Requirements ...................................................................... 31
`The Combination of Bauer And Svensson Teaches The “Scatter
`Loading” Limitations ........................................................................... 36
`The Combination Of Bauer And Svensson Alone Or With Kim
`Teaches The Secondary Processor Receiving The Image Header
`And Each Data Segment Separately .................................................... 42
`The Combination of Bauer and Svensson Teaches a “Hardware
`Buffer” ................................................................................................. 47
`The Combination of Bauer and Svensson Teaches a “Scatter
`Loader Controller” ............................................................................... 49
`Dependent Claims 2 and 12 are Obvious ............................................ 52
`I.
`IV. CONCLUSION .............................................................................................. 54
`
`
`G.
`
`H.
`
`i
`
`B.
`
`C.
`
`D.
`
`E.
`
`F.
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`
`I.
`
`INTRODUCTION
`In its Petitions, Intel Corporation (“Petitioner”) explained in detail how each
`
`challenged claim is invalid in view of Bauer in combination with Svensson (for
`
`claims 1-15 and 22-23), or alternatively, in view of the combination of Bauer and
`
`Svensson with one or more of Kim (for claims 1-23), Zhao (for claims 16 and 17),
`
`and Lim (for claims 18-21). And after considering the arguments that Qualcomm
`
`Incorporated (“Patent Owner”) advanced in its Preliminary Responses, the Board
`
`found that Petitioner had established a reasonable likelihood that the challenged
`
`claims are invalid, and instituted inter partes review on all challenged grounds.
`
`In its Response, Patent Owner just repeats many of the same arguments that
`
`it previously raised in its Preliminary Responses, and that the Board considered
`
`and rejected in its Institution Decisions. Those arguments should be rejected again
`
`here, along with Patent Owners new arguments, none of which has merit.
`
`First, for many of its arguments, Patent Owner rests on proposed claim
`
`constructions for certain terms (e.g., “system memory,” “hardware buffer,” “scatter
`
`loader controller”) that are inconsistent with the terms’ plain meanings and find no
`
`support in the intrinsic record. Patent Owner cannot avoid invalidity based on such
`
`improper attempts to re-write the claims.
`
`Second, Patent Owner argues that a POSITA would not have been motivated
`
`to combine the asserted prior art references, including Bauer and Svensson. But as
`
`1
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`explained in the Petitions, and as the Board recognized in its Institution Decisions,
`
`compelling record evidence demonstrates that such a motivation existed—
`
`including because Bauer and Svensson share the same inventors and much of the
`
`same disclosure, and Bauer explicitly references Svensson as disclosing a program
`
`loader that can read and process information contained in Bauer’s disclosed file
`
`format. Ex. 1009 at [0031].
`
`Finally, Patent Owner argues that, even if combined, the references still fail
`
`to teach certain limitations of the challenged claims. As an initial matter, however,
`
`many of those arguments hinge on the untenable proposed constructions referenced
`
`above—and should be rejected for that reason alone. Moreover, Patent Owner’s
`
`remaining arguments largely rely on attempts to restrict the prior art references in a
`
`manner that simply cannot be squared with the express disclosures of the
`
`references themselves. As Intel’s expert, Dr. Bill Lin, has confirmed, when
`
`considered from the perspective of a person of ordinary skill in the art (POSITA),
`
`the asserted prior art references teach all limitations of the challenged claims.
`
`In sum, because Patent Owner has failed to rebut Petitioner’s compelling
`
`evidence establishing that each challenged claim is invalid, the claims should be
`
`found unpatentable and cancelled.
`
`2
`
`
`
`II.
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`PATENT OWNER’S PROPOSED CONSTRUCTIONS SHOULD BE
`REJECTED
`Attempting to avoid the prior art, Patent Owner proffers constructions that
`
`effectively seek to re-write—and narrow—the scope of the challenged claims.
`
`Because none of those proposed constructions is grounded in the intrinsic record or
`
`otherwise consistent with the broadest reasonable interpretation of the terms, each
`
`should be rejected. See 37 C.F.R. § 42.100(b).2
`
`A.
`“System Memory”
`Patent Owner asserts that the term “system memory” in independent claims
`
`1, 10, 16, 18, 20, and 22 (and dependent claims 2, 4, 5, 8, and 12) should be
`
`interpreted to mean “memory that is addressable by the secondary processor.”
`
`POR at 9. Petitioner did not ask to construe this term, the Board found it
`
`unnecessary in its Institution Decisions to construe this term, 1334 DI at 8; 1335
`
`DI at 15; 1336 DI at 8, and Patent Owner itself did not seek a construction of
`
`“system memory” in the district court or ITC litigations. See Ex. 1008; Ex. 1024.
`
`Nevertheless, to the extent to Board decides to construe this term, Patent Owner’s
`
`proposed construction should be rejected for two reasons.
`
`
`2 Because the Board only applies the Phillips standard to IPR petitions filed on or
`
`after November 13, 2018, that standard does not apply here.
`
`3
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`First, Patent Owner asserts that its proposed construction reflects the plain
`
`meaning of “system memory”; yet, it tellingly fails to cite any intrinsic evidence in
`
`support of that assertion beyond generic statements in the patent referring to
`
`“system memory.” That is because Patent Owner’s construction does not reflect
`
`plain meaning; instead, Patent Owner essentially seeks to convert the requirement
`
`for “system memory” into just “memory,” such that the limitation could be met by
`
`any type of memory addressable by a processor.3 Ex. 1023 [Lin Reply Decl.] ¶11.
`
`That improper attempt to re-write the claims should be rejected. See, e.g.,
`
`Callicrate v. Wadsworth Mfg., Inc., 427 F.3d 1361, 1369 (Fed. Cir. 2005) (holding
`
`that it is improper to read out a limitation of the claims); Unique Concepts, Inc. v.
`
`Brown, 939 F.2d 1558, 1562 (Fed. Cir. 1991) (“All the limitations of a claim must
`
`be considered meaningful.”).
`
`
`3 For example, Patent Owner’s construction is so broad that it could cover non-
`
`volatile memory such as flash memory and read only memory (ROM) addressable
`
`by a processor—even though a POSITA would not have considered either to be a
`
`type of system memory. System memory is where an executable software image
`
`can be loaded and executed. This cannot be done with a non-volatile memory like
`
`a flash memory or read only memory (ROM). Ex. 1023 [Lin Reply Decl.] ¶11.
`
`4
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`Second, Patent Owner’s proposed construction fails to specify what sets a
`
`“system memory” apart from other memories—i.e., that a system memory is where
`
`an executable software image can be loaded and executed, as both parties’ experts
`
`agree. Ex. 1022 [Rinard Dep.] at 61:9-14 (“Q. Do you agree with Dr. Lin that
`
`system memory is memory where programs can be loaded and executed by a
`
`processor? A. That’s one of the things that system memory does, that you can do
`
`with system memory....”); Ex. 2001 [Lin Dep.] at 25:10-12 (testifying “a system
`
`memory would be a portion of the memory where programs could be loaded and
`
`executed”); Ex. 1023 [Lin Reply Decl.] ¶12.
`
`This is also the same meaning used in the ’949 patent, which consistently
`
`describes system memory as the memory where programs (e.g., scatter loaded data
`
`segments of an executable software image) are loaded and executed. Ex. 1001,
`
`2:61-63 (describing “loading the executable software image directly from the
`
`hardware buffer to the system memory”);4 id., 5:48-51 (“The modem Boot ROM
`
`code 126 may then jump into that modem executable image 132 and start
`
`executing the main modem program from the modem processor RAM 112 [i.e.,
`
`system memory]”); id., 8:18-21 (referring to “where the modem image executable
`
`data is to be eventually placed into the system memory of the secondary processor
`
`
`4 Emphasis added throughout unless otherwise indicated.
`
`5
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`305”); id., 9:37-41 (“[T]he executable software image is loaded into the system
`
`memory of the secondary processor ….”); id., claim 22 (requiring “scatter
`
`load[ing] each received data segment directly to a system memory of the
`
`secondary processor; and executing, at the secondary processor, the executable
`
`software image”). Indeed, the entire purpose of loading an “executable software
`
`image” to target locations in “system memory” in the ’949 patent is so that the
`
`executable software image can be executed. Ex. 1023 [Lin Reply Decl.], ¶13.
`
`Therefore, because Patent Owner has failed to identify any legitimate basis
`
`to depart from that understanding here, to the extent the Board construes the term,
`
`it should be defined to mean “memory where an executable software image can be
`
`loaded and executed.” Ex. 1023 [Lin Reply Decl.] ¶14.
`
`B.
`“Image Header”
`Patent Owner agreed in the district court and ITC litigations that “image
`
`header” means “a header associated with the entire image that specifies where the
`
`data segments are to be placed in the system memory,” and Patent Owner has
`
`adopted the same construction in this proceeding. POR at 12-13; Ex. 1008 at 10;
`
`Ex. 1024 at 25. Although Petitioner agrees that construction should apply here,
`
`1334 Pet. at 17, the Board has identified three potential issues with this agreed-
`
`upon construction.
`
`6
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`First, the Board noted that the proposed construction does not provide a
`
`separate definition for a “header.” 1334 DI at 7; 1335 DI at 7; 1336 DI at 7. But
`
`no party sought a separate construction of that term in either of the litigations (or
`
`here) because the term has a well-known plain meaning. See Ex. 1008; Ex. 1024;
`
`Ex. 1023 [Lin Reply Decl.] ¶16. Thus, whether the prior art discloses the “header”
`
`portion of the limitation is a pure factual issue.
`
`Second, the Board found that the “at least one data segment” language of the
`
`challenged claims can be met by an executable software image containing just a
`
`single data segment, but suggested the plural term “data segments” in the agreed-to
`
`construction might require multiple data segments. 1334 DI at 7; 1335 DI at 7;
`
`1336 DI at 7. Petitioner agrees that the claims can be met by a single data
`
`segment, but disagrees that the agreed-to construction requires multiple data
`
`segments. Rather, the plural term simply reflects that if a secondary processor in
`
`the claimed system receives multiple data segments, the “image header” must
`
`scatter load all of them (plural). In other words, the plural term “data segments” in
`
`the agreed-to construction refers to all data segments of an image, whether the
`
`image has one or more than one data segment. That said, if the Board believes that
`
`clarification is needed, consistent with that understanding, Petitioner would support
`
`changing “data segments” in the proposed construction to “one or more data
`
`segments.”
`
`7
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`Third, the Board stated that the agreed-to construction is unduly narrow to
`
`the extent it requires the “image header” to specify where data segments are to be
`
`placed in system memory. 1334 DI at 7; 1335 DI at 7; 1336 DI at 7. Petitioner
`
`respectfully believes that this requirement is consistent with the ’949 patent’s
`
`description of an “image header.” E.g., Ex. 1001, 8:18-21 (“The image header
`
`includes information used to identify where the modem image executable data is to
`
`be eventually placed into the system memory of the secondary processor 305.”);
`
`see 1334 Pet. at 17.
`
`Petitioner has shown how the prior art teaches an “image header” under the
`
`agreed-upon construction—i.e., a construction that specifies where data segments
`
`are to be placed in system memory. 1334 Pet. at 26-35. However, if the Board
`
`affirms its initial conclusion that “the image header is perhaps better described as
`
`having information that can be used to determine the placement of the at least one
`
`data segment in the system memory,” 1334 DI at 8; 1335 DI at 8; 1336 DI at 8, the
`
`prior art will even more clearly meet the “image header” limitation under that
`
`broader definition.
`
`C.
`“Hardware Buffer”
`Patent Owner asserts that the term “hardware buffer” (claims 1, 2, 8, and 12)
`
`should be interpreted to mean “a buffer within a hardware transport mechanism
`
`that receives data sent from the primary processor to the secondary processor.”
`
`8
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`POR at 14. Petitioner did not construe this term, the Board found it unnecessary to
`
`construe this term, 1334 DI at 8; 1335 DI at 15; 1336 DI at 8, and Patent Owner
`
`did not seek a construction of this term in the district court or ITC proceeding. See
`
`Ex. 1008; Ex. 1024. In any event, if the Board decides to construe this term, Patent
`
`Owner’s proposed construction should be rejected for two reasons.
`
`First, Patent Owner has failed to offer evidence even remotely suggesting
`
`that a POSITA would have understood the plain meaning of a “hardware buffer” to
`
`require a buffer residing in a “hardware transport mechanism.” Nor has Patent
`
`Owner identified any instance in which the intrinsic evidence purports to define a
`
`“hardware buffer” in such a specialized, non-plain meaning manner—because
`
`there is no such instance.
`
`To the contrary, the language of claim 1 merely requires the “hardware
`
`buffer” to be part of the “secondary processor”—without requiring it to exist in any
`
`specific place within that processor, and without even mentioning a “hardware
`
`transport mechanism.” Ex. 1001, claim 1 (“a secondary processor comprising … a
`
`hardware buffer”). Further, the specification only uses the term “hardware buffer”
`
`twice—(1) when repeating the language of claim 1, Ex. 1001, 2:58-61 (“a
`
`secondary processor having … a hardware buffer”), and (2) when describing how,
`
`in one embodiment, the “entire” executable software image is not stored in the
`
`hardware buffer. Ex. 1001, 9:37-41 (“In one aspect, the executable software image
`
`9
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`is loaded into the system memory of the secondary processor without an entire
`
`executable software image being stored in the hardware buffer of the secondary
`
`processor.”). As such, Patent Owner has no intrinsic support for its attempt to
`
`interpret the term “hardware buffer” as requiring a buffer residing in a “hardware
`
`transport mechanism.”
`
`Second, Patent Owner’s construction relies entirely on the fact that Figure 3
`
`of the ’949 patent shows a “Hardware Buffer” within a “Hardware Transport
`
`Mechanism.” POR at 14-15. But the specification expressly states that Figure 3 is
`
`merely “exemplary,” and Patent Owner has identified no evidence suggesting that
`
`the inventors intended to limit the “hardware buffer” of claim 1 to that single
`
`example. Ex. 1001, 7:60-63 (“In one aspect of the present disclosure, the loading
`
`process is divided into two stages, as illustrated in the exemplary flow shown in
`
`FIG. 3.”). Therefore, it would be error to restrict a “hardware buffer” to that
`
`embodiment. See Phillips v. AWH Corp., 415 F.3d 1303, 1323 (Fed. Cir. 2005)
`
`(“[A]lthough the specification often describes very specific embodiments of the
`
`invention, we have repeatedly warned against confining the claims to those
`
`embodiments.”). Moreover, the location of the buffer does not characterize the
`
`buffer itself, so it does not make sense to construe it in that manner. Ex. 1023 [Lin
`
`Reply Decl.] ¶24.
`
`10
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`As such, Patent Owner’s unjustified construction should be rejected, and the
`
`term “hardware buffer” should be given its ordinary meaning of “a buffer
`
`implemented in hardware.” Ex. 1023 [Lin Reply Decl.] ¶25.
`
`D.
`“Scatter Loader Controller”
`Patent Owner asserts that the term “scatter loader controller” (claims 1 and
`
`2) should be interpreted to mean “a component of a hardware transport mechanism
`
`that scatter loads data received from the primary processor directly into the system
`
`memory of the secondary processor.” POR at 15. Once again, Petitioner did not
`
`construe this term, the Board did not find it necessary to construe this term, 1334
`
`DI at 8; 1335 DI at 15; 1336 DI at 8, and Patent Owner did not request a
`
`construction of this term in the district court or ITC litigations. See Ex. 1008; Ex.
`
`1024.
`
`Petitioner continues to believe that no construction of this term is needed.
`
`But to the extent the Board decides to construe this term, Patent Owner’s proposed
`
`definition should be rejected for the following reasons.
`
`First, Patent Owner has offered no evidence that a POSITA would have
`
`understood that the plain meaning of a “scatter loader controller” requires a
`
`component to necessarily reside in a “hardware transport mechanism.” Nor is
`
`Petitioner aware of any such evidence. Rather, a “scatter loader controller” is
`
`11
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`simply a controller that performs scatter loading, such as “scatter load[ing] each
`
`received data segment,” as recited in claim 1. Ex. 1023 [Lin Reply Decl.] ¶28.
`
`Second, the plain language of claim 1 does not support Patent Owner’s
`
`proposed construction. The claim simply requires the “scatter loader controller” to
`
`be part of the “secondary processor,” without identifying any specific location
`
`where it must sit within the secondary processor, and without any mention of a
`
`“hardware transport mechanism.” Ex. 1001, claim 1 (“a secondary processor
`
`comprising … a scatter loader controller”). That is, the location of the scatter
`
`loader controller does not characterize the scatter loader controller itself. Ex. 1023
`
`[Lin Reply Decl.] ¶29.
`
`Third, nothing in the specification purports to define or otherwise require
`
`the claimed “scatter loader controller” to have the narrow meaning that Patent
`
`Owner proposes here (but did not propose in either litigation). See Ex. 1008; Ex.
`
`1024. And although Figure 3 shows controller 304 in a box labelled “Hardware
`
`Transport Mechanism,” it would be error to limit the claims to that single
`
`“exemplary” embodiment for the same reasons discussed above for the “hardware
`
`buffer” limitation. Phillips, 415 F.3d at 1323.
`
`Petitioner respectfully submits that it is not necessary to construe the term
`
`“scatter loader controller,” and that claim 1 sufficiently sets forth what the scatter
`
`12
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`loader controller must do—i.e., “load the image” and “scatter load each received
`
`data segment.”5 Ex. 1001, claim 1.
`
`E. Means-Plus-Function Limitations
`In the IPR2018-01335 proceeding, Petitioner proposed constructions for four
`
`means-plus-function terms recited in claim 16. 1335 Pet. at 18-22. In its
`
`Institution Decision, the Board agreed that each of these terms is a means-plus-
`
`function limitation and agreed with Petitioner’s identification of the claimed
`
`function. 1335 DI at 13.
`
`For the “means for processing …” and “means for scatter loading …”
`
`clauses, however, the Board found that the cited portions of the specification
`
`included insufficient structure to perform the claimed functions. 1335 DI at 14.
`
`
`5 Neither the parties nor the Board in its institution decisions proposed construing
`
`“scatter loader controller” as a means-plus-function term. Nor is such a
`
`construction required, because controllers, including those that perform scatter
`
`loading, are conventional computer components with known structures. Telcordia
`
`Techs., Inc. v. Cisco Sys., Inc., 612 F.3d 1365, 1376–77 (Fed.Cir.2010) (holding
`
`that “controller ” was sufficient disclosure because “[t]he record shows that an
`
`ordinary artisan would have recognized the controller as an electronic device with
`
`a known structure”).
`
`13
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`The Board encouraged the parties to address this issue, including the impact on this
`
`proceeding if the Board determines that the ’949 specification provides inadequate
`
`corresponding structure for the recited functions. 1335 DI at 14-15. Petitioner
`
`addresses these issues below.
`
`First, Patent Owner disagrees with the Board and supports Petitioner’s
`
`proposed constructions—which are the same constructions that Patent Owner
`
`proposed in the ITC proceeding. POR at 18-21; Ex. 1008 at 4-6. Upon
`
`consideration of the Board’s articulated concerns, Petitioner agrees that the ’949
`
`specification fails to disclose sufficient structure to perform the recited functions—
`
`which is the same position that Apple took for these terms in the ITC investigation.
`
`Ex. 1008 at 4-6.
`
`Second, despite these deficiencies, Petitioner agrees with Patent Owner that
`
`“[n]one of the arguments Qualcomm makes [in its Response] to distinguish the
`
`prior art requires construction of these [means-plus-function] limitations.” POR at
`
`17. Accordingly, the Board can address in this proceeding whether claim 16 is
`
`invalid in view of the asserted prior art. See Apple Inc. v. Valencell Inc., No.
`
`IPR2017-00315, Paper 45 at 47 (P.T.A.B. May 31, 2018) (“Although we agree that
`
`14
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`the proposed substitute claims are indefinite, we consider Petitioner’s arguments
`
`that the proposed substitute claims are unpatentable over the prior art.”).6
`
`III. CLAIMS 1-23 ARE OBVIOUS
`As the Board preliminarily found, Petitioner has demonstrated that the
`
`challenged claims7 are unpatentable in view of the combination of Svensson and
`
`Bauer, or alternatively, in view of the combination of Bauer and Svensson with one
`
`or more of Kim, Zhao, and Lim:
`
`(1) Svensson teaches a multi-processor system in which a program loader
`
`can transfer an executable software image from a memory of a primary processor
`
`to system memory of a secondary processor via an intermediate hardware buffer;
`
`(2) Bauer discloses an executable software image format for use with
`
`Svensson’s system that contains one or more data segments and a header portion
`
`
`6 Although Apple Inc. v. Valencell Inc. addresses proposed substitute claims, it is
`
`instructive because—like here, where the Patent Owner concedes that none of its
`
`arguments turn on the means-plus-function terms—the Board was able to apply the
`
`prior art to the (otherwise indefinite) claims.
`
`7 The Board did not reach a preliminary conclusion as to claim 16 because it of its
`
`questions about the sufficiency of the corresponding structure, as noted above.
`
`1335 DI at 13-15. See supra, §II.E.
`
`15
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`specifying where each data segment should be loaded for execution, and also
`
`teaches having a secondary processor receive the header portion separately from
`
`the data segments;
`
`(3) Kim confirms that having a processor separately receive the header
`
`and data segment portions of an executable software image was known in the prior
`
`art; and
`
`(4) Zhao and Lim confirm that conventional components such as modem
`
`processors and primary processor file systems were known. 1334 DI at 29; 1335
`
`DI at 37; 1336 DI at 31. Therefore, each challenged claim should be cancelled as
`
`obvious.
`
`
`
`In its Response, Patent Owner advances a host of arguments, none of which
`
`has merit. For example, Patent Owner argues that a POSITA would not have been
`
`motivated to combine Svensson and Bauer—even though the references share the
`
`same inventors and much of the same disclosure, and Bauer expressly states that
`
`its invention was specifically designed for use with Svensson’s system. Patent
`
`Owner also maintains that, even if combined, the prior art still fails to teach
`
`multiple limitations. But many of those arguments depend on flawed claim
`
`construction positions that fail for the reasons stated above (and under which
`
`Petitioner has established invalidity in any event). And Patent Owner’s other
`
`16
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`arguments depend on an incomplete and inaccurate reading of the asserted prior art
`
`references that simply cannot be squared with the references’ actual disclosures.
`
`Accordingly, because Patent Owner has presented no reason for the Board to
`
`depart from its preliminary conclusion that the challenged claims are obvious in
`
`view of the asserted prior art, the Board should reach the same conclusion here and
`
`find that the claims are not patentable.
`
`A.
`
`Patent Owner Cannot Escape Invalidity Based On The
`Petitioner’s Use Of The Phrase “Bauer and Svensson Combined”
`Patent Owner argues that Petitioner has failed to demonstrate invalidity
`
`because the Petitions refer to Bauer and Svensson collectively using the phrase
`
`“Bauer and Svensson combined.” POR at 35-37. But as the Board previously
`
`found, and as explained in the Petitions, that label is merely shorthand used to
`
`reflect the fact that Bauer and Svensson contain significant overlap in their
`
`disclosures. 1334 DI at 16 (Board observing that “[b]ased on the interrelatedness
`
`of the references, Petitioner refers to the teachings of ‘Bauer and Svensson
`
`combined’”); 1334 Pet. at 24-25 (explaining shorthand use of term).
`
`Moreover, despite Patent Owner’s claims to the contrary, the Petitions
`
`identify the specific disclosures that Petitioner is relying on from each reference, as
`
`well as their key respective differences, as Patent Owner elsewhere admits in its
`
`Response—i.e., that Bauer does not describe the multiprocessor system with the
`
`same level of detail as Svensson, and that Svensson does not disclose the improved
`
`17
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`file format introduced in Bauer. E.g., 1334 Pet. at 24-25 (“Bauer does not describe
`
`the multiprocessor system with the same level of detail as Svensson.”); id. at 30-31
`
`(describing the multi-processor system “as described in Svensson, using Bauer’s
`
`file format”); id. at 33 (explaining how “Bauer expressly cites to Svensson as one
`
`example of a program loader that can load data using the invention described in
`
`Bauer.”); POR at 61 (“Recognizing that ‘Bauer does not explicitly describe the
`
`loading process from the primary processor to the secondary processor in much
`
`detail’ (Paper 3 at 33), Petitioner generally relies on Svensson as disclosing how
`
`data would be loaded in the described multi-processor system.”).
`
`In addition, each time the petitions use the phrase “Bauer and Svensson
`
`combined,” the petitions cite specific disclosures from Bauer, Svensson, or Bauer
`
`and Svensson, so that Patent Owner knows exactly what Petitioner relies on as
`
`teaching each claim limitation. E.g., 1334 Petition at 25-26 (using term “Bauer
`
`and Svensson combined” for the preamble of claim 1 and citing specific
`
`disclosures from each reference); id. at 26-27 (using term “Bauer and Svensson
`
`combined” and citing specific disclosures for each reference for the “secondary
`
`processor” limitation); id. at passim.
`
`Thus, Patent Owner has identified no legitimate basis to conclude that
`
`Petitioner somehow attempted to hide its true positions, or otherwise failed to meet
`
`its disclosure obligations, with respect to the prior art.
`
`18
`
`
`
`B.
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`Petitioner Has Established That A POSITA Would Have Been
`Motivated To Combine Bauer And Svensson
`Patent Owner suggests that a POSITA would not have been motivated to
`
`combine Bauer and Svensson in the manner that Petitioner has proposed. POR at
`
`37. That argument fails for several reasons.
`
`First, Bauer and Svensson are closely interrelated; as Petitioner previously
`
`explained, the two references were filed just four months apart, and they both share
`
`the same inventors, same assignee, same figures, and much of the same disclosure.
`
`1334 Pet. at 23-25. This significant overlap alone weighs strongly in favor of
`
`finding a motivation to combine the two references. See, e.g., Plantronics, Inc. v.
`
`Aliph, Inc., 724 F.3d 1343, 1354 (Fed. Cir. 2013) (“[M]otivation to combine may
`
`be found explicitly or implicitly in … the ‘interrelated teachings of multiple
`
`patents.’”) (quoting Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324,
`
`1328-29 (Fed. Cir. 2009) (quoting KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398,
`
`418-21, (2007))).
`
`Second, Patent Owner’s lack of motivation to combine arguments are
`
`particularly untenable given that Bauer explicitly describes its file format as an
`
`improvement over Svensson’s format, and explicitly states that the new file format
`
`can be used with Svensson’s program loader and multi-processor system. 1334
`
`Pet. at 23-24; Ex. 1009, cover ¶¶27, 31-36, 43, Figs. 1A-1C, 2; Ex. 1010, cover,
`
`Fig. 1, 3:49-4:8; Ex. 1002, ¶¶102-04; DI at 15 (“Bauer expressly cites Svensson’s
`
`19
`
`
`
`IPR2018-01334
`U.S. Patent No. 8,838,949
`program loader as an example of a program loader that can use the file format
`
`disclosed in Bauer.”); POR at 37 (Patent Owner admitting “it is conceivable that
`
`the POSA would be motivated to combine Bauer and Svensson”).
`
`Indeed, it is difficult to imagine a more compelling basis to find that a
`
`motivation to combine references exists than where the references themselves
`
`suggest the combination—as is the case here. See Bayer Pharma AG v. Watson
`
`Labs., Inc., 874 F.3d 1316, 1328-29 (Fed. Cir. 2017) (finding “prior art was
`
`explicit in the suggestion to make such a combination” and that “[t]he repeated
`
`suggestion … [was] strong evidence of a motivation to make the claimed
`
`combination.”).
`
`
`
`Finally, Patent Owner’s argument is undermined by its own expert, Dr.
`
`Rinard, who testified that a person of ordinary skill in the art would have combined
`
`these two references:
`
`Q. Do you agree with me that a person of ordinary skill in the
`
`art would co