throbber
Paper 13
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket