Express Mobile, Inc. v. Meta Platforms, Inc., No. 24-1190 (Fed. Cir. Dec. 8, 2025)

DYK, Circuit Judge.

Express Mobile, Inc. (“Express Mobile”) appeals three final written decisions by the Patent Trial and Appeal Board (“Board”) determining that all challenged claims of U.S. Patent Nos. 9,063,755 (“’755 patent”), 9,471,287 (“’287 patent”), and 9,928,044 (“’044 patent”) are unpatentable as obvious. We affirm.

3BACKGROUND

The challenged patents relate to systems for generating code to provide content on a display of a device. The patents derive from the same parent application and have a common specification in all relevant respects.

Generally, the systems allow for efficient programming on a large number of types of devices. One claimed aspect of the systems is a “player,” which provides “device- or device-platform specific instructions for . . . the device.” ’755 patent, col. 5 ll. 10–12.¹ “[T]he Player transforms device-independent instructions of the Application into device-specific instructions that are executable by the device,” which allows the device to present the content of the Application. ’755 patent, col. 5 ll. 57–59.

Claim 1 of the ’755 patent, which is representative, recites:

A system for generating code to provide content on a display of a device, said system comprising:

computer memory storing a registry of:

a) symbolic names required for

evoking one or more web components each related to a set of inputs and outputs of a web service obtainable over a network, where the symbolic names are character strings that do not contain either a persistent address or pointer to an output value accessible to the web service, and

4b) the address of the web service;

an authoring tool configured to: define a user interface (UI) object for presentation on the display, where said UI object corresponds to the web component included in said registry selected from the group consisting of an input of the web service and an output of the web service, access said computer memory to select the symbolic name corresponding to the web component of the defined UI object, associate the selected symbolic name with the defined UI object, produce an Application including the selected symbolic name of the defined UI object, where said Application is a device-independent code, and produce a Player, where said Player is a device-dependent code; such that, when the Application and Player are provided to the device and executed on the device, and when a user of the device provides one or more input values associated with an input symbolic name to an input of defined UI object, 1) the device provides the user provided

one or more input values and corresponding input symbolic name to the web service,

2) the web service utilizes the input sym-

bolic name and the user provided one or more input values for generating one or

5more output values having an associated output symbolic name,

3) said Player receives the output symbolic

name and corresponding one or more output values and provides instructions for a display of the device to present an output value in the defined UI object.

’755 patent, claim 1 (emphases added).

Meta Platforms, Inc. (“Meta”) petitioned for inter partes review (IPR) of claims 1–2, 5–7, and 11 of the ’755 patent, claims 1–2, 5–7, and 11–12 of the ’287 patent, and claims 1–2, 5–7, and 11–12 of the ’044 patent, alleging each was unpatentable as obvious. In each petition, Meta relied on prior art combinations that used a Java Virtual Machine (“JVM”) to satisfy the “player” limitation. Meta argued the JVM disclosed the device-specific “player” limitation because, quoting the prior art, “‘JVMs are written for each operating system. In this way it is the JVM which is linked to the operating system, and handles all of the platform-specific details, while the source code you write for interpretation is platform independent.’” E.g., J.A. 538 (emphasis omitted) (quoting J.A. 1361).² In other words, in the language of the ’755 patent specification, it “transforms device independent instructions . . . into device-specific instructions that are executable by the device.” ’755 patent, col. 5 ll. 57–59.

The Board instituted review on each challenged claim. The Board ultimately determined each challenged claim was unpatentable as obvious over the prior art combinations, finding the JVM satisfied the player limitation.

6DISCUSSION

Express Mobile primarily argues that the Board erred when it failed to construe the claim term “player” to exclude virtual machines such as the JVM. The Board held that Express Mobile forfeited this argument because, as it conceded, it raised the argument “in its Sur-reply and at the hearing,” J.A. 5143, and not in the patent owner response. We do not address the forfeiture issue because we conclude that the Board did not err in determining that the term “player” can include JVMs.

First, as the Board determined, while the specification discloses one embodiment (Figure 2B) where the “player” and virtual machine are identified as separate elements, the specification “describes how ‘the Application may include Java programming for generating a display on Screen 137,’ and that ‘the Player may interpret the Java and instruct processor 135 to produce the display according to the Application.’” J.A. 42 (quoting ’755 patent, col. 5 ll. 60–61). As the petitions argue, the JVM’s purpose is to interpret and execute Java. The Board did not err in finding that these disclosures “strongly suggest[ed] that the Player could be a JVM, or at least software with very similar capabilities.” J.A. 42.³

Express Mobiles argues that this interpretation is inconsistent with the prosecution history. During initial examination, Express Mobile argued in reply to an office action that the “player” may “interpret non-binary, device-independent [code] contained in the Application.” J.A. 2414 (alteration in original) (quoting J.A. 4243).7 Express Mobile argued that this shows that a JVM cannot be the “player.” The theory is that this is so because a JVM only executes Java bytecode which, according to Express Mobile’s expert, is binary code. J.A. 2414 (citing J.A. 2480). The Board disagreed, finding “Java bytecode is not ‘binary code,’ at least as that term is used in its most strict sense, because Java ‘[b]yte code is a set of instructions that is interpreted within a Java Runtime Environment (JRE),’” not “low level, machine specific code.” J.A. 43 (alteration in original) (quoting J.A. 1361). The Board’s findings are supported by substantial evidence. We conclude that the Board did not err in concluding that a JVM may function as the claimed “player.”

Express Mobile also argues the Board erred in concluding the prior art combinations disclosed the “provides instructions” limitation because it “failed to identify the claimed ‘instructions’” provided by the JVM. Appellant’s Br. 47 (quoting J.A. 54). As Express Mobile did not argue in its patent owner responses that Meta incorrectly identified the “instructions” in its petitions, this argument is forfeited. Even if the argument were not forfeited, it is without merit.

Express Mobile’s theory is that an ordinarily skilled artisan would not conclude that the JVM provides instructions “because it causes a different component—the servlet—to generate a webpage, which causes yet another component—the web server—to provide the webpage to the browser.” Appellant’s Br. 51 (emphasis omitted). The Board agreed with Meta that “nothing in the challenged claims requires that the Player itself directly present or physically draw the user interface for the user; the claim requires only that the Player provide ‘instructions’ for such display.” J.A. 54 (citing J.A. 4291–92). As a result, the Board found that the JVM satisfied this limitation because it “carries out the function of the Java application, resulting in instructions that cause display of the user interface8 on the web browser.” Id. These factual findings are supported by substantial evidence.

Finally, Express Mobile argues the Board applied an erroneous claim construction to the “produce a player” limitation, and how under its construction, the Board’s conclusion that the prior art combination disclosed this limitation is not supported by substantial evidence. But Express Mobile did not argue for a claim construction of “produce” before the Board, and the Board found that Express Mobile “[did] not offer, or support, a narrowing construction” of this term. J.A. 44–45. The Board also determined that under the plain and ordinary meaning of produce, the prior art combination satisfied this limitation. We see no error as to the Board’s determinations.

CONCLUSION

We have considered Express Mobile’s remaining arguments and find them unpersuasive. We affirm.

AFFIRMED.

COSTS

Costs to Meta.