UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`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
`
`
`______________________
`
`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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
