`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`Intel Corporation
`Petitioner
`
`v.
`
`Qualcomm Incorporated
`Patent Owner
`______________________
`
`Case IPR2018-013341
`Patent 8,838,949
`______________________
`
`REMAND DECLARATION OF DR. MARTIN RINARD
`
`I, Martin Rinard, do hereby declare:
`
`1.
`
`I am making this declaration at the request of Qualcomm Incorporated
`
`(“Qualcomm” or “Patent Owner”) in the matter of the Inter Partes Review of U.S.
`
`Patent No. 8,838,949 (“the ’949 patent”). I previously prepared and submitted my
`
`Declaration in support of Qualcomm’s Patent Owner Response (Ex. 2007). I submit
`
`this Declaration in support of Qualcomm’s Response Brief on Remand.
`
`1 IPR2018-01335 and IPR2018-01336 have been consolidated with the instant
`proceeding. All citations are to IPR2018-01334 unless otherwise noted.
`
`1
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`2.
`
`Since preparing my Declaration in support of Qualcomm’s Patent
`
`Owner Response, I have also reviewed the following materials:
`
`a. Qualcomm’s Sur-Reply (Paper 25);
`b. Final Written Decision (Paper 30);
`c. Federal Circuit Opinion (Intel Corp. v. Qualcomm Inc., 21 F.4th 801
`(Fed. Cir. 2021) (the “Opinion”));
`d. Intel’s Opening Brief on Remand (Paper 35);
`e. Remand Declaration of Bill Lin, Ph.D. (Ex. 1026);
`f. Lin Deposition Transcript (May 5, 2022) (Ex. 2010);
`g. Oxford University Press, “A Dictionary of Computing” (6th ed.)
`(Ex. 2011);
`h. “Computer Architecture—A Quantitative Approach (5th Edition)”
`by John L. Hennessy and David A. Patterson (Ex. 2012);
`i. “Computer Architecture—A Quantitative Approach (4th Edition)”
`by John L. Hennessy and David A. Patterson (Ex. 2014);
`j. “FIFO Architecture, Functions, and Applications”
`Instruments, 1999) (Ex. 2013); and
`k. Any other materials referenced herein.
`
`(Texas
`
`3.
`
`I am being compensated for my work in this matter at my standard
`
`hourly rate of $975 for consulting services. My compensation in no way depends
`
`on the outcome of this proceeding.
`
`I.
`
`PROFESSIONAL BACKGROUND
`4.
`I described my qualifications in my Declaration in support of
`
`Qualcomm’s Patent Owner Response. Ex. 2007 at ¶4-17.
`
`
`
`2
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`II. RELEVANT LEGAL STANDARDS
`5.
`In my Declaration in support of Qualcomm’s Patent Owner Response,
`
`I set forth the applicable principles of patent law that were provided to me by
`
`counsel. Ex. 2007 at ¶18-24. As appropriate, I have continued to apply those
`
`principles in providing my opinions in this Declaration.
`
`III. BACKGROUND ON BUFFERS
`6.
`Computer systems often need to transfer data (such as instructions that
`
`comprise software) between devices and/or components. A common problem that
`
`arises in this context is matching the timing at which the sender sends the data with
`
`the timing at which the receiver receives the data. A common solution to this
`
`problem is to insert a buffer between the sender and the receiver. In this context a
`
`buffer accumulates and stores transferred data, typically for a short period of time,
`
`until the receiver retrieves the data. For efficiency reasons, it is often important that
`
`the buffer support fast retrieval by the receiver. Oxford University Press’s “A
`
`Dictionary of Computing,” Sixth Edition (2008), defines “buffer” as follows:
`
`
`
`3
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`
`
`Ex. 2012 at 58.
`
`7.
`
`Buffers that support the transfer of data are ubiquitous in computing
`
`generally and can appear in a wide variety of contexts, implemented in a wide variety
`
`of storage technologies, with the specific characteristics of the buffer specialized as
`
`appropriate for the context in which they appear.
`
`8.
`
`There is an important conceptual difference between buffers that store
`
`data for short periods of time as it is transferred between components or devices, and
`
`memories that store data for longer periods of time (or even indefinitely) for future
`
`access, often as the primary storage mechanism for data over the lifetime of a
`
`
`
`4
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`program or computer system. Examples of such memories include the main or
`
`system memory of the computer, often implemented in DRAM (storing data during
`
`the execution of a program), disks (storing data for a computer attached to the disk),
`
`or tape (storing archived data indefinitely).
`
`Examples of Buffers in Modern Computer Systems
`
`9.
`
`In modern computers, the DRAM memory access time is too slow to
`
`keep up with processor memory reads and writes. See, e.g., Ex. 2012, “Computer
`
`Architecture—A Quantitative Approach (5th Edition)” by John L. Hennessy and
`
`David A. Patterson (hereinafter “Hennessy/Patterson 5”) at Figure 2.2, page 73 and
`
`Ex. 2014, “Computer Architecture—A Quantitative Approach (4th Edition)” by John
`
`L. Hennessy and David A. Patterson (hereinafter “Hennessy/Patterson 4”) at Figure
`
`5.2, page 289. This fact motivates the development of caches – smaller, faster
`
`memories designed to hold accessed memory locations. See Hennessy/Patterson 5
`
`at Figure 2.1, page 72 and Hennessy/Patterson 4 at Figure 5.1, page 288. Instead of
`
`inefficiently accessing data from DRAM memory, the processor accesses data from
`
`faster caches, with data transferred between the DRAM memory and caches as
`
`required to satisfy the processor’s memory access requests. A goal is to improve the
`
`overall efficiency and performance of the system by storing frequently accessed data
`
`in the cache.
`
`
`
`5
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`10. With cache architectures there is a need to write modified data back
`
`from the cache into main memory. In this context a write buffer stores the data as it
`
`is transferred from the cache into the DRAM main memory. See Hennessy/Patterson
`
`5 at 75 and Hennessy/Patterson 4 at 289. Because the write buffer is faster than main
`
`memory, it improves the overall efficiency of the system by enabling the cache (and
`
`therefore the processor as it accesses the cache) to proceed without waiting for “the
`
`full latency to write the data into memory.” See, e.g., Hennessy/Patterson 5 at 74-
`
`75 and Hennessy/Patterson 4 at 289: “A write-through cache updates the item in the
`
`cache and writes through to update main memory. A write-back cache only updates
`
`the copy in the cache. When the block is about to be replaced, it is copied back to
`
`memory. Both write strategies can use a write buffer to allow the cache to proceed
`
`as soon as the data are placed in the buffer rather than wait the full latency to write
`
`the data into memory.” (emphasis in original).
`
`11. Memory access time can also cause an efficiency problem when
`
`reading instructions for the processor to execute. Here again fast buffers can play a
`
`role in improving overall system efficiency. See, e.g., Hennessy/Patterson 5 at 91
`
`and Hennessy/Patterson 4 at 305: “Another approach is to prefetch items before the
`
`processor requests them. Both instructions and data can be prefetched, either directly
`
`into the cache or into an external buffer that can be more quickly accessed than main
`
`memory.”
`
`
`
`6
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`12. Both write buffers and external buffers that hold prefetched instructions
`
`can be faster than main memory because they serve only a single purpose in the
`
`system. They can (and in practice typically are) therefore directly implemented as
`
`small, permanent hardware components dedicated to a single purpose in the system
`
`– write buffers only hold data as it is transferred from the cache to slower main
`
`memory; external instruction buffers only hold instructions as they are transferred
`
`from slower main memory to the processor for execution.
`
`13.
`
`It can also be appropriate for buffers to be stored in main memory. A
`
`prominent example is buffers used to hold data for input or output.
`
`14.
`
`In this context the overhead of copying data between buffers located in
`
`main memory is a known issue that can degrade the performance of the system. See,
`
`e.g., “One problem you may encounter in performing I/O is that systems often
`
`perform extra memory copies; for example, when the read() system call is invoked,
`
`data may first be read from disk into a system buffer and the subsequently copied
`
`into the specified user buffer. Hence, memory bandwidth during I/O can be an
`
`issue.” Hennessy/Patterson 5 at D-65.
`
`15. While buffers implemented as permanent hardware components can
`
`deliver important efficiency benefits, they have the drawback that they are
`
`implemented directly into the hardware architecture and can therefore serve only the
`
`specific purpose for which they were designed. While buffers implemented in
`
`
`
`7
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`memory are typically slower, they can be more flexibly managed. See, e.g.,
`
`“A FIFO is a special type of buffer. The name FIFO stands for first in first out and
`
`means that the data written into the buffer comes out of it first. There are other kinds
`
`of buffers like the LIFO (last in first out), often called a stack memory, and the shared
`
`memory. The choice of buffer architecture depends in the application to be solved.
`
`FIFOs can be implemented with software or hardware. The choice between a
`
`software and a hardware solution depends on the application and the features
`
`desired. When requirements change, a software FIFO easily can be adapted to them
`
`by modifying its program, while a hardware FIFO may demand a new board layout.
`
`Software is more flexible than hardware. The advantage of hardware FIFOs shows
`
`in their speed.” Ex. 2013, “FIFO Architecture, Functions, and Applications” (Texas
`
`Instruments, 1999) at 1.
`
`IV. CLAIM CONSTRUCTION—“HARDWARE BUFFER”
`16. Claims 1-9 and 12 of the ’949 patent all require a “hardware buffer.” I
`
`previously submitted a declaration putting forth the opinion that this term should be
`
`interpreted to mean “a buffer within a hardware transport mechanism that receives
`
`data sent from the primary processor to the secondary processor.” Ex. 2007 at ¶¶69-
`
`71. I understand that the Patent Trial and Appeal Board (PTAB) did not adopt this
`
`construction but instead concluded that the claim term “hardware buffer” “should
`
`
`
`8
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`not be read so broadly as to encompass” the use of a temporary buffer. Final Written
`
`Decision at 17.
`
`17.
`
`I understand that the Final Written Decision of the PTAB was appealed
`
`to the Federal Circuit, which vacated the decision and remanded back to the PTAB
`
`for further proceedings. I understand that the Federal Circuit reviewed the claim
`
`construction for the claim term “hardware buffer” de novo and determined that
`
`“What is needed in this case is a more substance-focused analysis than is yet
`
`present.” Opinion at 811.
`
`18. Claim 1 of the ’949 patent claims “system memory and a hardware
`
`buffer for receiving an image header and at least one data segment of an executable
`
`software image” as well as “to scatter load each received data segment based at least
`
`in part on the loaded image header, directly from the hardware buffer to the system
`
`memory.”
`
`19. Claim 2 of the ’949 patent further claims “to load the executable
`
`software image directly from the hardware buffer to the system memory of the
`
`secondary processor without copying data between system memory locations on the
`
`secondary processor.”
`
`20. Claim 12 of the ’949 patent claims “loading the software image directly
`
`from the hardware buffer to the system memory of the secondary processor without
`
`copying data between system memory locations.”
`
`
`
`9
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`21. These portions of the claims recite a flow of data in which software
`
`image data flows through the hardware buffer to the system memory, and
`
`specifically directly to the system memory without copying data between system
`
`memory locations on the secondary processor. An example of these limitations is
`
`shown in Figure 3 of the ‘949 patent, which provides a “hardware buffer” as part of
`
`a “Hardware Transport Mechanism (i.e., USB controller).” In Figure 3, image
`
`segments flow over “Physical Data Pipe (i.e. HS-USB Cable)” 310 through the
`
`claimed “hardware buffer” directly to their final locations in system memory 305.
`
`In this disclosure, the claimed “hardware buffer” is a permanent buffer, similar to
`
`the write buffers and external instruction buffers discussed above, in that it is
`
`designed to support a single purpose in the system, specifically efficient transfer of
`
`data between system components.
`
`22.
`
`It is my opinion that the term “hardware buffer” should be construed as
`
`“a permanent, dedicated buffer that is distinct from system memory” for these
`
`reasons and those below.
`
`A. The Background Section Of The ’949 Patent Describes
`Conventional Loading Processes That Use Temporary
`Buffers In System Memory
`23. The Background section of the ’949 patent describes prior-art systems
`
`in which a software image is loaded onto a target, secondary processor from a
`
`primary processor using “an intermediate step where the binary multi-segmented
`
`
`
`10
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`image is transferred into the system memory and then later transferred into target
`
`locations by the boot loader.” ’949 patent at 2:17-22. This loading is performed by
`
`“allocat[ing] a temporary buffer into which each packet is received.” Id. at 2:25-26.
`
`The temporary buffer (also referred to as an “intermediate buffer,” see id. at 2:35-
`
`54) is “some place in system memory, such as in internal random-access-memory
`
`(RAM) or double data rate (DDR) memory, for example.” Id. at 2:31-34.
`
`24. The ’949 patent states that the prior-art use of system memory for
`
`buffering is inefficient because it requires “extra memory copy operations.” Id.
`
`at 7:16-30. The conventional approaches described in the Background section of the
`
`’949 patent involve the intermediate step of copying image data from the temporary
`
`buffer—which is formed in one portion of system memory, see id. at 2:31-34—to
`
`its final location in system memory. Id. at 2:17-22, 2:29-31, 2:35-41, 7:20-26. The
`
`’949 patent states that the extra memory copy operations in system memory result
`
`in reduced efficiency and increased time required to boot a secondary processor in a
`
`multi-processor system. Id. at 7:27-30.
`
`25. The prior-art systems’ use of system memory is also inefficient because
`
`it is general-purpose memory that is not specifically configured for the task of
`
`buffering data in a multi-processor system. System memory, as used in the ‘949
`
`patent (as well as broadly throughout the field of computing) refers to the general
`
`working memory of a processor, used, for example, to store data and code that the
`
`
`
`11
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`processor can read and write as it operates. As such, the running processor allocates
`
`different regions of system memory, under software control, to the different data and
`
`code storage tasks required to execute the software. The temporary buffer described
`
`in the Background section of the ’949 patent is an example of a buffer that is
`
`allocated by software in system memory. See ’949 patent at 2:23-28. This buffer is
`
`“temporary” because it only exists conceptually after it is allocated by the software.
`
`The hardware does not configure or distinguish the different regions allocated in
`
`system memory.
`
`26. Different software running on the processor can apply different
`
`configurations to the system memory, and the system memory is therefore capable
`
`of supporting a wide variety of different access patterns. The ability to support
`
`different access patterns provides flexibility, but the flexibility comes at the cost of
`
`speed and efficiency. See Section III above. Because system memory (including
`
`the system memory allocated for use as temporary buffers in the prior-art
`
`approaches, see ’949 patent at 2:23-34) is able to support a wide range of software
`
`memory access patterns, using system memory for buffering data transfers is less
`
`efficient than using dedicated hardware components for this purpose. Such hardware
`
`components are designed to serve only a single more specialized purpose,
`
`specifically transferring data within or between devices. See Section III above. The
`
`hardware buffer of the ’949 patent is an example of a dedicated hardware
`
`
`
`12
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`component, distinct from system memory, that provides “improv[ed] performance”
`
`over the conventional approaches, as explained below. ’949 patent at 7:27-30.
`
`B.
`
`The ’949 Invention’s Use Of A Dedicated, Permanent
`Hardware Buffer Improves Upon The Conventional
`Approaches And Enables More Efficient Loading
`27. The invention of the ’949 patent uses a hardware buffer to provide “a
`
`direct scatter load technique” that eliminates “the intermediate step of buffering
`
`required in traditional loading processes,” to achieve increased efficiency. ’949
`
`patent at 4:43-47, 7:20-26. The ’949 patent refers to the direct scatter load technique
`
`as a “Zero Copy Transport Flow.” Id. at 7:16. An example of the Zero Copy
`
`Transport Flow is illustrated in Figure 3:
`
`
`
`13
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`
`
`28.
`
`In the Zero Copy Transport Flow shown above, data segments “are sent
`
`from system memory 307 to the primary hardware transport mechanism 308,” and
`
`the “segments are then sent from the hardware transport mechanism 308 of the
`
`primary processor 301 to a hardware transport mechanism 309 of the secondary
`
`
`
`14
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`processor over an inter-chip communication bus 310 (e.g., a HS-USB cable.)” Id.
`
`at 8:24-30. The scatter load controller 304 then transfers the image segments “from
`
`the hardware buffer of the hardware transport mechanism 309 directly into their
`
`respective target locations in the secondary processor’s system memory 305.” Id.
`
`at 9:21-27. The specification of the ’949 patent discloses that one advantage of the
`
`claimed direct transfer from the hardware buffer to the system memory of the
`
`secondary processor is “increased performance on the USB/HSIC bus when the
`
`segments are significantly large (e.g., over 1 megabyte (MB)).” Id. at 9:9-11.
`
`29.
`
`In transferring data directly from the hardware buffer to the target
`
`locations in system memory, the invention of the ’949 patent eliminates the extra
`
`memory copying operations of the prior art. Specifically, the ’949 patent states that
`
`in performing the direct transfer using the hardware buffer, “no extra memory copy
`
`operations occur in the secondary processor.” Id. at 9:42-43. The patent contrasts
`
`the invention with the “conventional techniques employing a temporary buffer,”
`
`stating that the conventional techniques “are bypassed in favor of a more efficient
`
`direct loading process.” Id. at 9:43-46. The direct loading process “does not require
`
`the intermediate buffer operations traditionally required for loading a software image
`
`from a primary processor to a secondary processor.” Id. at 9:46-50.
`
`30.
`
`In avoiding the extra memory copy operations of the prior art, the
`
`invention provides a more efficient loading process. The ’949 patent states, for
`
`
`
`15
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`instance, that the direct scatter load technique of the invention “reduce[s] the time it
`
`takes to boot secondary processors in a multi-processor system where secondary
`
`processor images are transferred from the primary processor. This reduction is
`
`achieved by avoiding extra memory copy operations ….” Id. at 11:17-24; see also
`
`id. at 9:9-11. These passages from the specification disclose that the hardware buffer
`
`enables an efficient direct transfer of the image data, as opposed to less efficient
`
`transfer techniques involving a “temporary buffer” or “intermediate buffer
`
`operations” characteristic of prior art techniques over which the patent repeatedly
`
`distinguishes.
`
`31. The patent repeatedly distinguishes its direct loading technique from
`
`less-efficient techniques involving intermediate buffer operations using temporary
`
`buffers allocated in system memory. See, e.g., id. at 2:23-55, 4:46-57, 5:31-35, 7:16-
`
`30. One drawback of the use of temporary buffers in prior art techniques is that the
`
`resulting extra copy operations (copying image data from the temporary buffer to its
`
`final location in system memory) are less efficient and increase the time required to
`
`boot the processor. The ‘949 patent specification discusses this drawback and
`
`highlights the fact that the ‘949 invention eliminates this drawback by eliminating
`
`the extra copy operations associated with the use of a temporary buffer as opposed
`
`to the use of a hardware buffer. See, e.g., id. at 7:24-30, 9:42-46, 11:11-24. As
`
`repeatedly noted in the patent specification (see, e.g., id.), the result is a more
`
`
`
`16
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`efficient loading process that reduces the time required to boot the secondary
`
`processor.
`
`32. The hardware buffer of the ’949 patent also enables a more efficient
`
`loading process because it is permanent and dedicated to the single task of loading
`
`data segments directly to system memory. As explained above, the conventional
`
`techniques distinguished in the ’949 patent use a temporary buffer that is allocated
`
`by software in general-purpose system memory. The prior-art buffer is temporary
`
`(i.e., not permanent) because it exists only after software allocates it. Because it is
`
`allocated in system memory, it is flexible and can be easily modified under software
`
`control but it is less efficient than a permanent hardware buffer. By contrast, in the
`
`invention of the ’949 patent, the hardware buffer is permanently assigned within the
`
`structure of the hardware to perform the single, specialized task for which it was
`
`designed (i.e., the direct transfer of data into the system memory of a secondary
`
`processor). Such hardware components are typically engineered to support specific
`
`data access patterns, with their operation tightly coordinated with the operation of
`
`the surrounding hardware. See Section III above. The hardware buffer of the ’949
`
`patent is an example of a hardware component that delivers efficient data transfer,
`
`in part, because it is engineered to perform only that task. The permanent and
`
`dedicated nature of the hardware buffer, along with the elimination of “extra
`
`
`
`17
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`memory copy operations,” is critical to enabling the efficient direct scatter loading
`
`technique described and claimed in the ’949 patent.
`
`33. To elaborate, a key difference between the hardware buffers of the ’949
`
`patent and the prior art temporary buffers is that the hardware buffers of the ’949
`
`patent are permanently assigned, within the structure of the hardware, to perform the
`
`specialized task for which they were designed, in this case the direct transfer of data
`
`into the system memory of a secondary processor. It is this permanent assignment
`
`that enables, in part, the efficient direct scatter loading technique claimed in the ‘949
`
`patent. The prior art temporary buffers, in contrast, are allocated by the software in
`
`less efficient system memory. The use of these buffers in prior art techniques
`
`“require an intermediate step” (’949 patent at 7:21) in which the “image is buffered
`
`(e.g., transferred into the system memory) and then later scattered into target
`
`locations (e.g., by a boot loader).” Id. at 7:21-24.
`
`34. For the reasons above, it is my opinion that the term “hardware buffer”
`
`should be construed as a permanent, dedicated buffer that is distinct from system
`
`memory.
`
`C.
`
`Inventor Testimony Of Mr. Haehnichen Is Relevant To The
`Construction Of Hardware Buffer
`35. Trial testimony from named inventor Steve Haehnichen provides
`
`additional insight into the motivation for reducing the boot time. Mr. Haehnichen
`
`
`
`18
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`testified that Qualcomm customer Apple was requiring Qualcomm to deliver a
`
`modem processor boot time of less than a second. Ex. 2003 at 213:22-214:2.
`
`36. Mr. Haehnichen also testified that “we had never booted a modem in 1
`
`second, so it was a pretty – pretty tough bar to meet.” Id. at 214:6-12. Mr.
`
`Haehnichen also testified that, after performing an analysis of the existing technique
`
`that Qualcomm was considering using for this purpose (the so-called Gobi
`
`technique), “there was no way we were going to get to 1 second that way.” Id.
`
`at 215:7-14, referring to the existing Gobi technique.
`
`37. Mr. Haehnichen also testified that, in response, Qualcomm developed
`
`a new technique, the so-called Sahara technique, that did meet Apple’s requirement
`
`for a modem processor boot time of less than a second. Id. at 215:20-216:15.
`
`38. Mr. Haehnichen also testified that “The single biggest thing we did to
`
`speed it up was to avoid copying things around in memory in the modem” and that
`
`“in Sahara we saw that copying time was really slow compared to USB. USB speed
`
`is fast, but then the processing inside was slowing things down. So we really focused
`
`on getting rid of all of those stages of copying so things would come right in the pipe
`
`from USB and land right in memory where they needed to be.” Id. at 216:16-217:2.
`
`39. Mr. Haehnichen’s testimony reflects the fact that a permanent buffer,
`
`for example the hardware buffer of Figure 3 of the ‘949 patent, which is depicted as
`
`part of the Hardware Transport Mechanism (i.e. USB controller), can deliver a more
`
`
`
`19
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`efficient direct transfer as opposed to the less efficient copying of image data using
`
`a temporary buffer as in prior art techniques such as Gobi. Indeed, Mr. Haehnichen
`
`testified that avoiding “copying things around in memory in the modem” was “the
`
`single biggest thing we did to speed it up” (referring to speeding up Sahara in
`
`comparison with Gobi).
`
`40. The fact that the hardware buffer of the ’949 patent is a permanent
`
`buffer enables it to be integrated into and play an important role in efficient direct
`
`data transfer mechanisms such as the USB controller of Figure 3 of the ‘949 patent
`
`and as in Qualcomm’s modem products. The efficiency of the USB data transfer
`
`mechanism is reflected in Mr. Haehnichen’s testimony that “USB speed is fast.”
`
`D.
`41.
`
`Intel’s Arguments Are Wrong
`I have reviewed Intel’s Opening Brief on Remand (Paper 35) and the
`
`Declaration of Bill Lin, Ph.D. (Ex. 1026). Intel’s brief and the supporting
`
`declaration of Dr. Lin include several arguments relevant to my proposed
`
`construction of “hardware buffer.” I disagree with these arguments for the reasons
`
`below.
`
`42.
`
`Intel argues that nothing in the ’949 patent precludes the hardware
`
`buffer from being located in system memory. Intel Br. at 6. But the Federal Circuit
`
`determined that the hardware buffer and system memory are different, and I agree
`
`for the reasons stated above. The Federal Circuit stated that “claim 1 requires both
`
`
`
`20
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`a ‘system memory’ and a ‘hardware buffer,’” and therefore, “there must be some
`
`distinction between those two concepts.” Opinion at 810. The court also stated that
`
`the “claim language ... makes clear [that] Qualcomm’s ‘hardware buffer’ is …
`
`different from ‘system memory.’” Id. at 811.
`
`43.
`
`I also disagree with Intel’s argument because it is contrary to the
`
`invention described in the specification. The ’949 patent specification repeatedly
`
`states that one of the goals of the invention is to improve image loading efficiency
`
`by eliminating extra copy operations (’949 patent at 7:24-30, 5:31-25, 9:42-46,
`
`11:11-24). A person of ordinary skill in the art would understand, as Mr. Haehnichen
`
`testified, that copy operations involving system memory, or any memory with
`
`similar access characteristics, are much slower than data transfers involving
`
`permanent buffers whose sole purpose is to support data transfer operations. The
`
`’949 patent identifies “internal random-access-memory (RAM) or double data rate
`
`(DDR) memory” as system memory in which the prior art temporary buffers are
`
`stored. Id. at 2:31-34. Any attempt to place the claimed “hardware buffer” in RAM
`
`or DDR memory would produce the same inefficiencies as using prior art temporary
`
`buffers and would therefore eliminate the benefits delivered by the claimed
`
`invention in the ’949 patent.
`
`44.
`
`Intel also argues that “dependent claim 2 limits claim 1 by requiring
`
`that the executable software image be loaded ‘without copying data between system
`
`
`
`21
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`memory locations on the secondary processor,’” and that this “confirms that neither
`
`claim 1 nor its ‘hardware buffer’ limitation precludes the possibility of copying data
`
`between system memory locations.” Intel Br. at 7. I disagree. This argument, if
`
`accepted, would improperly broaden claims 1 and 3-9 beyond their correct scope.
`
`As explained above and recognized by the Federal Circuit, the “use of a ‘hardware
`
`buffer’ relates to one of the key claimed advances of the invention—the elimination
`
`of ‘extra memory copy operations’” in system memory. Opinion at 811. Intel’s
`
`argument, if adopted, would yield a claim that permits “copying data between system
`
`memory locations” (Intel Br. at 7), and thus would improperly broaden these claims
`
`beyond the scope of the invention described in the specification.
`
`45. Further, Intel’s argument fails because claims 1 and 2 have different
`
`scopes under my proposed construction. With my construction of “hardware buffer”
`
`inserted, claim 1 requires a scatter loader controller configured to “scatter load each
`
`received data segment based at least in part on the loaded image header, directly
`
`from the [permanent, dedicated buffer that is distinct from system memory] to the
`
`system memory.” Claim 2 further limits the scatter loader controller element by
`
`adding limitations on how it “directly” loads into system memory—specifically,
`
`expressly excluding “copying data between system memory locations on the
`
`secondary processor.” I note that claim 1 recites the term “data segment,” and
`
`claim 2 recites the term “data.”
`
`
`
`22
`
`QUALCOMM EXHIBIT 2015
`Intel v. Qualcomm
`IPR2018-01334
`
`
`
`46.
`
`Intel asserts that that the hardware buffer need not be permanent,
`
`arguing that the ’949 patent does not “distinguish … the use of temporary buffers
`
`per se.” Intel Br. at 9. According to Intel, the specification “distinguishes systems
`
`in which the entire executable image is copied into a temporary buffer.” Id.
`
`(boldface and italics by Intel). I disagree because the ’949 patent also distinguishes
`
`prior-art approaches in which a temporary buffer receives “part of the image data.”
`
`’949 patent at 2:23-55 (explaining the conventional technique in which the
`
`temporary buffer “is used to receive part of the image data from the primary
`
`processor, and from the buffer the image data may be scattered into the memory
`
`(e.g., volatile memory) of the secondary processor”). Thus, the prior-art techniques
`
`distinguished by the ’949 patent are not limited to those that involve copying an
`
`entire executable image into a temporary buffer.
`
`47.
`
`I note that there was a specific design (the so-called “second option”
`
`described in an email from Apple employee Mr. Mujtaba), which did involve
`
`copying the entire image to an intermediate buffer (Ex. 2003 at 206:20-207:22). This
`
`alternative “second option” is different from the prior art Gobi protocol, which did
`
`not copy the entire image to an intermediate buffer. At trial, Qualcomm employee
`
`Claudia de Andrade testified that the prior art Gobi protocol, which did not meet the
`
`Apple performance requirements, and upon which the Sahar