`Trials@uspto.gov
`571-272-7822 Date: March 16, 2020
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`INTEL CORPORATION,
`Petitioner,
`v.
`QUALCOMM INCORPORATED,
`Patent Owner.
`
`IPR2018-013341
`Patent 8,838,949 B2
`
`
`
`
`
`
`
`
`
`Before TREVOR M. JEFFERSON, DANIEL J. GALLIGAN, and
`AARON W. MOORE, Administrative Patent Judges.
`GALLIGAN, Administrative Patent Judge.
`
`
`
`
`
`JUDGMENT
`Final Written Decision
`Determining Some Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`
`1 IPR2018-01335 and IPR2018-01336 have been consolidated with the
`instant proceeding.
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`I. INTRODUCTION
`In this inter partes review, Intel Corporation (“Petitioner”) challenges
`the patentability of all claims (1–23) of U.S. Patent No. 8,838,949 B2 (“the
`’949 patent,” Ex. 1001), which is assigned to Qualcomm Incorporated
`(“Patent Owner”).
`We have jurisdiction under 35 U.S.C. § 6. This Final Written
`Decision, issued pursuant to 35 U.S.C. § 318(a), addresses issues and
`arguments raised during the trial in this inter partes review. For the reasons
`discussed below, we determine that Petitioner has proven by a
`preponderance of the evidence that claims 10, 11, 13–15, and 18–23 are
`unpatentable but that Petitioner has not proven by a preponderance of the
`evidence that claims 1–9, 12, 16, and 17 are unpatentable. See 35 U.S.C.
`§ 316(e) (“In an inter partes review instituted under this chapter, the
`petitioner shall have the burden of proving a proposition of unpatentability
`by a preponderance of the evidence.”).
`A. Procedural History
`On July 3, 2018, Petitioner filed three petitions challenging claims of
`the ’949 patent as follows: IPR2018-01334 (claims 1–9, 22, and 23),
`IPR2018-01335 (claims 10–17), and IPR2018-01336 (claims 18–21). In
`each proceeding, Patent Owner filed a Preliminary Response. Paper 7 (in
`each proceeding). We instituted review in each case on all grounds
`presented, which are as follows:
`
`
`
`2
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`Claims Challenged
`1–15, 22, 23
`16, 17
`18–21
`
`35 U.S.C. §2
`103(a)
`103(a)
`103(a)
`
`References
`Bauer,3 Svensson,4 Kim5
`Bauer, Svensson, Kim, Zhao6
`Bauer, Svensson, Kim, Lim7
`
`IPR2018-01334, Paper 10 (“Dec. on Inst.”), 29; IPR2018-01335, Paper 10
`(“1335 Dec. on Inst.”),8 38; IPR2018-01336, Paper 10 (“1336 Dec. on
`Inst.”), 32.
`After institution, we consolidated IPR2018-01335 and
`IPR2018-01336 with IPR2018-01334 and terminated IPR2018-01335 and
`IPR2018-01336. Paper 12.
`During the trial, Patent Owner filed a Response (Paper 16, “PO
`Resp.”), Petitioner filed a Reply (Paper 21, “Pet. Reply”), and Patent Owner
`filed a Sur-reply (Paper 25, “PO Sur-reply”).
`An oral hearing was held on December 12, 2019, a transcript of which
`appears in the record. Paper 29 (“Tr.”).
`
`
`2 The Leahy-Smith America Invents Act (“AIA”) included revisions to
`35 U.S.C. §§ 103 and 112 that became effective after the filing of the
`application for the ’949 patent. Therefore, we apply the pre-AIA versions of
`these sections.
`3 US 2006/0288019, published Dec. 21, 2006 (Ex. 1009).
`4 US 7,356,680 B2, issued Apr. 8, 2008 (Ex. 1010).
`5 Korean Patent Application Publication No. 10-2002-0036354, published
`May 16, 2002 (Ex. 1011). References to Kim in this Decision are to the
`English translation provided by Petitioner as Exhibit 1012.
`6 US 2007/0140199 A1, published June 21, 2007 (Ex. 1013).
`7 US 7,203,829 B2, published Apr. 10, 2007 (Ex. 1014).
`8 We use prefixes “1335” and “1336” to denote papers from IPR2018-01335
`and IPR2018-01336, respectively. We do not use a prefix for papers from
`IPR2018-01334.
`
`
`
`3
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`B. Real Parties in Interest
`Petitioner identifies itself and Apple Inc. as real parties in interest.
`Pet. 2. Patent Owner identifies itself as the real party in interest. Paper 4, 2.
`C. The ’949 Patent and Illustrative Claim
`The ’949 patent generally relates to loading software from one
`processor to another in a multi-processor system. Ex. 1001, code (57). One
`example disclosed in the ’949 patent involves loading modem image
`executable data by first retrieving and processing an image header, which
`“includes information used to identify where the modem image executable
`data is to be eventually placed into the system memory of the secondary
`processor.” Ex. 1001, 8:9–21. Figure 3 of the ’949 patent is reproduced
`below.
`
`
`
`4
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`
`Figure 3 shows “operational flow for an exemplary loading process for
`loading an executable image from a primary processor to a secondary
`processor according to one aspect of the present disclosure.” Ex. 1001,
`4:10–13. Referring to various components depicted in Figure 3, the ’949
`patent discloses the following:
`The header information is used by the secondary processor 302
`to program the scatter loader/direct memory access controller
`304 receive address when receiving the actual executable data.
`Data segments are then sent from system memory 307 to the
`primary hardware transport mechanism 308. The segments are
`
`
`
`5
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`then sent from the hardware transport mechanism 308 of the
`primary processor 301 to a hardware transport mechanism 309
`of
`the
`secondary processor 302 over an
`inter-chip
`communication bus 310 (e.g., a HS-USB cable.) The first
`segment transferred may be the image header, which contains
`information used by the secondary processor to locate the data
`segments into target locations in the system memory of the
`secondary processor 305. The image header may include
`information used to determine the target location information for
`the data.
`Ex. 1001, 8:21–35.
`Claims 1, 10, 16, 18, 20, and 22 are independent claims. Claims 1,
`10, and 16 are reproduced below.
`
`1.
`
`A multi-processor system comprising:
`a secondary processor comprising:
`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.
`
`10. A method comprising:
`receiving at a secondary processor, from a primary
`processor via an inter-chip communication bus, an image header
`for an executable software image for the secondary processor
`6
`
`
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`that is stored in memory coupled to the primary processor, the
`executable software image comprising the image header and at
`least one data segment, the image header and each data segment
`being received separately;
`processing, by the secondary processor, the image header
`to determine at least one location within system memory to
`which the secondary processor is coupled to store each data
`segment;
`receiving at the secondary processor, from the primary
`processor via the inter-chip communication bus, each data
`segment; and
`scatter loading, by the secondary processor, each data
`segment [directly9] to the determined at least one location within
`the system memory, and each data segment being scatter loaded
`based at least in part on the processed image header.
`
`16. An apparatus comprising:
`means for receiving at a secondary processor, from a
`primary processor via an inter-chip communication bus, an
`image header for an executable software image for the secondary
`processor that is stored in memory coupled to the primary
`processor, the executable software image comprising the image
`header and at least one data segment, the image header and each
`data segment being received separately;
`means for processing, by the secondary processor, the
`image header to determine at least one location within system
`memory to which the secondary processor is coupled to store
`each data segment;
`means for receiving at the secondary processor, from the
`primary processor via the inter-chip communication bus, each
`data segment; and
`means for scatter loading, by the secondary processor,
`each data segment directly to the determined at least one location
`
`
`9 The issued patent recites “reedy,” which appears to be a printing error.
`The April 30, 2014 claim listing submitted by the applicants during
`prosecution states “directly.”
`
`
`
`7
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`within the system memory, and each data segment being scatter
`loaded based at least in part on the processed image header.
`
`II. ANALYSIS
`A. Level of Ordinary Skill in the Art
`Petitioner offers the following assessment as to the level of ordinary
`skill in the art:
`A person of ordinary skill in the art (POSITA) of the ’949
`patent would have had a Master’s degree in Electrical
`Engineering, Computer Engineering or Computer Science plus
`at least two years of experience in mobile device architecture and
`multi-processor systems, or a Bachelor’s degree in one of those
`fields plus at least four years of experience in mobile device
`architecture and multiprocessor systems.
`Pet. 16 (citing Ex. 1002 ¶ 74; Ex. 1007, 11–13). Patent Owner states that it
`“accepts Petitioner’s proposed education and experience level of one of
`ordinary skill in the art.” PO Resp. 21.
`We determine that the parties’ agreed level of skill in the art is
`appropriate in view of the evidence of record, with the exception of the
`language “at least,” which is vague because it expands the range indefinitely
`without an upper bound. Thus, we determine that a person of ordinary skill
`in the art would have had a Master’s degree in Electrical Engineering,
`Computer Engineering, or Computer Science plus two years of experience in
`mobile device architecture and multi-processor systems, or a Bachelor’s
`degree in one of those fields plus four years of experience in mobile device
`architecture and multiprocessor systems.
`B. Claim Interpretation
`In an inter partes review for a petition filed before November 13,
`2018, a claim in an unexpired patent shall be given its broadest reasonable
`
`
`
`8
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`construction in light of the Specification of the patent in which it appears.
`37 C.F.R. § 42.100(b) (2018); see Changes to the Claim Construction
`Standard for Interpreting Claims in Trial Proceedings Before the Patent Trial
`and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11, 2018) (amending
`37 C.F.R. § 42.100(b) effective November 13, 2018) (now codified at
`37 C.F.R. § 42.100(b) (2019)). The Petition was accorded a filing date of
`July 3, 2018, and, therefore, the broadest reasonable interpretation standard
`applies. See Paper 6 (Notice of Filing Date Accorded to Petition).
`In applying a broadest reasonable interpretation, claim terms generally
`are given their ordinary and customary meaning, as would be understood by
`one of ordinary skill in the art in the context of the entire disclosure. See In
`re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). This
`presumption may be rebutted when a patentee, acting as a lexicographer, sets
`forth an alternate definition of a term in the specification with reasonable
`clarity, deliberateness, and precision. In re Paulsen, 30 F.3d 1475, 1480
`(Fed. Cir. 1994). Furthermore, only terms that are in controversy need to be
`construed, and only to the extent necessary to resolve the controversy. See
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013,
`1017 (Fed. Cir. 2017) (citing Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795, 803 (Fed. Cir. 1999)).
`1. Image Header
`Petitioner argues the term “image header” means “a header associated
`with the entire image that specifies where the data segments are to be placed
`in the system memory.” Pet. 17 (citing Ex. 1001, 7:50–52, 8:18–21,
`9:23–24, 10:6, claim 10; Ex. 1008, 3; Ex. 1002 ¶ 77). When we instituted
`trial, we did not adopt Petitioner’s proposed construction as the broadest
`
`
`
`9
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`reasonable interpretation for reasons explained in the Decision on
`Institution, including that the proposed construction requires plural “data
`segments” while the claim recites “at least one data segment.” Dec. on
`Inst. 6–8. Nonetheless, “we determine[d] that Petitioner’s proposed
`construction falls within the broadest reasonable interpretation of ‘image
`header.’” Dec. on Inst. 6–8. Thus, we applied Petitioner’s proposed
`construction in determining whether the asserted prior art teaches the subject
`matter claimed. Dec. on Inst. 24–26.
`In its Response, Patent Owner agrees with Petitioner’s proposed
`construction. PO Resp. 12–13. Because the concerns with Petitioner’s
`proposed construction that we highlighted in the Decision on Institution do
`not impact our analysis in this Decision, we apply the parties’ agreed
`construction of “image header” as “a header associated with the entire image
`that specifies where the data segments are to be placed in the system
`memory.”
`
`2. Hardware Buffer
`The term “hardware buffer” appears in independent claim 1, and
`claims 2 and 8, which depend from claim 1, and in claim 12, which depends
`from independent claim 10. Claim 1 recites, in part, “a secondary processor
`comprising: system memory and a hardware buffer for receiving an image
`header and at least one data segment of an executable software image” 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.”
`Claim 12 recites, “The method of claim 10 further comprising loading the
`executable software image directly from a hardware buffer to the system
`
`
`
`10
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`memory of the secondary processor without copying data between system
`memory locations.”
`Although the Petition does not set forth an express construction for
`“hardware buffer,” Petitioner contends that the claimed “hardware buffer” is
`taught by the prior art’s (Svensson’s and Bauer’s) disclosure of a block of
`random access memory (RAM) that is reserved when needed to create an
`intermediate storage area for temporarily storing information being sent to
`system memory. Pet. 27 (citing Ex. 1009 ¶¶ 35–36, Fig. 2; Ex. 1010,
`3:54–58, 3:64–4:5, Fig. 1; Ex. 1002 ¶ 110); Pet. Reply. 34–35. In its
`Preliminary Response, Patent Owner argued that “[t]he ‘intermediate storage
`area’ in Svensson is a temporary buffer within system memory – it is not a
`‘hardware buffer’ as alleged by Petitioner.” Prelim. Resp. 34.
`In the Decision on Institution, we stated that, “[o]n the evidence
`before us, we are persuaded that Svensson and Bauer’s intermediate storage
`area teaches a ‘hardware buffer’” because “[t]he intermediate storage area of
`Bauer and Svensson is a buffer used to store data destined for another
`memory, and the intermediate storage area is in hardware inasmuch as
`SARAM and DARAM [of Bauer and Svensson] are hardware.” Dec. on
`Inst. 27.
`During the trial, Patent Owner maintains that the disclosure of a
`temporary buffer in RAM, such as in Bauer and Svensson, does not teach the
`claimed “hardware buffer.” PO Resp. 70–71. Patent Owner argues that the
`term “hardware buffer” means “a buffer within a hardware transport
`mechanism that receives data sent from the primary processor to the
`secondary processor.” PO Resp. 14. In its Reply, Petitioner argues that
`Patent Owner’s proposed construction should be rejected, and Petitioner
`
`
`
`11
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`argues that “the term ‘hardware buffer’ should be given its ordinary meaning
`of ‘a buffer implemented in hardware.’” Pet. Reply 8–11 (citing Ex. 1023
`¶ 25). In response, Patent Owner disputes Petitioner’s proposed
`construction, arguing that “a buffer cannot exist absent some piece of
`hardware, such that all buffers must ultimately be ‘implemented in
`hardware.’” PO Sur-reply 11. Patent Owner offers an alternative proposed
`construction in the following discussion:
`[T]o the extent the Board determines that Qualcomm’s proposed
`construction of “hardware buffer” is too narrow, Qualcomm
`alternatively proposes that the term be construed as “a buffer that
`is not allocated by the secondary processor.” In the ‘949 patent,
`the hardware buffer is a permanent buffer within the hardware
`transport mechanism (Ex. 1001 at 2:58-61, 8:24-30, Fig. 3; Ex.
`2007 at ¶¶69-71), in contrast to a temporary buffer in system
`memory that is allocated by the secondary processor at run time
`for this purpose (Ex. 1001 at 2:14-34; Ex. 2007 at ¶¶52-53).
`Qualcomm’s alternative construction of “hardware buffer”
`captures this distinction between the system memory and the
`hardware buffer, whereas Petitioner’s overly broad construction
`does not.
`PO Sur-reply 13.
`We begin our analysis with the claim language. Independent claim 1
`does not recite any particular configuration for the “hardware buffer.” As
`noted above, claim 1 recites, in part, “a secondary processor comprising:
`system memory and a hardware buffer for receiving an image header and at
`least one data segment of an executable software image” 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.” Thus,
`claim 1 recites that the hardware buffer is “for receiving an image header
`
`
`
`12
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`and at least one data segment of an executable software image,” but it does
`not define what implementation the hardware buffer must take or what type
`of storage device the hardware buffer is. Claim 1 separately recites a
`“system memory,” but that recitation of a separate system memory, by itself,
`does not foreclose the possibility of implementing a buffer in some other
`system memory.
`Turning next to the Specification of the ’949 patent, Figure 3 depicts a
`“Hardware Buffer” as part of the “Hardware Transport Mechanism” in each
`of the primary processor and the secondary processor. Ex. 1001, Fig. 3.
`Patent Owner relies on this disclosure in support of its proposed construction
`that a hardware buffer be “within a hardware transport mechanism.” PO
`Resp. 14–15. We find Patent Owner’s position problematic for two reasons.
`First, as Petitioner points out (Pet. Reply 10), the Specification of the ’949
`patent describes Figure 3 as “exemplary.” Ex. 1001, 4:10–13, 7:60–62; see
`also Ex. 1001, 4:22–25 (“The word ‘exemplary’ is used herein to mean
`‘serving as an example, instance, or illustration.’ Any aspect described
`herein as ‘exemplary’ is not necessarily to be construed as preferred or
`advantageous over other aspects.”). We are not persuaded that importing
`this limitation from the Specification into the claims is warranted under the
`broadest reasonable interpretation. See Phillips v. AWH Corp., 415 F.3d
`1303, 1323 (Fed. Cir. 2005) (en banc) (“[A]lthough the specification often
`describes very specific embodiments of the invention, we have repeatedly
`warned against confining the claims to those embodiments.”).
`Second, even if we were persuaded that adding the qualifier “within a
`hardware transport mechanism” were appropriate, that language does not
`provide a very helpful definition to a person of ordinary skill in the art. The
`
`
`
`13
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`’949 patent states that “[s]econdary processor 302 includes a hardware
`transport mechanism 309 (e.g., a USB controller).” Ex. 1001, 8:60–62; see
`also Ex. 1001, Fig. 3 (labeling box 309 as “Hardware Transport Mechanism
`(i.e. USB Controller)”). Thus, the ’949 patent gives an example of a
`hardware transport mechanism, but the ’949 patent does not indicate that the
`term “hardware transport mechanism” is limited to this example. See Tr.
`64:4–9 (Patent Owner’s counsel stating that “hardware transport
`mechanism” “refers to a broad variety of hardware”), 46:11–14 (Patent
`Owner’s counsel stating that “hardware transport mechanism” is “a generic
`term if you look at the specification. That’s a generic term for a USB
`controller, a PCIU controller. It’s some kind of serial bus controller that
`exists in both the secondary processor and the primary processor.”). Thus,
`the phrase “hardware transport mechanism” itself lacks the kind of
`specificity that would help a person of ordinary skill at the time of patenting
`understand the term “hardware buffer” or that would help us resolve the
`obviousness inquiry from the perspective of a person of ordinary skill in the
`art.
`
`As noted above, Petitioner asserts that the term “hardware buffer”
`means “a buffer implemented in hardware.” Pet. Reply 11 (citing Ex. 1023
`¶ 25). This proposed construction is similar to our preliminary
`determination at institution that Svensson and Bauer’s intermediate storage
`area teaches the claimed “hardware buffer” because the intermediate storage
`area is a buffer and it is in hardware. Dec. on Inst. 27. Having considered
`the full trial record, we agree with Patent Owner that Petitioner’s proposed
`construction and our preliminary determination fail to give meaning to the
`term “hardware.” In particular, Patent Owner correctly points out that “a
`
`
`
`14
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`buffer cannot exist absent some piece of hardware, such that all buffers must
`ultimately be ‘implemented in hardware.’” PO Sur-reply 11; see Merck &
`Co. v. Teva Pharms. USA, Inc., 395 F.3d 1364, 1372 (Fed. Cir. 2005) (“A
`claim construction that gives meaning to all the terms of the claim is
`preferred over one that does not do so.”).
`The written description of the ’949 patent, which uses the term
`“hardware buffer” only three times (Ex. 1001, 2:58–63, 9:37–41), does not
`provide much, if any, guidance on what a “hardware buffer” must be. As
`Patent Owner points out, however, the ’949 patent does differentiate
`disclosed loading techniques from known prior art techniques that use
`temporary buffers to receive data from a primary processor for loading. See
`PO Sur-reply 5–6. For example, the “Background” section of the ’949
`patent describes a conventional loading process as follows:
`In a system in [w]hich the software image is loaded onto a
`target “secondary” processor from a first “primary” processor,
`one way of performing such loading is to allocate a temporary
`buffer into which each packet is received, and each packet would
`have an associated packet header information along with the
`payload. The payload in this case would be the actual image
`data. From the temporary buffer, some of the processing may be
`done over the payload, and then the payload would get copied
`over to the final destination. The temporary buffer would be
`some place in system memory, such as in internal random-
`access-memory (RAM) or double data rate (DDR) memory, for
`example.
`Ex. 1001, 2:23–34 (emphasis added). The ’949 patent contrasts its
`disclosure with the prior art’s use of a temporary buffer, stating that “[i]n
`one exemplary aspect a direct scatter load technique is disclosed for loading
`a segmented image from a primary processor’s non-volatile memory to a
`secondary processor’s volatile memory. As discussed further below, the
`
`
`
`15
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`direct scatter load technique avoids use of a temporary buffer.” Ex. 1001,
`4:43–47. Furthermore, in describing a disclosed loading technique with
`reference to the exemplary device of Figure 1, the ’949 patent discloses that
`“[t]he modem processor 110 stores the modem executable image 132
`directly into the modem processor RAM (Random Access Memory) 112 to
`the final destination without copying the data into a temporary buffer in the
`modem processor RAM 112.” Ex. 1001, 5:31–35 (emphasis added).
`Patent Owner likens the ’949 patent’s distinction over using
`temporary buffers to the situation in SciMed Life Systems, Inc. v. Advanced
`Cardiovascular Systems, Inc., 242 F.3d 1337 (Fed. Cir. 2001).
`PO Sur-reply 5–6. In that case, the Court of Appeals for the Federal Circuit
`noted that the written description of the patents at issue described several
`disadvantages of certain prior art catheters. Id. at 1342–43. The court stated
`that
`
`the SciMed patents distinguish the prior art on the basis of the
`use of dual lumens and point out the advantages of the coaxial
`lumens used in the catheters that are the subjects of the SciMed
`patents. That discussion in the written description supports the
`district court’s conclusion that the claims should not be read so
`broadly as to encompass the distinguished prior art structure.
`Id. at 1343. We find this reasoning applicable to the claims that recite the
`use of a hardware buffer because those claims have affirmatively recited a
`distinct term—“hardware buffer”—to differentiate from prior art techniques
`described in the ’949 patent that use a “temporary buffer.” For those claims,
`therefore, we agree with Patent Owner that the ’949 patent distinguishes
`over prior art techniques that use a temporary buffer, based on the passages
`discussed above. Ex. 1001, 2:23–34, 4:43–47, 5:31–35.
`
`
`
`16
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`For the above reasons, we conclude that the “hardware buffer”
`limitations of independent claim 1 and its dependent claims (2–9) and
`dependent claim 12 “should not be read so broadly as to encompass” the use
`of a temporary buffer. See SciMed, 242 F.3d at 1343. No further
`interpretation of “hardware buffer” is necessary to resolve the obviousness
`inquiry before us. See Nidec, 868 F.3d at 1017.
`3. Means-Plus-Function Limitations
`The 1335 Petition sets forth proposed constructions for several
`limitations of independent claim 16 that Petitioner contends are means-plus-
`function limitations governed by 35 U.S.C. § 112, ¶ 6. IPR2018-01335
`Paper 3 (“1335 Pet.”), 17–22 (addressing “means for receiving . . . an image
`header,” “means for processing . . . the image header,” “means for receiving
`. . . each data segment,” and “means for scatter loading”). In the 1335
`Decision on Institution, we agreed with Petitioner that the identified
`limitations of claim 16 are means-plus-function limitations subject to
`35 U.S.C. § 112, ¶ 6, and we agreed with Petitioner’s identification of the
`claimed functions. 1335 Dec. on Inst. 13. We stated, however, that “we
`have questions as to the sufficiency of Petitioner’s identified structures,” and
`we discussed the “means for processing . . . the image header” and “means
`for scatter loading” limitations. 1335 Dec. on Inst. 13–15.
`In its Response, Patent Owner addresses the “means for
`processing . . . the image header” and “means for scatter loading” limitations
`and identifies the same corresponding structure identified in the 1335
`Petition. PO Resp. 18–21. Patent Owner also argues that “these terms do
`not need to be construed in order for the Board to reach its Final Written
`Decision” because “[n]one of the arguments Qualcomm makes below to
`
`
`
`17
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`distinguish the prior art requires construction of these limitations.” PO
`Resp. 17. In its Reply, Petitioner states that, “[u]pon consideration of the
`Board’s articulated concerns, Petitioner agrees that the ’949 specification
`fails to disclose sufficient structure to perform the recited functions.” Pet.
`Reply 14. Petitioner, however, also agrees with Patent Owner’s position that
`we still “can address in this proceeding whether claim 16 is invalid in view
`of the asserted prior art.” Pet. Reply 14 (citing PO Resp. 17).
`Under our Rules, for a means-plus-function limitation, a petition
`“must identify the specific portions of the specification that describe the
`structure, material, or acts corresponding to each claimed function.”
`37 C.F.R. § 42.104(b). Therefore, it is Petitioner’s burden to identify
`corresponding structure. Because Petitioner asserts during the trial that the
`Specification of the ’949 patent fails to disclose sufficient corresponding
`structure for the “means for processing . . . the image header” and “means
`for scatter loading” limitations (Pet. Reply 14), Petitioner has not met this
`burden. Furthermore, in the absence of the requisite showing by Petitioner
`of sufficient corresponding structure for the means-plus-function limitations,
`we need not further address the construction of these claim terms to
`determine whether Petitioner has met its burden to prove, by a
`preponderance of the evidence, unpatentability of independent claim 16 and
`dependent claim 17.
`
`C. Principles of Law
`A patent claim is unpatentable under 35 U.S.C. § 103(a) if the
`differences between the claimed subject matter and the prior art are such that
`the subject matter, as a whole, would have been obvious at the time the
`invention was made to a person having ordinary skill in the art to which said
`
`
`
`18
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`subject matter pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406
`(2007). The question of obviousness is resolved on the basis of underlying
`factual determinations including (1) the scope and content of the prior art;
`(2) any differences between the claimed subject matter and the prior art;
`(3) the level of ordinary skill in the art; and (4) any secondary
`considerations, if in evidence.10 Graham v. John Deere Co., 383 U.S. 1,
`17–18 (1966).
`D. Obviousness over Bauer, Svensson, and Kim
`(Claims 1–15, 22, 23)
`Petitioner contends claims 1–15, 22, and 23 of the ’949 patent are
`unpatentable under 35 U.S.C. § 103(a) as obvious over the combined
`teachings of Bauer, Svensson, and Kim. Pet. 23–75; 1335 Pet. 29–67.
`1. Svensson
`Svensson describes a multi-processor system in which data are sent
`from a host processor to a client processor. Ex. 1010, code (57). Figure 1 of
`Svensson is reproduced below.
`
`
`10 Patent Owner does not present any objective evidence of nonobviousness
`(i.e., secondary considerations) as to any of the challenged claims.
`19
`
`
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`
`
`Figure 1 depicts multi-processor system 100 having host processor 102 and
`client processor 104. Ex. 1010, 3:49–50. Client processor 104 is the
`processor for a digital signal processor (DSP) device. Ex. 1010, 3:54–58.
`As Svensson explains, “[m]ost commercially available DSP devices include
`on-chip memories, and as indicated in FIG. 1, the DSP includes ‘internal’
`single-access RAM (SARAM) and dual-access RAM (DARAM) 108, as
`well as an ‘external’ RAM (XRAM) 110.” Ex. 1010, 3:64–4:1. Svensson
`explains that “XRAM 110 is invisible to, i.e., not accessible by, the CPU
`102,” whereas CPU 102 can access “internal” SARAM and DARAM 108.
`Ex. 1010, 4:5–8, 4:13–14. DSP processor 104 can access both RAMs 108
`and 110. Ex. 1010, 4:7–8.
`Because host processor 102 cannot access XRAM 110, Svensson
`discloses a technique for sending data from host processor 102 to be stored
`in XRAM 110. Ex. 1010, Fig. 2, 4:15–6:11, 7:7–8. Svensson’s Figure 2 is
`reproduced below.
`
`
`
`20
`
`
`
`IPR2018-01334
`Patent 8,838,949 B2
`
`
`
`Figure 2 is a flow chart of Svensson’s bootloader operation. Ex. 1010, 3:34,
`4:15–19. In step 212, a block of memory in “internal” memory 108 is
`reserved as an intermediate storage area (ISA) for data that are being sent
`from the host to the invisible memory of the client processor. Ex. 1010,
`5:21–28. After the host transfers data to the ISA (step 216), the host tells the
`client the ISA has been loaded and indicates whether more data are coming
`(step 218). Ex. 1010, 5:53–63. The client then copies the data from the ISA
`to its “invisible” memory (s