`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`Intel Incorporated
`Petitioner
`
`v.
`
`Qualcomm Incorporated
`Patent Owner
`______________________
`
`Case IPR2018-01334
`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
`IV. THE PETITION FAILS TO ESTABLISH A REASONABLE
`
`LIKELIHOOD THAT AT LEAST ONE OF THE CHALLENGED
`
`CLAIMS IS UNPATENTABLE ................................................................ 15
`The Combination of Svensson, Bauer, and Kim Does Not Disclose
`A.
`
`an “Image Header” ........................................................................... 15
`B.
`The Combination of Svensson, Bauer, and Kim Does Not Disclose
`
`“The Image Header and Each Data Segment Being Received
`
`Separately” ......................................................................................... 21
`1.
`Not Obvious From Svensson/Bauer Combination ................... 21
`2.
`Not Obvious in View of Kim .................................................... 27
`The Combination of Svensson, Bauer, and Kim Does Not Disclose
`C.
`Scatter Loading Each Received Data Segment Directly to System
`
`Memory .............................................................................................. 31
`
`V. CONCLUSION ............................................................................................ 37
`
`
`
`
`I.
`
`INTRODUCTION
`Intel Incorporated (“Intel” or “Petitioner”) seeks review of claims 1-9, 22, and
`
`23 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. 1002), 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 10-17 of the ’949 Patent in IPR2018-
`01335, and seeks review of claims 18-21 in IPR2018-01336.
`
`
`
`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. 1001 (’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. 1001 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. 1001 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 1 of the ’949 Patent is exemplary:
`
`1. A multi-processor system comprising:
`a secondary processor comprising:
`
`5
`
`
`
`system memory and a hardware buffer for receiving an image header
`and at least one data segment of an executable software image, the
`image header and each data segment being received separately,
`and
`a scatter loader controller configured:
`to load the image header, and
`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;
`a primary processor coupled with a memory, the memory storing the
`executable software image for the secondary processor; and
`an interface communicatively coupling the primary processor and the
`secondary processor, the executable software image being received
`by the secondary processor via the interface.
`
`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. 1003), which is referred to by
`
`Petitioner as “Svensson PCT.” See Ex. 1004. Svensson PCT claims priority to, and
`
`includes the same disclosure as, the Svensson patent (Ex. 1010) 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. 1005 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. 1006), 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. 1010 (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. 1010 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. 1009
`
`(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. 1012 (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
`
`
`
`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 1-9,
`
`22, and 23 by the combination of Svensson, Bauer, and Kim. 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, and Kim Does Not
`Disclose an “Image Header”
`Independent claims 1 and 22 of the ’949 Patent both require the receipt of “an
`
`image header” and at least one data segment of 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 data segments are to be
`
`placed in the system memory.” See Petition at 17. 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 34. Petitioner’s only argument is that modifying the references to provide the
`
`claimed “image header” would “be obvious to try.” See id. at 34-36.
`
`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
`
`
`
`15
`
`
`
`(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 34. “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 36. 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.
`
`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
`
`
`
`16
`
`
`
`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
`
`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. 1001 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
`
`
`
`17
`
`
`
`“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 35. But Petitioner’s recitation of vague and universal design goals, such as
`
`increasing efficiency and reducing response time, fails to establish a specific
`
`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]
`
`
`
`18
`
`
`
`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.”)
`
`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
`
`
`
`19
`
`
`
`locations where the destination addresses could be stored. See Petition at 35.
`
`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. at 36. 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
`
`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
`
`
`
`20
`
`
`
`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, and Kim Does Not Disclose
`“The Image Header and Each Data Segment Being Received
`Separately”
`Independent claims 1 and 22 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
`
`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 37-39. But this claim element is not disclosed
`
`by Svensson. And, as recognized by Petitioner, Bauer describes a file format that
`
`
`
`21
`
`
`
`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 33 (“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. 1010
`
`(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
`
`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.
`
`
`
`22
`
`
`
`
`
`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 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.
`
`Because Svensson’s blocks, as shown in FIG. 3 (above), include both the
`
`header and the actual data, the transfer of a “block” in Svensson results in the header
`
`and the data being received together, i.e., not separately. The Patent Office therefore
`
`
`
`
`
`23
`
`
`
`correctly recognized that Svensson does not teach or suggest the claim element “the
`
`image header and each data segment being received separately.”
`
`Bauer does not remedy Svensson’s deficiency. Whereas Svensson is directed
`
`to a method for bootloading a client processor in a multi-processor system, Bauer is
`
`directed to a “flexible data file format” that may be used in a multi-processor system.
`
`See Ex. 1009 (Bauer), title; para. 35. The file format of Bauer includes a header 102,
`
`section information 104, and section data 106, as shown in FIG. 1A (reproduced
`
`below).
`
`
`
`Bauer provides a diagram of the same multi-processor system that is shown
`
`in FIG. 1 of Svensson, but provides no details on how its image file format would
`
`be used in the described multi-processor system. See id. at FIG. 2 and paras. 0035-
`
`0036. Bauer therefore does not teach or suggest “the image header and each data
`
`segment being received separately.”
`
`Petitioner nonetheless argues that the combination of Bauer and Svensson
`
`somehow renders this claim element obvious. Specifically, Petitioner argues that
`
`“Bauer and Svensson combined teaches that it is important that the
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
