NOTE: This disposition is nonprecedential. United States Court of Appeals
for the Federal Circuit
RFCYBER CORP.,
Appellant
v.
COKE MORGAN STEWART, ACTING UNDER
SECRETARY OF COMMERCE FOR
INTELLECTUAL PROPERTY AND ACTING
DIRECTOR OF THE UNITED STATES PATENT
AND TRADEMARK OFFICE,
Intervenor
2023-2418
Appeal from the United States Patent and Trademark Office, Patent Trial and Appeal Board in No. IPR2022-00413.
Decided: August 14, 2025
RICHARD MATTHEW COWELL, Fabricant LLP, Rye, NY, argued for appellant. Also represented by ALFRED ROSS FABRICANT, PETER LAMBRIANAKOS, VINCENT J. RUBINO, III. MICHAEL S. FORMAN, Office of the Solicitor, United States Patent and Trademark Office, Alexandria, VA,
2argued for intervenor. Also represented by PETER J. AYERS, AMY J. NELSON, FARHEENA YASMEEN RASHEED, SHEHLA WYNNE.
Before PROST, REYNA, and CHEN, Circuit Judges.
RFCyber Corp. (RFCyber) appeals the final written decision of the Patent Trial and Appeal Board (Board) finding all claims of U.S. Patent No. 9,240,009 (’009 patent) unpatentable under 35 U.S.C. § 103 based on grounds asserted in an inter partes review petition filed by Apple Inc. (Apple). Apple Inc. v. RFCyber Corp., No. IPR2022-00413, 2023 WL 5167264 (P.T.A.B. July 18, 2023) (Decision). We have jurisdiction under 28 U.S.C. § 1295(a)(4)(A). We affirm.
Claim 1 is representative. It recites, in relevant part, a server “configured to prepare data necessary for the application to function as designed on the mobile device.” ’009 patent at claim 1. The Board found that Dua1 teaches this limitation. RFCyber argues that the Board implicitly construed “prepare data” too broadly, and that substantial evidence does not support the Board’s findings.
RFCyber contends that the Board implicitly adopted an overbroad interpretation by treating a server’s transmission of data as satisfying “prepare data.” RFCyber also asserts that, in light of the specification, “prepare data” requires an active role in generating or computing the necessary data, which Dua does not disclose. We disagree in both respects.
Nothing in the specification limits “prepare data” to active generation. The specification states that “there are at3 least two different ways to prepare the data,” ’009 patent col. 13 ll. 19–21 (emphasis added), and describes two exemplary modes: requesting or generating application keys. Id. col. 13 ll. 22–34. To the extent that these embodiments both involve “active” steps, these examples do not limit the claims. See Hill-Rom Servs., Inc. v. Stryker Corp., 755 F. 3d 1367, 1371 (Fed. Cir. 2014) (“While we read claims in view of the specification, of which they are a part, we do not read limitations from the embodiments in the specification into the claims.”).
Even under RFCyber’s narrower construction, substantial evidence supports the Board’s findings. The Board found that Dua discloses a server that “prepare[s] data” because Dua describes a server that has “the ability to make edits in order to ensure proper formatting” of a user’s mobile phone number before transmission. J.A. 997, ¶¶ 62– 63; see Decision, 2023 WL 5167264, at *12. It was reasonable for the Board to conclude that such formatting constitutes preparation of “data necessary for the application to function as designed on the mobile device,” as Dua describes that proper formatting is required before confidential information can be transmitted to the mobile device. See J.A. 997, ¶ 62.
The Board also reasonably found that Dua’s description of transmitting data taught the “prepare data” limitation. The Board relied, in part, on Dua’s disclosures that describe transmitting personalization data—including encryption keys and authentication information—from the server to the wallet application in payloads. Decision, 2023 WL 5167264, at *12; J.A. 996 ¶ 57; J.A. 1006, ¶ 215. The Board further relied on expert testimony explaining that the server prepares this data by packaging it into payloads for transmission. Decision, 2023 WL 5167264, at *12; J.A. 914–15, ¶ 147. Accordingly, the Board reasonably found that Dua discloses the “prepare data” limitation.
4We have considered RFCyber’s remaining arguments and find them unpersuasive. For the foregoing reasons, we affirm.