`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________________
`
`Intel Corporation,
`Petitioner,
`v.
`
`Qualcomm Incorporated,
`Patent Owner
`____________________
`Case IPR2018-013341
`U.S. Patent No. 8,838,949
`_____________________
`
`PATENT OWNER SUR-REPLY
`
`
`
`
`
`
`
`1 IPR2018-01335 and IPR2018-01336 have been consolidated with the instant
`
`proceeding.
`
`
`
`
`
`
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`
`
`
`
`
`Table of Contents
`Introduction ..................................................................................................... 1
`Claim Construction ......................................................................................... 2
`A.
`“System Memory” ................................................................................ 2
`1.
`Petitioner’s Construction is Unclear .......................................... 3
`2.
`A Construction That Defines “System Memory” Based
`on the Data That is Loaded Into the Memory is
`Erroneous and Does Not Reflect Any Characteristic of
`the Memory Itself ....................................................................... 3
`“Image Header” .................................................................................. 10
`B.
`“Hardware Buffer” ............................................................................. 11
`C.
`“Scatter Loader Controller” ............................................................... 13
`D.
`E. Means-Plus-Function Limitations ...................................................... 14
` Claims 1-23 Are Not Unpatentable .............................................................. 15
`A.
`Petitioner’s Reliance on “Bauer and Svensson Combined” is
`Inconsistent With the Proper Obviousness Inquiry Mandated by
`Graham ............................................................................................... 15
`Qualcomm Acknowledges That Bauer and Svensson Could Be
`Combined, and Petitioner’s Repeated Argument on this Point is
`a Red Herring ..................................................................................... 16
`Bauer and Svensson Combined Fail to Disclose Loading Each
`Received Data Segment Directly to System Memory of the
`Secondary Processor........................................................................... 17
`Petitioner Failed to Prove That It Would Have Been Obvious to
`Transfer an Image in Bauer’s File Format to a Secondary
`Processor ............................................................................................ 26
`Bauer and Svensson Combined Fail to Meet the “Scatter
`Loading” Limitations ......................................................................... 29
`The Cited References Fail to Disclose a Secondary Processor
`Receiving an Image Header and Each Data Segment Separately ...... 31
`Bauer and Svensson Fail to Meet the Claimed “Hardware
`Buffer” ................................................................................................ 35
`
`B.
`
`C.
`
`D.
`
`E.
`
`F.
`
`G.
`
`
`
`-ii-
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
` Conclusion .................................................................................................... 36
`
`
`
`
`
`-iii-
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`
`
`
`Introduction
`Petitioner’s reply introduces unpersuasive arguments that cannot salvage the
`
`petitions. The thrust of Petitioner’s unpatentability argument is that the intermediate
`
`storage area of Bauer/Svensson is not “system memory,” and therefore data is loaded
`
`“directly” to the DSP XRAM (i.e., the alleged “system memory”) despite the data
`
`being temporarily buffered in the intermediate storage area. See, e.g., Paper 21 at 34-
`
`35.
`
`
`
`Ex. 1010 (Svensson) at Fig. 1.
`
`
`
`But this is erroneous because the intermediate storage area of Bauer/Svensson
`
`is indistinguishable from the temporary buffer in system memory that is described
`
`in the Background section of the ‘949 patent. Ex. 1001 at 2:14-41. Both are
`
`temporary buffers that are allocated at run time and used to hold data that is
`
`subsequently transferred to a final destination in system memory:
`
`
`
`1
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`Ex. 1001 (‘949 Background) at 2:23-34: “[O]ne way of performing
`such loading is to allocate a temporary buffer …. From the temporary
`buffer, … the payload would get copied over to the final destination [in
`system memory]. The temporary buffer would be some place in system
`memory.”
`
`Ex. 1010 (Svensson) at 5:21-28: “The idle process reserves a block of
`memory in the slave’s heap of memory … [in] ‘internal’ memory 108
`(Step 212). … [T]his reserved block of memory is used for intermediate
`storage of information (code and/or data) to be transferred to the …
`‘external’ XRAM 110.”
`
`See Section III.C below. The combination of Bauer and Svensson thus describes the
`
`prior-art temporary buffering operation that the invention of the ‘949 patent seeks to
`
`avoid, and therefore does not disclose loading data segments directly to system
`
`memory, as required by all of the challenged claims.
`
`The Board should confirm the patentability of claims 1-23 for this reason and
`
`those explained below.
`
` Claim Construction
`“System Memory”
`A.
`Qualcomm showed in its response that the claim term “system memory”
`
`
`
`should be interpreted to mean “memory that is addressable by the secondary
`
`processor.” Paper 16 at 9-12. On reply, Petitioner disagrees and argues that the term
`
`should be construed as “memory where an executable software image can be loaded
`
`and executed.” Paper 21 at 6. The Board should reject Petitioner’s construction and
`
`adopt Qualcomm’s for the reasons explained below. But even if the Board were to
`
`
`
`2
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`adopt Petitioner’s erroneous construction, the cited references still fail to disclose
`
`loading data segments directly to system memory. See Section III.C below.
`
`Petitioner’s Construction is Unclear
`1.
`The language “can be” in Petitioner’s construction makes it unclear. On one
`
`
`
`hand, the construction could refer to memory that is physically capable of loading
`
`an executable software image that is then executed from the memory. But
`
`Qualcomm’s proposed construction—“memory that is addressable by the secondary
`
`processor”—already covers a memory having this capability, and Qualcomm’s
`
`construction is clearer on its face. As Petitioner’s declarant Dr. Lin acknowledged
`
`at deposition, a memory from which executable software images can be executed
`
`must be addressable by the processor. See Ex. 2008 at 26:14-22.
`
`
`
`On the other hand, Petitioner’s construction could refer to memory that is
`
`actually used for loading an executable software image that is then executed from
`
`the memory. Petitioner’s declarant Dr. Lin appears to be interpreting the
`
`construction in this manner. Id. at 27:6-16. As explained below, however, this
`
`construction is erroneous.
`
`2.
`
`A Construction That Defines “System Memory” Based on
`the Data That is Loaded Into the Memory is Erroneous and
`Does Not Reflect Any Characteristic of the Memory Itself
`A construction of “system memory” that considers whether an executable
`
`
`
`software image is actually loaded into the memory and then executed from the
`
`
`
`3
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`memory is erroneous for multiple reasons. Under this construction, a memory that
`
`loads an executable software image that is then executed from the memory would
`
`be a “system memory.” Dr. Lin testified, for instance, that the memory 305 shown
`
`in Figure 3 of the ‘949 patent would meet his construction of system memory “[i]f
`
`an executable software image is loaded into the system memory 305 and executed
`
`from the system memory 305.” Ex. 2008 at 25:24-26:4. But if the very same
`
`memory 305 was not loaded with an executable software image, then that
`
`memory 305 would not be “system memory” according to Dr. Lin:
`
`Q. [I]f an executable software image is never loaded into the system
`memory 305, does the system memory 305 meet your construction of
`the term[] system memory?
`…
`A. Well, so my definition my construction of the system memory ... is
`a memory where software images are loaded and executed. So if a
`memory is never used for that purpose, then it is not system memory.
`
`Id. at 27:6-16.
`
`
`
`This shows the error in Petitioner’s construction: It is not based on any
`
`characteristics of the “system memory” itself, and it defines the system memory
`
`solely in terms of the data loaded into it and whether a software image is executed
`
`from it. By contrast, Qualcomm’s construction defines the “system memory” based
`
`on characteristics of the memory itself.
`
`
`
`Further, if Petitioner’s construction is interpreted as requiring memory that is
`
`actually used for loading an executable software image that is then executed from
`
`
`
`4
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`the memory, then this construction is erroneous because it is contrary to the claimed
`
`invention of the ‘949 patent. The Background section of the ‘949 patent describes
`
`conventional loading processes, and the Detailed Description goes on to distinguish
`
`the claimed invention from the conventional processes. As explained below,
`
`Petitioner’s construction of “system memory” would allow the claims to encompass
`
`the very prior art whose deficiencies the ‘949 patent seeks to overcome, and it is
`
`therefore erroneous.
`
`
`
`The Background section of the ‘949 patent describes that in conventional
`
`multi-processor systems, “[w]hen software images are loaded from an external
`
`device (e.g., from another processor) onto a target device (e.g., a target processor)
`
`there may be an intermediate step where the binary multi-segmented image is
`
`transferred into the system memory and then later transferred into target locations
`
`by the boot loader.” Ex. 1001 at 2:17-41 (emphasis added). In contrast to the
`
`conventional loading processes, the invention of the ‘949 patent implements “direct
`
`scatter loading of [an] executable software image” that “avoids the use of a
`
`temporary buffer.” Id. at 4:46-47; see also id. at 5:31-35, 7:17-30, 9:42-56. The
`
`‘949 patent thus distinguishes the claimed invention from the prior-art loading
`
`techniques described in the Background section.
`
`
`
`Petitioner’s construction of “system memory,” however, would allow the
`
`claim language to encompass the very prior art whose deficiencies the ‘949 patent
`
`
`
`5
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`seeks to overcome. Such a construction cannot be correct. See SciMed Life Sys.,
`
`Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d 1337, 1342-43 (Fed. Cir. 2001).
`
`Specifically, if Petitioner’s construction is interpreted as requiring memory that is
`
`actually used for loading an executable software image that is then executed from
`
`the memory, then the construction limits the term “system memory” to only the
`
`portion of memory from which software images are executed. See id. Intermediate
`
`storage locations in memory, such as temporary buffers, would not be considered
`
`“system memory” under Petitioner’s construction because software images are not
`
`executed from them. See id.
`
`
`
`Petitioner’s construction would allow the claims to potentially cover the prior-
`
`art loading techniques that use a temporary buffer. See Ex. 1001 at 2:17-41. Under
`
`Petitioner’s construction, the temporary buffer would not be “system memory,” and
`
`thus any copying of data from the temporary buffer to a final destination in system
`
`memory would allegedly be direct and thus potentially within the scope of the
`
`claims. Petitioner’s construction is inconsistent with the main purpose of the
`
`claimed invention of the ‘949 patent, namely to “avoid[] use of a temporary buffer”
`
`and thus “avoid extra memory copy operations, thereby improving performance.”
`
`Ex. 1001 at 4:46-47, 7:27-30.
`
`
`
`By contrast, Qualcomm’s proposed construction of “system memory” is
`
`consistent with the invention described in the ‘949 patent. Paper 16 at 9-12.
`
`
`
`6
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`Petitioner nevertheless criticizes Qualcomm’s construction, arguing that it “fails to
`
`specify what sets a ‘system memory’ apart from other memories.” Paper 21 at 5.
`
`That is wrong. The ‘949 patent describes a secondary processor that includes
`
`“system memory” and a “hardware buffer,” and Qualcomm’s construction sets forth
`
`the difference between these two storage devices: The system memory is
`
`addressable by the secondary processor—e.g., the secondary processor can address
`
`the system memory in order to allocate a temporary buffer in the system memory at
`
`run time, see Ex. 1001 at 2:14-34, Ex. 2007 (Rinard Decl.) at ¶¶52-54—whereas the
`
`hardware buffer is a permanent buffer that does not require the secondary processor
`
`to address it and allocate it for use as a buffer (Ex. 2007 at ¶169). This distinction
`
`between “system memory” and the “hardware buffer” is explained further in
`
`Section III.C below.
`
`
`
`Petitioner disagrees and asserts that the hardware buffer is addressable by the
`
`secondary processor in the ‘949 patent. Paper 21 at 32-33. Petitioner’s argument is
`
`based on the notion that the scatter loader controller is a component of the hardware
`
`buffer (id.), but there is simply nothing in the ‘949 patent indicating that the scatter
`
`loader controller is part of the hardware buffer. See Ex. 2008 (Lin Depo. Transcript)
`
`at 32:23-37:4. Petitioner suggests that Figure 3 of the ‘949 patent shows the scatter
`
`loader controller 304 as being a component of the hardware buffer, but that
`
`misinterprets the disclosure of the drawing. The ‘949 patent states that “[s]econdary
`
`
`
`7
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`processor 302 includes a hardware transport mechanism 309 (e.g., a USB
`
`controller) that includes a scatter loader controller 304” (Ex. 1001 at 8:60-62
`
`(emphasis added)), and that is what is shown in Figure 3:
`
`
`
`Id. at Fig. 3. As seen above, the scatter loader controller 304 is a component of the
`
`hardware transport mechanism 309. Petitioner’s expert Dr. Lin conceded this:
`
`Q. Do you agree that in the embodiment of Figure 3 of the ‘949 patent,
`the scatter loader controller 304 is a component of the hardware
`transport mechanism 309?
`
`A. Yes.
`
`
`
`8
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`
`
`Ex. 2008 at 32:18-22. The box labeled 309 represents a hardware transport
`
`mechanism, not a hardware buffer.
`
`
`
`Petitioner also criticizes Qualcomm’s construction of “system memory” for
`
`allegedly being overbroad, arguing that that “it could cover non-volatile memory
`
`such as flash memory” even though loading and execution of an executable software
`
`image allegedly “cannot be done with a non-volatile memory like a flash memory.”
`
`Paper 21 at 4 n.3. Petitioner’s argument is technically wrong. There is nothing that
`
`would prevent non-volatile memory from being used to load and execute executable
`
`software images, and Petitioner does not attempt to explain why non-volatile
`
`memory allegedly could not be used in this manner. In fact, at deposition,
`
`Petitioner’s declarant Dr. Lin could provide only a single difference between volatile
`
`and non-volatile memory—i.e., non-volatile memory’s ability to retain data when
`
`power is lost, see Ex. 2008 at 37:21-38:18—and this difference would not prevent
`
`non-volatile memory from being used to load and execute software images in the
`
`same way that volatile memory is used.
`
`
`
`The Board should adopt Qualcomm’s construction of “system memory” and
`
`reject Petitioner’s construction for at least these reasons. But even if the Board were
`
`to adopt Petitioner’s erroneous construction, the cited references still fail to disclose
`
`
`
`9
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`loading data segments directly to system memory, as explained in Section III.C
`
`below.
`
`“Image Header”
`B.
`In its response, Qualcomm agreed with Petitioner that the term “image header”
`
`should be construed as “a header associated with the entire image that specifies
`
`where the data segments are to be placed in the system memory.” Paper 16 at 12-
`
`14. Qualcomm also responded to the three potential issues identified by the Board
`
`for this construction. Id.
`
`In its reply, Petitioner argues again that its proposed construction should be
`
`applied and responds to the three issues raised by the Board. Paper 21 at 6-8. For
`
`one of these issues—the fact that the agreed-upon construction recites the plural term
`
`“data segments,” whereas the claim elsewhere recites “at least one data segment”—
`
`Petitioner states that it now “agrees [with the Board] that the claims can be met by a
`
`single data segment.” Id. at 7.
`
`Qualcomm disagrees that the claims can be met by a single data segment.
`
`Independent claims 1, 10, 16, 18, 20, and 22 of the ’949 patent all require scatter
`
`loading each received data segment. As Qualcomm’s expert Dr. Rinard previously
`
`testified, “scatter loading requires at least two data segments (otherwise there is no
`
`scattering of the data segments),” and thus “the claims can be met only by at least
`
`two data segments.” Ex. 2007 at ¶63. Moreover, Petitioner’s declarant Dr. Lin has
`
`
`
`10
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`conceded that scatter loading involves loading to multiple “locations,” which
`
`confirms that scatter loading requires at least two data segments. Ex. 2008 at 40:6-
`
`12.
`
`“Hardware Buffer”
`C.
`Qualcomm showed in its response that the claim term “hardware buffer”
`
`
`
`should be interpreted to mean “a buffer within a hardware transport mechanism that
`
`receives data sent from the primary processor to the secondary processor.” Paper 16
`
`at 14-15. In its reply, Petitioner disagrees and argues that the term should be
`
`construed as “a buffer implemented in hardware.” Paper 21 at 8-11. But a buffer
`
`cannot exist absent some piece of hardware, such that all buffers must ultimately be
`
`“implemented in hardware.” Petitioner’s declarant Dr. Lin acknowledged this at
`
`deposition:
`
`Q. Dr. Lin, is it possible to implement a buffer without some type of
`physical storage medium?
`
`A. No.
`
`Ex. 2008 at 41:9-12; see also id. at 43:3-5. Petitioner’s construction thus reads the
`
`term “hardware” out of the claim and gives no meaning to this language because all
`
`buffers are ultimately “implemented in hardware.”
`
`
`
`Further, Petitioner’s construction is erroneous because it is overly broad and
`
`would allow the claims to potentially cover the prior-art loading techniques that the
`
`
`
`11
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`‘949 patent disparages. As explained above, the Background section of the ‘949
`
`patent describes conventional loading processes in which “the data being
`
`downloaded from a primary processor to a secondary processor is copied into [an]
`
`intermediate buffer” in system memory and then later transferred into its final
`
`destination in the system memory. Id. at 2:35-41. The invention of the ‘949 patent,
`
`by contrast, implements “direct scatter loading of [an] executable software image”
`
`that “avoids the use of a temporary buffer.” Id. at 4:46-47; see also id. at 9:42-56.
`
`The ‘949 patent thus distinguishes the claimed invention from the prior-art
`
`techniques that use a temporary buffer in system memory.
`
`
`
`Petitioner’s proposed construction of “hardware buffer” would impermissibly
`
`expand the claims to encompass prior art embodiments plainly disclosed and
`
`distinguished in the ‘949 patent. Under Petitioner’s overly broad construction, any
`
`“buffer implemented in hardware”—even temporary buffers in system memory, as
`
`discussed in the prior-art solutions of the patent’s Background section—would read
`
`on the claimed “hardware buffer.” Petitioner’s declarant Dr. Lin acknowledged this:
`
`Q. Column 2, Lines 31 through 34 of the ‘949 patent state that “The
`temporary buffer would be someplace in the system memory such as in
`internal random access memory (RAM) or double data rate (DDR)
`memory, for example.” Do you see that?
`
`A. Yes.... I can agree that if a temporary buffer is implemented using
`random access memory, that it is in hardware.... [I]f the temporary
`buffer is implemented [in] double data rate memory I can agree that it
`is implemented in hardware.
`
`
`
`12
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`
`
`Ex. 2008 at 17:4-20:18. Petitioner’s construction would thus allow the claims to
`
`potentially cover the prior-art loading techniques that the ‘949 patent disparages.
`
`See Ex. 1001 at 2:17-41. Petitioner’s construction is erroneous for this additional
`
`reason.
`
`
`
`However, to the extent the Board determines that Qualcomm’s proposed
`
`construction of “hardware buffer” is too narrow, Qualcomm alternatively proposes
`
`that the term be construed as “a buffer that is not allocated by the secondary
`
`processor.” In the ‘949 patent, the hardware buffer is a permanent buffer within the
`
`hardware transport mechanism (Ex. 1001 at 2:58-61, 8:24-30, Fig. 3; Ex. 2007
`
`at ¶¶69-71), in contrast to a temporary buffer in system memory that is allocated by
`
`the secondary processor at run time for this purpose (Ex. 1001 at 2:14-34; Ex. 2007
`
`at ¶¶52-53). Qualcomm’s alternative construction of “hardware buffer” captures this
`
`distinction between the system memory and the hardware buffer, whereas
`
`Petitioner’s overly broad construction does not.
`
`“Scatter Loader Controller”
`D.
`Qualcomm showed in its response that the claim term “scatter loader
`
`
`
`controller” 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.” Paper 16 at 15-16; Ex. 2007 at
`
`
`
`13
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`¶¶72-75. On reply, Petitioner disagrees and argues that the specification and claim
`
`language do not require the scatter loader controller to be a component of a hardware
`
`transport mechanism. Id.
`
`But the specification never states or suggests that the scatter loader controller
`
`could be a component outside of the hardware transport mechanism. To the contrary,
`
`the ‘949 Patent contains express disclosure indicating that the scatter loader
`
`controller is a component of a hardware transport mechanism. See, e.g., Ex. 1001
`
`at 8:60-62; Fig. 3. Disclosure such as this provides a strong indicator of the proper
`
`claim scope. See, e.g., In re NTP, Inc., 654 F.3d 1279, 1288 (Fed. Cir. 2011). In
`
`fact, the specification only describes a scatter loader controller that is a component
`
`of a hardware transport mechanism—and, importantly, does not describe a scatter
`
`loader controller that exists independently of a hardware transport mechanism.
`
`E. Means-Plus-Function Limitations
`In the IPR2018-01335 petition, Petitioner proposed constructions for the four
`
`means-plus-function terms recited in claim 16. Paper 2 (IPR2018-01335) at 18-22.
`
`In its response, Qualcomm identified the claimed functions and corresponding
`
`structures in the specification of the ‘949 patent for each of the respective means-
`
`plus-function limitations. Paper 16 at 17-21.
`
`On reply, Petitioner changes its position and states that it now agrees with the
`
`Board that “the ‘949 specification fails to disclose sufficient structure to perform the
`
`
`
`14
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`recited functions.” Paper 21 at 14. Qualcomm disagrees (Paper 21 at 17-21), but
`
`should the Board maintain its position that the specification does not disclose
`
`corresponding structure for the claimed functions, then this precludes the Board from
`
`finding that claim 16 is unpatentable. See, e.g., Nikon Corp. v. ASML Netherlands
`
`B.V., IPR2018-00220, Paper No. 8 at 16-17 (PTAB June 4, 2018).
`
`Petitioner argues that the Board should “address in this proceeding whether
`
`claim 16 is invalid in view of the asserted art” (Paper 21 at 14), but under clear Board
`
`precedent, when a petitioner in an IPR is unable to establish that a challenged claim
`
`satisfies the § 112 definiteness requirement, then the petitioner cannot meet its
`
`burden to show unpatentability under § 102 or § 103. Petitioner cites the Apple Inc.
`
`v. Valencell Inc. case as supporting its position that the Board can invalidate an
`
`allegedly indefinite claim (Paper 21 at 14-15), but that case is distinguishable
`
`because the Board was addressing proposed substitute claims and not original patent
`
`claims. IPR2017-00315, Paper 45 at 40-51 (PTAB May 31, 2018).
`
` Claims 1-23 Are Not Unpatentable
`Petitioner’s Reliance on “Bauer and Svensson Combined” is
`A.
`Inconsistent With the Proper Obviousness Inquiry Mandated by
`Graham
`Qualcomm’s response showed that Petitioner’s reliance on “Bauer and
`
`Svensson combined” is inconsistent with the proper obviousness inquiry mandated
`
`by Graham v. John Deere Co., 383 U.S. 1 (1966). Paper 16 at 35-37.
`
`
`
`15
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`In its reply, Petitioner argues that “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.” Paper 21 at 18. But even if
`
`the petitions cite specific portions of Bauer and Svensson, it is improper for
`
`Petitioner to place the burden upon Qualcomm and the Board to parse through the
`
`petitions’ citations and piece together Petitioner’s unstated unpatentability theory.
`
`See, e.g., Vista Outdoor Operations LLC v. Liberty Ammunition, LLC, IPR2016-
`
`00539, Paper 9 at 15 (PTAB Aug. 3, 2016).
`
`B. Qualcomm Acknowledges That Bauer and Svensson Could Be
`Combined, and Petitioner’s Repeated Argument on this Point is a
`Red Herring
`Petitioner argues repeatedly throughout its reply (Paper 1-2, 16-17, 19-20)
`
`that Qualcomm is taking the unreasonable position “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.” Id. at 16. But this argument
`
`is a red herring because Qualcomm never took that position. Rather, Qualcomm
`
`explicitly acknowledged that “it is conceivable that the POSA would be motivated
`
`to combine Bauer and Svensson.” Paper 16 at 37; see also Ex. 2007 (Rinard Decl.)
`
`at ¶¶106-07. Accordingly, Petitioner’s repeated criticisms have no validity.
`
`
`
`16
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`C. Bauer and Svensson Combined Fail to Disclose Loading Each
`Received Data Segment Directly to System Memory of the
`Secondary Processor
`In its response (Paper 16 at 50-58), Qualcomm showed that the cited
`
`references fail to disclose loading each received data segment directly to a system
`
`memory of the secondary processor, as required by all of the challenged claims. As
`
`Qualcomm explained (id.), in the combination of Bauer and Svensson, the system
`
`memory consists of the DSP SARAM & DARAM—including the portion thereof
`
`allocated as an intermediate storage area—and the DSP XRAM:
`
`Ex. 1009 at Fig. 2 (annotations added). Therefore, the copying of data from the
`
`intermediate storage area to the DSP XRAM in Bauer/Svensson does not disclose
`
`loading segments directly to system memory but instead describes the prior-art
`
`
`
`
`
`17
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`intermediate buffering operation that the ‘949 invention seeks to avoid. Paper 16
`
`at 50-58.
`
`On reply, Petitioner attempts to distinguish the intermediate storage area of
`
`Bauer/Svensson from the system memory of the ‘949 patent. Paper 21 at 34-35.
`
`Petitioner argues that the intermediate storage area of Bauer/Svensson is “reserved
`
`for only temporarily storing information to be transferred to the actual system
`
`memory (DSP XRAM 110)” and never used for loading and executing images like
`
`the system memory of the ‘949 patent. Id. But the intermediate storage area of
`
`Bauer/Svensson is not permanently “reserved” in the manner suggested by Petitioner.
`
`Rather, the intermediate storage area is allocated at run time in the exact same
`
`manner as the temporary buffer in system memory described in the ‘949 patent
`
`Background section.
`
`Specifically, the Background section of the ‘949 patent describes a prior-art
`
`loading process in a multi-processor system. Ex. 1001 at 2:14-41. In the prior-art
`
`loading process, a temporary buffer is (i) allocated in system memory at run time,
`
`and (ii) used to hold data that is subsequently transferred to a final destination in the
`
`system memory:
`
`In a system in [w]hich the software image is loaded onto a target
`“secondary” processor from a first “primary” processor, one way of
`performing such loading is to allocate a temporary buffer into which
`each packet is received …. From the temporary buffer, some of the
`processing may be done over the payload, and then the payload would
`
`
`
`18
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`get copied over to the final destination. The temporary buffer would be
`some place in system memory, such as in internal random-access-
`memory (RAM) or double data rate (DDR) memory, for example.
`
`Id. at 2:23-34 (emphasis added); see also id. at 2:14-22, 2:35-41.
`
`
`
`The combination of Bauer and Svensson discloses the same prior-art loading
`
`process. Specifically, Svensson describes that “[w]hen code needs to be loaded to
`
`the XRAM 110 during boot,” a “bootloader, the OS, and any necessary start-up code
`
`for the OS” is pushed from the host (ARM) processor to the DSP SARAM &
`
`DARAM 108 of the slave (DSP) processor. Ex. 1010 at 4:9-31. When this push is
`
`complete, the slave processor is booted (step 208 of Svensson Figure 2), and the
`
`operating system is started in the slave processor (step 210). Id. at 4:31-5:20. In
`
`starting the operating system, a “system idle process is created” and executed by the
`
`slave processor. See id. (“At this point, the slave 104 is partly up and running. The
`
`slave part of the OS-friendly bootloader has been loaded, and the slave’s idle process
`
`is executing…. OS mechanisms for which all code and data accesses are in memory
`
`that has already been loaded (SARAM and DARAM 108, in this example) are
`
`available….”).
`
`
`
`The idle process reserves (i.e., allocates) a block of memory from the “heap”
`
`of the DSP SARAM & DARAM 108 at run time, and that block is used as a
`
`temporary buffer to hold data that is subsequently transferred into the DSP
`
`XRAM 110:
`
`
`
`19
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`The idle process reserves a block of memory in the slave’s heap of
`memory that is located in the memory visible to the host, such as
`“internal” memory 108 (Step 212). … [T]his reserved block of memory
`is used for intermediate storage of information (code and/or data) to be
`transferred to the slave-private memory, i.e., the memory that is
`invisible to the host, such as “external” XRAM 110.
`
`Id. at 5:21-28 (emphasis added). The “heap” is a well-known term that refers to
`
`memory that is dynamically allocated at program run time for various purposes, such
`
`as
`
`temporary buffering of data.
`
` See, e.g., https://en.wikipedia.org/wiki/
`
`Memory_management (“Dynamic memory allocation – The task of fulfilling an
`
`allocation request consists of locating a block of unused memory of sufficient size.
`
`Memory requests are satisfied by allocating portions from a large pool of memory
`
`called the heap or free store.”) (emphasis in original). Thus, the intermediate storage
`
`area of Bauer/Svensson is a temporary buffer in system memory that is allocated at
`
`run time and not a permanent, fixed memory.
`
`
`
`The steps for loading data to the DSP XRAM 110 during boot—including
`
`booting the slave processor (step 208), starting the OS in the slave processor
`
`(step 210), and allocating the intermediate storage area in the DSP SARAM &
`
`DARAM 108 at run time (step 212) are shown in Figure 2 of Svensson:
`
`
`
`20
`
`

`

`IPR2018-01334
`U.S. Patent 8,838,949
`
`
`
`Ex. 1010 at Fig. 2 (annotations added).
`
`
`
`
`
`Further, after the slave processor allocates the intermediate storage area, the
`
`slave processor sends a message to the host processor with “information about the
`
`address a