`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`Intel Incorporated
`Petitioner
`
`v.
`
`Qualcomm Incorporated
`Patent Owner
`______________________
`
`Case IPR2018-01336
`Patent 8,838,949
`______________________
`
`PRELIMINARY PATENT OWNER RESPONSE TO PETITION FOR
`INTER PARTES REVIEW PURSUANT TO 37 C.F.R. § 42.107
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`INTRODUCTION ......................................................................................... 1
`I.
`II. THE ’949 PATENT AND ITS PROSECUTION HISTORY .................... 2
`A. Overview of the ’949 Patent ............................................................... 2
`B.
`Prosecution History of the ’949 Patent .............................................. 6
`III. OVERVIEW OF THE CITED REFERENCES ......................................... 7
`A. Overview of Svensson .......................................................................... 7
`B. Overview of Bauer ............................................................................. 11
`C. Overview of Kim ................................................................................ 12
`D. Overview of Zhao .............................................................................. 15
`IV. THE PETITION FAILS TO ESTABLISH A REASONABLE
`
`LIKELIHOOD THAT AT LEAST ONE OF THE CHALLENGED
`
`CLAIMS IS UNPATENTABLE ................................................................ 16
`The Reference Combinations Relied On By Petitioner Do Not
`A.
`
`Disclose an “Image Header” ............................................................. 16
`B.
`The Reference Combinations Relied On By Petitioner Do Not
`
`Disclose “The Image Header and Each Data Segment Being
`
`Received Separately” ........................................................................ 22
`1.
`Not Obvious From Svensson/Bauer Combination ................... 23
`2.
`Not Obvious in View of Kim .................................................... 28
`The Reference Combinations Relied On By Petitioner Do Not
`C.
`Disclose Scatter Loading Each Received Data Segment Directly to
`
`System Memory ................................................................................. 32
`
`V. CONCLUSION ............................................................................................ 37
`
`
`
`
`I.
`
`INTRODUCTION
`Intel Incorporated (“Intel” or “Petitioner”) seeks review of claims 18-21 of
`
`U.S. Patent No. 8,838,949 (the “’949 Patent”) based on obviousness grounds. 1
`
`Institution should be denied.
`
`The claims of the ’949 Patent relate to a novel way to transfer an executable
`
`software image from memory of a first processor into memory of a second processor
`
`without requiring an intermediate buffering step. None of the references relied on
`
`by the Petitioner address this problem. It is therefore not surprising that Petitioner’s
`
`proposed combination fails to disclose many claim limitations, forcing Petitioner to
`
`repeatedly rely on speculation and lawyer argument about what might have been
`
`obvious to the person of ordinary skill in the art (POSA). This type of “hand-waving”
`
`obviousness analysis is insufficient under KSR Int’l Co. v. Teleflex Inc., 550 U.S.
`
`398 (2007), and thus fails to establish a reasonable likelihood that at least one of the
`
`claims challenged in the petition is unpatentable.
`
`Further, the Declaration of Dr. Bill Lin (Ex. 1202), filed by Petitioner does
`
`not remedy the deficiencies of the Petition. In fact, the Declaration provides little to
`
`no independent evidence or factual support and largely parrots the arguments made
`
`in the Petition. The Board has recognized that declarations that merely “expertize”
`
`
`1 Petitioner seeks review of claims 1-9, 22 and 23 of the ’949 Patent in
`IPR2018-01334, and seeks review of claims 10-17 in IPR2018-01335.
`
`
`
`1
`
`
`
`lawyer argument without providing independent expert analysis are entitled to little
`
`or no evidentiary weight. See, e.g., Initiative for Medicines, Access, & Knowledge,
`
`Inc. v. Gilead Pharmasset LLC, IPR2018-00120, Paper 7 at 21 (PTAB May 4, 2018)
`
`(declaration merely “parrots the Petition … and, therefore, does not remedy the
`
`various deficiencies in Petitioner’s ground of unpatentability”) (citing Ashland Oil,
`
`Inc. v. Delta Resins & Refractories, Inc., 776 F.2d 281, 294 (Fed. Cir. 1985)).
`
`Because the Declaration of Dr. Lin adds nothing to the allegations set forth in the
`
`Petition, the Declaration should be given little or no evidentiary weight.
`
`Intel’s petition fails to establish a reasonable likelihood of prevailing on any
`
`claim, and therefore the Board should decline to institute trial on the ’949 Patent.
`
`II. THE ’949 PATENT AND ITS PROSECUTION HISTORY
`A. Overview of the ’949 Patent
`U.S. Patent No. 8,838,949 (“the ’949 Patent”), titled “Direct Scatter Loading
`
`of Executable Software Image From a Primary Processor to One or More Secondary
`
`Processor in a Multi-Processor System,” generally relates to multi-processor
`
`systems in which a primary processor is coupled to a non-volatile memory storing
`
`executable software image(s) of one or more secondary processors that are each
`
`coupled to a dedicated volatile memory, where the executable software images are
`
`efficiently communicated from the primary processor to the secondary processor(s)
`
`in a segmented format (e.g., using a direct scatter load process). See Ex. 1201 (’949
`
`
`
`2
`
`
`
`Patent) at 1:25-33. The ’949 Patent issued on September 16, 2014 from an
`
`application filed on March 21, 2011. The ’949 Patent claims priority to three
`
`provisional applications, the earliest of which was filed on April 14, 2010.
`
`“In a multi-processor system, each processor may require respective boot code
`
`for booting up. As an example, in a smartphone device that includes an application
`
`processor and a modem processor, each of the processors may have respective boot
`
`code for booting up.” Id. at 1:39-43. The ’949 Patent explains that in some multi-
`
`processor systems, one of the processors is responsible for storing the boot code for
`
`one or more other processors in the system and loading the respective boot code to
`
`the other processor(s) at power-up. “In this type of system, the software (e.g., boot
`
`image) is downloaded from the first processor to the other processor(s) (e.g., to
`
`volatile memory of the other processor(s)), and thereafter the receiving processor(s)
`
`boots with the downloaded image.” Id. at 2:1-14.
`
`The Background section of the ’949 Patent describes systems in which the
`
`boot image is loaded onto a target “secondary” processor from a first “primary”
`
`processor using “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.” See id. at 2:17-22. “One way of performing such loading is to
`
`allocate a temporary buffer into which each packet is received.” Id. at 2:25-26. “The
`
`temporary buffer would be some place in system memory, such as in internal
`
`
`
`3
`
`
`
`random-access-memory (RAM) or double data rate (DDR) memory, for example.”
`
`Id. at 2:32-34.
`
`The ’949 Patent improves upon the technology described in its Background
`
`section by providing “a direct scatter load technique” for loading a segmented image
`
`from a primary processor’s non-volatile memory to a secondary processor’s volatile
`
`memory without using “the intermediate step of buffering required in traditional
`
`loading processes.” See Ex. 1201 at 4:43-47; 7 20-26. The ’949 Patent refers to this
`
`as a “Zero Copy Transport Flow,” an example of which is illustrated in FIG. 3,
`
`reproduced below.
`
`
`
`
`
`4
`
`
`
`In FIG. 3, a software image (e.g., boot image) for the secondary processor 302
`
`is stored to non-volatile memory of the primary processor 301. See Ex. 1201 at 7:67-
`
`8:2. The software image 303 is a multi-segmented image that includes an image
`
`header and multiple data segments (shown as data segments 1-5). Id. at 8:2-5. In a
`
`first stage of the loading process, the image header is transferred from the primary
`
`processor 301 to a scatter loader controller 304 of the secondary processor 302. Id.
`
`at 8:9-11; 9:21-23. The image header includes information used by the secondary
`
`processor 302 to identify where each of the image data segments are to be placed
`
`into system memory 305. Id. at 8:18-21; 8:57-63; 9:23-24. “Data segments are then
`
`sent from system memory 307 to the primary hardware transport mechanism 308.
`
`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
`
`processor over an inter-chip communication bus 310 (e.g., a HS-USB cable.)” Id. at
`
`8:24-30. Using the information from the image header, the scatter load controller
`
`304 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. See id. at 9:21-27.
`
`
`
`
`
`Claim 18 of the ’949 Patent is exemplary:
`
`18. A multi-processor system comprising:
`
`5
`
`
`
`a primary processor coupled with a first non-volatile memory, the first
`non-volatile memory coupled to the primary processor and storing a
`file system for the primary processor and secondary processor;
`a secondary processor coupled with a second non-volatile memory, the
`second non-volatile memory coupled to the secondary processor and
`storing configuration parameters and file system for the secondary
`processor; and
`an interface communicatively coupling the primary processor and the
`secondary processor, an executable software image being received by
`the secondary processor via the interface, the executable software
`image comprising an image header and at least one data segment, the
`image header and each data segment being received separately, and
`the image header being used to scatter load each received data
`segment directly to a system memory of the secondary processor.
`
`B.
`Prosecution History of the ’949 Patent
`U.S. Patent Application No. 13/052,516, which later issued as the ’949 Patent,
`
`was filed on March 21, 2011. The original claims of the application were all rejected
`
`in an Office Action issued on July 19, 2013 as being anticipated by International
`
`Publication No. WO 2006/077068 to Svensson (Ex. 1203), which is referred to by
`
`Petitioner as “Svensson PCT.” See Ex. 1104. Svensson PCT claims priority to, and
`
`includes the same disclosure as, the Svensson patent (Ex. 1210) that is relied on
`
`extensively throughout the Petition as the primary reference.
`
`In response to the rejections over Svensson PCT, the independent claims were
`
`amended to require receiving, at a secondary processor, an image header and at least
`
`one data segment of an executable software image, with “the image header and each
`
`data segment being received separately.” See Ex. 1205 at 2-7. The claims were
`
`
`
`6
`
`
`
`further amended to require scatter loading each data segment directly to system
`
`memory of the secondary processor. See id.
`
`Following the amendments distinguishing the claims from Svensson PCT, no
`
`further prior art rejections were made by the Patent Office. The ’949 Patent was
`
`allowed on August 11, 2014 (see Ex. 1206), and issued on September 16, 2014.
`
`III. OVERVIEW OF THE CITED REFERENCES
`A. Overview of Svensson
`U.S. Patent No. 7,356,680 (“Svensson”), titled “Method of Loading
`
`Information Into a Slave Processor in a Multi-Processor System Using an Operating-
`
`System-Friendly Boot Loader,” generally relates to the “initialization of electronic
`
`systems having multiple programmable processors.” Ex. 1210 (Svensson) at 1:9-10.
`
`More specifically, Svensson discloses “an OS-friendly bootloader and methods that
`
`meet the challenge of integrating an OS with a bootloader in systems in which the
`
`host and a client have a communication mechanism that requires the OS for the
`
`mechanism to work and the client has two memory systems: one visible to both host
`
`and client and one visible only to the client.” Id. at 3:42-48. An example of
`
`Svensson’s system is depicted in FIG. 1, reproduced below.
`
`
`
`7
`
`
`
`
`
`As shown in FIG. 1, the multiprocessor system disclosed in Svensson includes
`
`a host processor (ARM CPU 102) and a client processor (DSP CPU 104). The client
`
`processor (DSP CPU 104) has access to an “internal” SARAM and DARAM 108 as
`
`well as an “external” XRAM 110, with an “intermediate storage area” defined within
`
`the “internal” memory 108. See Ex. 1210 at 3:64-4:3. Svensson explains that the
`
`“SARAM and DARAM 108 can be loaded from the non-volatile memory 106 by
`
`the trivial ‘push’ method.” Id. at 4:9-10. “When code needs to be loaded to the
`
`SRAM 110 during boot, however, a bootloader solution is required because the
`
`SRAM 110 is invisible to, i.e., not accessible by, the CPU 102 and so boot code
`
`cannot be pushed to the XRAM.” Id. at 4:11-14. Svensson discloses an “OS-
`
`friendly” bootloader solution with reference to FIG. 2 (below).
`
`
`
`8
`
`
`
`
`
`The “OS-friendly bootloader” shown in FIG. 2 of Svensson includes “two
`
`stages or modes of operations.” Id. at 4:20-21. In the first stage of operation,
`
`information, such as the bootloader, the OS, and any necessary start-up code, is
`
`pushed from the non-volatile memory 106 of the ARM device (i.e., host) into the
`
`commonly visible “internal” memories 108 of the DSP device (i.e, slave). See id. at
`
`4:20-28. “When this ‘push’ is finished (Step 206), the slave 104 is allowed to boot
`
`
`
`9
`
`
`
`(Step 208) and to start up the OS (e.g., it is released from the reset state) and its
`
`normal communication mechanisms (Step 210).” Id. at 4:31- 35.
`
`In the second stage of operation, “the host bootloader fills the intermediate
`
`storage area with information (code and/or data) to be loaded into the slave’s
`
`invisible memory [i.e., ‘external’ XRAM 110](Step 216).” Id. at 5:53-56. After
`
`receiving a message from the host indicating that the “intermediate storage area” is
`
`filled, “[t]he slave copies the contents of the intermediate storage area to appropriate
`
`locations in its slave-private memory [i.e., ‘external’ XRAM 110] (Step 220).” Id.
`
`at 5:60-66.
`
`Svensson further discloses that boot code and data are transferred to the
`
`“intermediate storage area” and then to the XRAM 110 in “blocks,” as shown in
`
`FIG. 3 (reproduced below). See, Id. at 6:12-25. Svensson explains with reference
`
`to FIG. 3 that “[a] block of code and/or data to be transferred into the intermediate
`
`storage area includes a header that indicates the length of the block and where it is
`
`to be loaded in the slave memory, i.e., the destination address.” Id at 6:20-24.
`
`
`
`10
`
`
`
`
`
`B. Overview of Bauer
`U.S. Patent Application Publication No. 2006/0288019 (“Bauer”), titled
`
`“Flexible Data File Format,” generally relates to a binary data format for digital data
`
`files. Bauer was filed on October 14, 2005, and published on December 21, 2006.
`
`An example of the binary data format disclosed in Bauer is illustrated in FIGs.
`
`1A-1C (reproduced below.) As shown in FIG. 1A, the binary data format includes
`
`a header 102, section information 104, and one or more sections 106. The section
`
`information contains the information for all sections which, according to Bauer, “is
`
`more advantageous than having each section include its own information, i.e., the
`
`information is concentrated rather than distributed across the sections.” Ex. 1209
`
`(Bauer) at para. 27.
`
`As shown in FIG. 1B (above), the header 102 contains information about the
`
`total size and the total number of sections 106. See id. at para. 33. As shown in
`
`
`
`11
`
`
`
`
`
`FIG. 1C, the section information 104 contains an entry for each section 106 that
`
`includes information about the section length and load address. See id. at para. 34.
`
`Bauer explains that “[h]aving information about the sections collected in the header
`
`102 and section information 104 simplifies optimization in a number of
`
`circumstances, for instance, if sections are to be loaded into memory.” Id. at para.
`
`43. “The block 104 lists all sections, preferably in order of memory location, and
`
`this makes memory loading efficient as there is no need to search through an image
`
`for section headers when loading.” Id.
`
`Bauer also provides a diagram (FIG. 2) of the same multi-processor system
`
`that is shown in FIG. 1 of Svensson, but provides no details on how its binary data
`
`format would be used in the illustrated multi-processor system. See id. at FIG. 2 and
`
`paras. 35-36.
`
`C. Overview of Kim
`Korean Patent Application Publication No. 2002/0036354 (“Kim”), titled
`
`“Method for Loading Using Distributed System Startup Loader in Private Branch
`
`Exchange,” generally relates to a loading process using a distributed system startup
`
`loader in an exchanger. See Ex. 1212 (Kim) at 2:3-4. Kim was filed on November
`
`9, 2000, and published on May 16, 2002.
`
`FIG. 1 of Kim (reproduced below) depicts a system management processor
`
`11 coupled to a hard disk drive 17. Processors 13, 14, and 15 are secondary
`
`
`
`12
`
`
`
`processors that need blocks of data from the hard disk drive 17. See id. at 4:8-21.
`
`To achieve this, “a booter of each of the SSPs 14 or the main processors 13 requests
`
`a block needed for a processor startup from the system startup loader of the system
`
`management processor.” Id. at 4:22-23.
`
`
`
`An example of Kim’s loading process is depicted in FIG. 4 (reproduced
`
`below). As shown in FIG. 4, a “booter” requests a block header that needs to be
`
`loaded from the “system startup loader” (step S410). See id. at 10:3-5. In response,
`
`the system startup loader transmits the requested block header from the booter (step
`
`S411). See id. at 10:5-6. The booter then “transmits a program block request
`
`
`
`13
`
`
`
`message for requesting text code or data code, which is an actual program block, to
`
`the system startup loader on the basis of the received header information of the block
`
`(S413).” Id. at 10:6-9. The system startup loader then transmits the requested block
`
`to the booter (step S415), and the operation repeats as necessary to load each
`
`available block (step S417). See id. at 10:10-16.
`
`
`
`
`
`14
`
`
`
`D. Overview of Lim
`U.S. Patent No. 7,203,829 (“Lim”), titled “Apparatus and Method for
`
`Initializing Coprocessor for use in System Comprised of Main Processor and
`
`Coprocessor,” generally relates to an apparatus and method for booting a
`
`coprocessor for use in a system that includes a main processor and a coprocessor.
`
`See Ex. 114 (Lim) at 1:21-25. Lim was filed on June 10, 2004, and issued on April
`
`10, 2007. An example of Lim’s system is shown in FIG. 2, reproduced below.
`
`
`
`As shown in FIG. 2 (above), Lin’s system includes a first flash memory 110,
`
`a second flash memory 120, external RAM 130, and other peripheral devices 140
`
`that are driven by a control signal received from a main processor 100. See id. at
`
`6:28-39. The first flash memory 110 stores “a boot module, a loader module, a flash
`
`file system, and other execution program modules of the main processor 100.” See
`
`
`
`15
`
`
`
`id. at 6:39-42. The second flash memory 120 stores “nonvolatile data generated by
`
`a control signal of the main processor 100, for example, content data, font data, bit
`
`data, phonebook data, and similar data.” See id. at 6:42-46. “The main processor
`
`100 performs its initialization operating using individual software modules stored in
`
`the first flash memory 110 when it is initially powered on, and provides the
`
`coprocessor 200 with a power-supply voltage such that it is able to initialize the
`
`coprocessor 200.” Id. at 6:46-51.
`
`IV. THE PETITION FAILS TO ESTABLISH A REASONABLE
`LIKELIHOOD THAT AT LEAST ONE OF THE CHALLENGED
`CLAIMS IS UNPATENTABLE
`The Petition includes only one Ground, alleging obviousness of claims 18-21
`
`by the combination of Svensson, Bauer, Kim, and Lim. As demonstrated below,
`
`Petitioner’s proposed combination fails to disclose many claim limitations, and thus
`
`fails to establish a reasonable likelihood that at least one of the challenged claims is
`
`unpatentable.
`
`A. The Combination of Svensson, Bauer, Kim, and Lim
`Does Not Disclose an “Image Header”
`Independent claims 18 and 20 of the ’949 Patent both require receiving, at a
`
`secondary processor, “an image header” and at least one data segment for an
`
`executable software image. Petitioner proposes a claim construction for “image
`
`header” to mean “a header associated with the entire image that specifies where the
`
`
`
`16
`
`
`
`data segments are to be placed in the system memory.” See Petition at 17-18. Even
`
`under its own proposed construction, however, Petitioner must acknowledge that the
`
`claimed “image header” is not disclosed by any of its cited references, either alone
`
`or in combination. See id. at 45, 47-50, and 73. Petitioner’s only argument is that
`
`modifying the references to provide the claimed “image header” would “be obvious
`
`to try.” See id. at 47-50.
`
`Specifically, Petitioner alleges that the claimed “image header” is obvious
`
`over the combination of Bauer and Svensson, but acknowledges that Bauer’s file
`
`format does not meet the claimed “image header” because “in Bauer, the header
`
`(header 102) is associated with the entire image, but it does not specify where the
`
`data segments (sections) are to be placed in the system memory (DSP XRAM).”
`
`Petition at 47. “Instead, Bauer teaches that the section information 104, rather than
`
`the header 102, specifies the destination addresses.” Id. Despite the admitted
`
`deficiencies of the Bauer and Svensson references, the Petitioner alleges, with no
`
`supporting evidence, that “[a] POSITA would find that storing the destination
`
`addresses in the header rather than in a different location would have been obvious
`
`to try because of the limited number of locations to put the destination addresses.”
`
`Id. at 49. But, based on nothing more than speculation and lawyer argument,
`
`Petitioner’s “obvious to try” analysis cannot support a reasonable likelihood that any
`
`of the challenged claims are unpatentable.
`
`
`
`17
`
`
`
`To support a conclusion that a claim would have been obvious based on an
`
`“obvious to try” rationale, the Petitioner must establish that at the time of the
`
`invention: (1) there had been a recognized problem or need in the art; (2) there had
`
`been a finite number of identified, predictable potential solutions with a reasonable
`
`expectation of success; and (3) that a POSA could have pursued the known potential
`
`solutions with a reasonable expectation of success. See MPEP § 2143(I)(E); see also
`
`KSR at 421 (invalidation of a claim under § 103 as being “obvious to try” requires a
`
`showing that “there [was] a design need or market pressure to solve a problem and
`
`there [was] a finite number of identified, predictable solutions”). Petitioner’s
`
`“obvious to try” analysis fails to satisfy these necessary criteria.
`
`First, the Petitioner makes no attempt to demonstrate that its proposed
`
`“obvious to try” modification of the Bauer and Svensson references is responsive to
`
`a recognized problem or need in the art. To invalidate a claim under § 103 as being
`
`obvious to try, the Petitioner first needs to establish that “there [was] a design need
`
`or market pressure to solve a problem.” See KSR at 421. Petitioner completely
`
`ignores this prong of the “obvious to try analysis,” failing to identify any specific
`
`design need or market pressure to solve a problem that would have led the POSA to
`
`“try” its proposed modification of the Bauer and Svensson references.
`
`The ’949 Patent recognizes an inefficiency in existing multi-processor
`
`systems that load a software image (e.g., boot code) from a first processor to a second
`
`
`
`18
`
`
`
`processor using an intermediate step where the software image is first transferred
`
`into a temporary buffer within system memory of the second processor and is then
`
`later transferred from the temporary buffer into target locations of the second
`
`processor’s system memory. See Ex. 1201 at 2:14-41. As a solution to this problem,
`
`the ’949 Patent teaches transferring software image segments “directly into their
`
`respective target locations in the secondary processor’s system memory,” without
`
`the use of a “temporary buffer” in system memory, using an “image header” that
`
`“provides information as to where the data segments are to be located in the system
`
`memory.” See, e.g., id. at 9:21-56.
`
`The Bauer and Svensson references do not resolve, or even recognize, the
`
`“temporary buffer” problem addressed by the ’949 Patent. Nor does the Petitioner
`
`make any real attempt to establish that its “obvious to try” modification of Bauer is
`
`based on any specific recognized problem or need in the field. Instead, the Petitioner
`
`baldly concludes, with no evidentiary support, that the POSA familiar with Bauer
`
`and Svensson “would have looked to the teachings of both to understand how
`
`different file formats can be loaded in the same multi-processor system,” and “would
`
`have also contemplated other types of file formats that result in greater efficiency in
`
`loading data, reduced response times, and space-efficient storage.” See Petition
`
`at 48. But Petitioner’s recitation of vague and universal design goals, such as
`
`increasing efficiency and reducing response time, fails to establish a specific
`
`
`
`19
`
`
`
`problem or need in the art that would motivate the POSA to “try” known options to
`
`solve the specific problem. See, e.g., Fisher & Paykel Healthcare Limited v. Resmed
`
`Limited, IPR2017-00501, Paper 41 at 37 (PTAB Oct. 23, 2018) (rejecting obvious-
`
`to-try argument where petitioner failed to articulate a particular “design need or
`
`market pressure to solve a problem and specifically, what that problem is”) (citing
`
`Unigene Labs, Inc. v. Apotex, Inc., 655 F.3d 1352, 1361 (Fed. Cir. 2011) (“[A]
`
`combination is only obvious to try if a [POSA] has a good reason to pursue the
`
`known options.”) (internal quotations omitted)).
`
`In fact, the only discussion within the Petition of any specific problem or need
`
`in the art that is relevant to an “image header” that “specifies where the data
`
`segments are to be placed in the system memory” is by reference to the “temporary
`
`buffer” problem set forth in the Background section of the ’949 Patent. See Petition
`
`at 10. But the recognition of this problem is part of the advancements made by the
`
`inventors of the ’949 Patent, and cannot properly serve as the basis for the
`
`Petitioner’s “obvious to try” analysis. See, e.g., Leo Pharms. Prods. Ltd., v. Rea,
`
`726 F.3d 1346, 1356-57 (Fed. Cir. 2013) (rejecting an obvious to try argument
`
`because “[u]ntil the advancement made by the inventors… [t]he problem was not
`
`known, the possible approaches to solving the problem were not known or finite,
`
`and the solution was not predictable… [i]ndeed ordinary artisans would not have
`
`thought to try at all because they would not have recognized the problem.”)
`
`
`
`20
`
`
`
`Further, having ignored the first prong of the “obvious to try” analysis,
`
`Petitioner also fails to establish that there had been a finite number of identified,
`
`predictable potential solutions that the POSA could have pursed to solve the problem
`
`with a reasonable expectation of success. See KSR at 421. Petitioner argues that,
`
`based on the teachings of Bauer regarding the location of its header and section
`
`information, the POSA would have understood that there are only two possible
`
`locations where the destination addresses could be stored. See Petition at 49.
`
`Therefore, despite Bauer’s explicit teaching that the destination addresses should be
`
`included within the section information, Petitioner argues that it would have been
`
`“obvious to try” storing the destination addresses in the header instead of within the
`
`section information. See id. But this argument misses the point of an “obvious to
`
`try” analysis as contemplated by the Supreme Court in KSR.
`
`The proper inquiry under KSR is not whether there are a finite number of ways
`
`that some feature within a reference might possibly be modified, despite there being
`
`no reason to do so other than impermissible hindsight reconstruction. Rather, the
`
`inquiry under KSR is whether there are only a finite number of potential solutions to
`
`a well-recognized problem that the POSA would have known could be applied with
`
`a reasonable expectation of success. Petitioner makes no attempt to explain how its
`
`proposed modification of Bauer is one of a finite number of possible solutions to a
`
`known problem. As such, Petitioner’s “obvious to try” analysis amounts to little
`
`
`
`21
`
`
`
`more than an argument that the POSA would have “tried” to modify Bauer because
`
`it could, theoretically, have been modified. This type of speculative analysis falls
`
`far short of providing the “articulated reasoning with some rational underpinning”
`
`necessary to support a conclusion of obviousness. See KSR at 418; see also Leo
`
`Pharms. Prods. at 1357 (“This court and obviousness law in general recognizes an
`
`important distinction between combining known options into ‘a finite number of
`
`identified, predictable solutions,’ and ‘merely throwing metaphorical darts at a board’
`
`in hopes of arriving at a successful result.”) (citations omitted); In re Kubin, 561
`
`F.3d 1351, 1359 (Fed. Cir. 2009) (“In such circumstances, where a defendant merely
`
`throws metaphorical darts at a dart board filled with combinatorial prior art
`
`possibilities, courts should not succumb to hindsight claims of obviousness.”) The
`
`Petition should be denied for this reason alone.
`
`B.
`
`The Combination of Svensson, Bauer, Kim, and Lim Does
`Not Disclose “The Image Header and Each Data Segment
`Being Received Separately”
`Independent claims 18 and 20 of the ’949 Patent require receiving, at a
`
`secondary processor, an image header and at least one data segment of an executable
`
`software image, with “the image header and each data segment being received
`
`separately.” Even if Petitioner’s proposed Svensson/Bauer combination did disclose
`
`an “image header,” Petitioner has failed to establish obviousness of “the image
`
`
`
`22
`
`
`
`header and each data segment being received separately” over any combination of
`
`references.
`
`1.
`Not Obvious From Svensson/Bauer Combination
`Petitioner first alleges that the claim element “the image header and each data
`
`segment being received separately” is somehow disclosed by the combination of
`
`Svensson and Bauer. See Petition at 55-57 and 73. But this claim element is not
`
`disclosed by Svensson. And, as recognized by Petitioner, Bauer describes a file
`
`format that can be used in a multiprocessor system, but provides very little detail
`
`about the specific operations of the multi-processor system. See, e.g., Petition at 54
`
`(“Bauer does not explicitly describe the loading process from the primary processor
`
`to the secondary processor in much detail.”). Petitioner’s attempt to show this claim
`
`element in the combination of Svensson and Bauer is therefore without merit.
`
`Svensson discloses a multiprocessor system (shown in FIG. 1 below) that
`
`includes a host processor (ARM CPU 102) and a client processor (DSP CPU 104).
`
`As shown in FIG. 1, the client processor (DSP CPU 104) has access to an “internal”
`
`SARAM and DARAM 108 as well as an “external” XRAM 110, with an
`
`“intermediate storage area” defined within the “internal” memory 108. See Ex. 1210
`
`(Svensson) at 3:64-4:3. Svensson is directed to a method for bootloading the
`
`“external” XRAM 110 of the DSP device (i.e., client processor) from non-volatile
`
`memory 106 of the ARM device (i.e., host processor) by pushing boot code and data
`
`
`
`23
`
`
`
`to the “intermediate storage area” of the DSP’s “internal” memory 108 and then
`
`transferring the boot code and data from the “intermediate storage area” to the
`
`“external” XRAM 110. See e.g., id. at FIG. 2; 6:12-25.
`
`
`
`Svensson discloses that boot code and data is transferred to the “intermediate
`
`storage area” and then to the XRAM 110 in “blocks,” as shown in FIG. 3 (reproduced
`
`below). See id. at 6:12-25. Svensson explains with reference