Intel Corp. v. Qualcomm Inc.

• Decision Date: 28 December 2021
• Docket Number: 2020-1828, 2020-1867
• Citation: 21 F.4th 801
• Parties: INTEL CORPORATION, Appellant v. QUALCOMM INCORPORATED, Cross-Appellant
• Court: U.S. Court of Appeals — Federal Circuit

21 F.4th 801

INTEL CORPORATION, Appellant

v.QUALCOMM INCORPORATED, Cross-Appellant

2020-1828, 2020-1867

United States Court of Appeals, Federal Circuit.

Decided: December 28, 2021

Thomas Saunders, Wilmer Cutler Pickering Hale and Dorr LLP, Washington, DC, argued for appellant. Also represented by David Langdon Cavanaugh, Claire Hyungyo Chung; Joseph F. Haag, Palo Alto, CA.

Jennifer L. Swize, Jones Day, Washington, DC, argued for cross-appellant. Also represented by Robert Breetz, David B. Cochran, David Michael Maiorana, Joseph M. Sauer, Cleveland, OH; Kelly Holt, New York, NY; Matthew Johnson, Joshua R. Nightingale, Pittsburgh, PA; Israel Sasha Mayergoyz, Chicago, IL.

Before Prost, Taranto, and Hughes, Circuit Judges.

Taranto, Circuit Judge Qualcomm Inc. owns U.S. Patent No. 8,838,949, which addresses multi-processor systems in which software stored in non-volatile memory coupled to a first processor is to be used by a second processor. The patent describes and claims systems, methods, and apparatuses for efficiently retrieving an executable software image from the first processor's non-volatile memory and loading it for use by the second processor. Intel Corp. challenged all claims of the '949 patent as unpatentable for obviousness in three inter partes reviews (IPRs) before the Patent and Trade-mark Office. The Office's Patent Trial and Appeal Board consolidated the proceedings and issued a final written decision holding that Intel had proved unpatentable claims 10, 11, 13–15, and 18–23, but not claims 1–9, 12, 16, and 17. Intel Corp. v. Qualcomm Inc., IPR2018-01334, 2020 WL 1286306, at *27 (P.T.A.B. Mar. 16, 2020) ( Final Written Decision ). Intel appeals.

We hold first that Intel has adequately demonstrated Article III standing to press this appeal. On the merits, we hold that in the decision before us, the Board failed to tie its construction of the phrase "hardware buffer" to the actual invention described in the specification. For that reason, we vacate the Board's decision as to claims 1–9 and 12 and remand for a new construction. As to claims 16 and 17, which are in means-plus-function format, we also vacate and remand. We conclude that the Board failed to determine for itself whether there is sufficient corresponding structure in the specification to support those claims and whether it can resolve the patentability challenges despite the (potential) indefiniteness of those claims.

I

A

The patent addresses a system with multiple processors, each of which must execute its own "boot code" to play its operational role in the system. Such code must be stored in non-volatile memory (e.g. , flash memory or read-only memory), since volatile memory is cleared when the device powers down; and the boot code generally must be transferred to its corresponding processor's volatile memory in order to be executed by that processor. '949 patent, col. 1, lines 39–41. In a multi-processor system, one possible design choice is to store the boot code for each processor in its own separate non-volatile memory. Another choice, to avoid the costs of multiple memories each adequate for such storage, is to store the boot code for one processor in the non-volatile memory of another processor, permitting elimination or shrinkage of the non-volatile memory of the first processor. Id. , col. 1, line 60, through col. 2, line 14.

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," assumes the latter, shared-storage choice. It addresses the problem, inherent in that choice, of loading the boot code for a "secondary" processor (into its volatile memory) from the non-volatile memory of a "primary" processor. Id. , col. 2, line 58, through col. 3, line 2. It uses a "direct scatter load" procedure to do so. "Scatter loading" refers to moving a "binary multi-segmented" software image into scattered parts (as opposed to one contiguous block) of the secondary processor's "system memory" before executing it. Id. , col. 2, lines 14–22. The patent discloses a "direct" scatter loading process, through which the segments of the software image are transmitted "directly" from a "hardware buffer" to their final locations in the secondary processor's "system memory." Id. , col. 2, lines 58–63.

Claims 1 and 2 are representative for the claim-construction issue on appeal. They recite:

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.¹

2. The multi-processor system of claim 1 in which the scatter loader controller is configured to load the executable software image directly from the hardware buffer to the system memory of the secondary processor without copying data between system memory locations on the secondary processor .

Id. , col. 12, line 60, through col. 13, line 16 (emphases added).

Claim 16 is relevant to the means-plus-function issue on appeal. It recites:

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 within the system memory, and each data segment being scatter loaded based at least in part on the processed image header.

Id. , col. 14, lines 17–37 (emphases added).

B

In 2017, Qualcomm initiated actions against Apple Inc. (not party to this appeal) in district court and at the International Trade Commission (ITC), alleging that Apple infringed the '949 patent (and other patents) by making, selling, and using iPhone models that incorporated baseband processors made by Intel. See J.A. 6233. Qualcomm's infringement theory identified the Intel baseband processors as the "secondary processors" of the '949 patent and pointed to "Intel design documents that describe how the Intel baseband processors are integrated into the iPhones." See J.A. 6262, 6264. In 2019, Qualcomm and Apple settled all litigation worldwide between the two companies, and Qualcomm agreed to license the patents to Apple for six years (and two additional years if Apple wished). J.A. 6084, 6210. Later in 2019, Apple acquired "the majority of Intel's smartphone modem business" (including its production of baseband processors), J.A. 6088, though Intel continues to supply pre-acquisition versions of its baseband processors to Apple and another customer, J.A. 6204.

Meanwhile, in 2018, Intel petitioned the Board for three inter partes reviews, each petition covering various claims of the '949 patent and together covering all. After consolidating the reviews, the Board issued a final written decision. The Board ruled that Intel had proved the unpatentability of claims 10, 11, 13–15, and 18–23, but Qualcomm, despite filing a cross-appeal to raise the issue, no longer challenges that ruling. The Board also ruled that Intel had failed to prove the unpatentability of the remaining claims: (a) independent claim 1 and its dependent claims 2–9, plus claim 12 (depending on independent claim 10); and (b) independent claim 16 and its dependent claim 17. See Final Written Decision , at *27. Intel appeals those losses.

The Board's determination upholding claims 1–9 and 12 turned on the construction of the claim phrase "hardware buffer." No party put forward an explicit construction of that term until Qualcomm's patent owner response, in which Qualcomm proposed to construe the phrase to mean "a buffer within a hardware transport mechanism that receives data sent from the primary processor to the secondary processor." J.A. 4224. In reply, Intel argued that " ‘hardware buffer’ should be given its ordinary meaning of ‘a buffer implemented in hardware.’ " J.A. 4322. In surreply, Qualcomm defended its proposed construction but also advanced an alternative construction, "a buffer that is not allocated by the secondary processor." J.A. 4397. Qualcomm explained: "In the '949 patent, the hardware buffer is a permanent buffer within the hardware transport mechanism, in contrast to a temporary buffer in system memory that is allocated by the secondary processor at run time for this purpose." Id. (cleaned up).

The Board rejected both Qualcomm's original construction, which referred to "a hardware transport mechanism," and Intel's "ordinary meaning" construction, "a buffer implemented in hardware." Final Written Decision , at *5–6. Instead, the Board agreed with Qualcomm that "the '949 patent does differentiate disclosed loading techniques from known prior art techniques that use temporary buffers" and concluded that "the ‘hardware buffer’ limitations ... ‘should not...