throbber
Case: 21-1355 Document: 43 Page: 1 Filed: 09/08/2022
`
`NOTE: This disposition is nonprecedential.
`
`United States Court of Appeals
`for the Federal Circuit
`______________________
`
`APPLE INC.,
`Appellant
`
`v.
`
`MPH TECHNOLOGIES OY,
`Appellee
`______________________
`
`2021-1355, 2021-1356
`______________________
`
`Appeals from the United States Patent and Trademark
`Office, Patent Trial and Appeal Board in Nos. IPR2019-
`00819, IPR2019-00820.
`______________________
`
`Decided: September 8, 2022
`______________________
`
`BRIAN ROBERT MATSUI, Morrison & Foerster LLP,
`Washington, DC, argued for appellant. Also represented
`by SETH W. LLOYD, JOSEPH R. PALMORE; RICHARD HUNG,
`San Francisco, CA; BITA RAHEBI, Los Angeles, CA.
`
` BRIAN ERIK HAAN, Lee Sheikh & Haan LLC, Chicago,
`IL, argued for appellee. Also represented by ASHLEY E.
`LAVALLEY, CHRISTOPHER LEE; JAMES CARMICHAEL,
`STEPHEN TERRY SCHREINER, Carmichael IP, PLLC, Tysons
`Corner, VA.
`
`

`

`Case: 21-1355 Document: 43 Page: 2 Filed: 09/08/2022
`
`2
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
` ______________________
`
`Before LOURIE, HUGHES, and CUNNINGHAM, Circuit
`Judges.
`CUNNINGHAM, Circuit Judge.
`Apple Inc. appeals the final written decisions issued in
`two Patent Trial and Appeal Board inter partes reviews
`concerning U.S. Patent No. 7,620,810 and U.S. Patent No.
`7,937,581 (collectively, the “Challenged Patents”), both
`owned by MPH Technologies Oy. Apple Inc. v. MPH Techs.
`Oy, IPR2019-00819, 2020 WL 5735595 (P.T.A.B. Sept. 24,
`2020) (Decision I); Apple Inc. v. MPH Techs. Oy, IPR2019-
`00820, 2020 WL 5735601 (P.T.A.B. Sept. 24, 2020) (Deci-
`sion II). Because the Board adopted an erroneous claim
`construction of “encrypted” messages in both decisions, we
`vacate the Board’s unpatentability determinations based
`on that construction and remand for further consideration.
`Because we further hold that the Board properly found that
`Apple’s petition failed to demonstrate the unpatentability
`of dependent claims 6–8 of the ’581 patent, we affirm as to
`those claims.
`
`I. BACKGROUND
`A. The Challenged Patents
`The Challenged Patents are both entitled “Method and
`Network for Ensuring Secure Forwarding of Messages.”
`They share a specification in all aspects relevant to this ap-
`peal. Each is directed to a method of facilitating a secure
`connection in a telecommunication network. See, e.g., ’810
`Patent Abstract; ’581 Patent Abstract. Each describes the
`prior art IP security protocols (“IPSec”) as “provid[ing] the
`capability to secure communications between arbitrary
`hosts.” ’810 Patent, col. 1 ll. 57–58; ’581 Patent, col. 1 ll.
`59– 60. The patents explain that “IPSec is intended to work
`with static network topology, where hosts are fixed to cer-
`tain subnetworks” and can be “problematic” if used with
`
`

`

`Case: 21-1355 Document: 43 Page: 3 Filed: 09/08/2022
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`3
`
`mobile hosts. ’810 Patent, col. 4 ll. 10–54; ’581 Patent, col.
`4 ll. 13–65.
`The ’810 patent has seven claims. Claim 1 requires:
`1. A method for ensuring secure forwarding of a
`message in a telecommunication network, hav-
`ing at least one mobile terminal and another ter-
`minal and a security gateway therebetween, the
`method comprising:
`a) establishing a secure connection be-
`tween a first address of the mobile terminal
`and an address of the security gateway, the
`secure connection defined by at least the
`addresses of the mobile terminal and the
`security gateway,
`b) the mobile terminal changing from the
`first address to a second address,
`c) while at the second address, the mobile
`terminal sending a request message to the
`address of the security gateway to request
`the security gateway to change the secure
`connection to be defined between the sec-
`ond address and the address of the security
`gateway,
`in response to the request message from
`the mobile terminal, the security gateway
`changing an address definition of the se-
`cure connection from the first address to
`the second address, the mobile terminal
`sending a secure message in the secure con-
`nection from the second address of the mo-
`bile terminal to the other terminal via the
`security gateway,
`the secure connection being established by
`forming a Security Association (SA) using
`
`

`

`Case: 21-1355 Document: 43 Page: 4 Filed: 09/08/2022
`
`4
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`IPSec protocols, and the request message
`and/or a reply message being encrypted
`and/or authenticated by using the same SA
`already established.
`’810 Patent, col. 10 l. 48–col. 11 l. 8 (emphasis added).
`Claim 7, the ’810 patent’s only other independent claim, is
`similar to claim 1 but does not require a “request message
`and/or a reply message being encrypted and/or authenti-
`cated.” Id. col. 12 ll. 1–22.
`The ’581 patent is a continuation of the ’810 patent. It
`includes nine claims, several of which are at issue in this
`appeal. Claim 1 of the ’581 patent requires:
`1. A method for ensuring secure forwarding of a
`message in a telecommunication network, hav-
`ing at least one mobile terminal and another ter-
`minal and a security gateway therebetween, the
`method comprising:
`a) establishing a secure connection having
`a first address of the mobile terminal as a
`first end-point and a gateway address of
`the security gateway as a second end-point,
`b) the mobile terminal changing from the
`first address to a second address,
`c) while at the second address, the mobile
`terminal sending a request message to the
`gateway address of the security gateway to
`request the security gateway to change the
`secure connection to be defined between
`the second address and the gateway ad-
`dress of the security gateway,
`in response to the request message from
`the mobile terminal, the security gateway
`changing an address definition of the
`
`

`

`Case: 21-1355 Document: 43 Page: 5 Filed: 09/08/2022
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`5
`
`secure connection from the first address to
`the second address, and
`the mobile terminal sending a secure mes-
`sage in the secure connection from the sec-
`ond address of the mobile terminal to the
`other terminal via the security gateway.
`’581 Patent, col. 10 l. 50–col. 11 l. 3. Relevant here, claim 4
`further requires an “encrypted and/or authenticated” re-
`quest or reply message, and dependent claims 5–8 add ad-
`ditional limitations to claims 1 and 5:
`4. The method of claim 1, wherein the request mes-
`sage and/or a reply message is encrypted and/or
`authenticated.
`5. The method of claim 1 wherein the method fur-
`ther comprises the security gateway sending
`back a reply message to the mobile terminal at
`the second address to confirm the address
`change.
`6. The method of claim 5, wherein the mobile termi-
`nal and the other terminal form an end-to-end
`connection whereby the secure connection is an
`IPSec transport connection or IPSec tunnel con-
`nection.
`7. The method of claim 5, wherein a tunneling pro-
`tocol is used for the secure connection between
`the mobile terminal and the security gateway.
`8. The method of claim 5, wherein the other termi-
`nal is a mobile terminal.
`Id. col. 11 ll. 9– 23 (emphasis added).
`B. Procedural History
`In 2018, MPH sued Apple for infringement of eight pa-
`tents in the Northern District of California. MPH Techs.
`Oy v. Apple Inc., No. 4:18-cv-05935-PJH (N.D. Cal.); J.A. 3.
`
`

`

`Case: 21-1355 Document: 43 Page: 6 Filed: 09/08/2022
`
`6
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`Apple then filed multiple IPR petitions, two of which are at
`issue in this appeal. J.A. 154–229, 3258–329.
`For IPR 2019-00819, the Board instituted review of the
`’810 patent on three grounds, each based on obviousness
`under 35 U.S.C. § 103(a).1 Decision I at *3. Ground 1 chal-
`lenged claims 1, 4–5, and 7 based on U.S. Patent No.
`6,904,466 to Ishiyama et al. (“Ishiyama”) and U.S. Patent
`No. 7,028,337 to Murakawa (“Murakawa”). Id. Ground 2
`challenged claims 2 and 3 based on Ishiyama, Murakawa,
`and U.S. Patent No. 6,976,177 to Ahonen (“Ahonen”). Id.
`Ground 3 challenged claim 6 based on Ishiyama, Mura-
`kawa, and U.S. Patent No. 6,954,790 to Forslöw (“For-
`slöw”). Id.
`For IPR 2019-00820, the Board instituted IPR as to the
`’581 patent on three grounds. Decision II at *3. Ground 1
`challenged claims 1–2, 4, 6–7, and 9 based on Ishiyama and
`Murakawa. Id. Ground 2 challenged claims 3 and 5 based
`on Ishiyama, Murakawa, and Ahonen. Id. Ground 3 chal-
`lenged claim 8 based on Ishiyama, Murakawa, and For-
`slöw. Id.
`In IPR 2019-00819, the Board agreed with Apple that
`Ishiyama and Murakawa rendered unpatentable claim 7 of
`the ’810 patent. Decision I at *22. In IPR 2019-00820, the
`Board agreed that Ishiyama and Murakawa rendered un-
`patentable claims 1, 2, and 9 of the ’581 patent, and that
`Ishiyama, Murakawa, and Ahonen rendered unpatentable
`claims 3 and 5 of the ’581 patent. Decision II at *27.
`
`
`1 Congress amended § 103. See Leahy-Smith Amer-
`ica Invents Act, Pub. L. No. 112-29, § 3(c), 125 Stat. 284,
`287–88 (2011) (“AIA”). Because the applications that led
`to the Challenged Patents were filed before March 16,
`2013, the pre-AIA § 103(a) applies. See AIA § 3(n), 125
`Stat. at 293.
`
`

`

`Case: 21-1355 Document: 43 Page: 7 Filed: 09/08/2022
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`7
`
`Relevant to this appeal, the Board’s interpretation of an
`“encrypted” request and/or reply message led it to conclude
`that Apple failed to demonstrate that claims 1–6 of the ’810
`patent and claim 4 of the ’581 patent would have been ob-
`vious. Decision I at *8, 22; Decision II at *18–20. In its
`petitions, Apple argued that all terms should receive their
`ordinary and customary meaning. J.A. 169, 3273. MPH
`proposed a construction of “security gateway,” but the
`Board did not base its decision on that claim term. Decision
`I at *4–5; Decision II at *4. Thus, the Board determined
`that “no express claim construction [was] necessary.” De-
`cision I at *5; Decision II at *4. The Board then interpreted
`the “plain words” of “request message and/or a reply mes-
`sage being encrypted” to require “that the message is en-
`crypted—not that a portion of the message is encrypted.”
`Decision I at *8; Decision II at *19. Based on its interpre-
`tation, the Board concluded that Ishiyama could not meet
`this limitation because its request message “includ[ed] the
`outer packet, and that packet is unencrypted.” Decision I
`at *8–9; Decision II at *18–19.
`The Board also concluded that Apple failed to meet its
`burden as to claims 6–8 of the ’581 patent because Grounds
`1 and 3 in IPR 2019-00820 did not address the intervening
`limitations of claim 5, from which claims 6–8 depend. De-
`cision II at *20, 27. The Board accepted that the combina-
`tion of Ishiyama and Murakawa rendered claim 1 of the
`’581 patent obvious. Id. at *6, 11. The Board further ac-
`cepted that adding Ahonen to that combination taught the
`additional limitation of dependent claim 5, i.e., “the secu-
`rity gateway sending back a reply message to the mobile
`terminal at the second address to confirm the address
`change.” Id. at *26–27. Because Apple did not include Aho-
`nen in Ground 1 addressing claims 6 and 7 or Ground 3
`addressing claim 8, the Board held that Apple did not carry
`its burden as to those claims. Id. at *20, 27.
`Apple timely appealed. We have jurisdiction under
`28 U.S.C. § 1295(a)(4)(A).
`
`

`

`Case: 21-1355 Document: 43 Page: 8 Filed: 09/08/2022
`
`8
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`II. DISCUSSION
`Apple presents two arguments on appeal. First, Apple
`argues that the Board adopted an erroneous claim con-
`struction of “request message and/or a reply message being
`encrypted” that excludes messages sent using packets with
`unencrypted address information. Appellant’s Br. 15–17,
`18–29. Second, Apple argues that the Board should have
`considered Apple’s arguments for the unpatentability of
`’581 patent claim 5 in evaluating its arguments regarding
`claims 6–8. Appellant’s Br. 17–18, 37–46. We address each
`argument in turn.
`
`A. Claim Construction
`“We review the Board’s claim construction de novo and
`any underlying factual findings for substantial evidence.”
`Kaken Pharm. Co. v. Iancu, 952 F.3d 1346, 1350 (Fed. Cir.
`2020) (citing Teva Pharms. USA, Inc. v. Sandoz, Inc., 574
`U.S. 318, 331–33 (2015)). “The words of a claim are gener-
`ally given their ordinary and customary meaning as under-
`stood by a person of ordinary skill in the art when read in
`the context of the specification and prosecution history.”
`Thorner v. Sony Comput. Ent. Am. LLC, 669 F.3d 1362,
`1365 (Fed. Cir. 2012) (citing Phillips v. AWH Corp., 415
`F.3d 1303, 1312–13 (Fed. Cir. 2005) (en banc)).
`Apple contends the Board erroneously construed “en-
`crypted” to exclude packets with unencrypted address in-
`formation. Appellant’s Br. 20. According to Apple,
`“encrypted” messages must rely on packets with unen-
`crypted addressing information, and the Challenged Pa-
`tents teach that encrypted messages use such packets.
`Appellant’s Br. 25–26. MPH argues that the claims require
`the request message to “cause the changing of the address
`definition,” and that “Apple admitted below that it is the
`outer header of Ishiyama’s packet,” which is unencrypted,
`“that alone is responsible for changing the address defini-
`tion to the second address.” Appellee’s Br. 32 (emphasis in
`original).
` We agree with Apple that the Board’s
`
`

`

`Case: 21-1355 Document: 43 Page: 9 Filed: 09/08/2022
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`9
`
`construction of an “encrypted” request and/or reply mes-
`sage is erroneous and contradicts the intrinsic record.
`Before addressing the substantive claim construction
`dispute, we first address certain preliminary arguments
`raised by MPH. MPH argues that the Board did not issue
`a claim construction at all, but instead made a factual find-
`ing that the Ishiyama reference fails to teach an encrypted
`request message. Appellee’s Br. 14, 30–31, 40. MPH also
`argues that Apple waived its claim construction arguments
`by not presenting them to the Board. Appellee’s Br. 34.
`We agree with Apple that the Board performed a claim
`construction. The Board stated that “the plain words of the
`claim state that the message is encrypted—not that a por-
`tion of the message is encrypted. . . . Simply put, claim 1
`requires that the request message (not just a portion
`thereof) is encrypted . . . .” Decision I at *8 (emphasis
`added); see also Decision II at *19 (same regarding claim
`4). In doing so, the Board “establish[ed] the scope and
`boundaries of the subject matter that is patented.” Net-
`word, LLC v. Centraal Corp., 242 F.3d 1347, 1350 (Fed. Cir.
`2001); see also HTC Corp. v. Cellular Commc’ns Equip.,
`LLC, 877 F.3d 1361, 1367 (Fed. Cir. 2017) (“Despite no ex-
`press construction of [claim term] below, Board findings es-
`tablishing the scope of the patented subject matter may fall
`within the ambit of claim construction.”). This is not an
`“application of the claim terms ‘encrypted’ and ‘request
`message’ to prior art,” as MPH contends, Appellee’s Br.
`45–46, but a construction as to what the claims mean.
`We also reject MPH’s argument that Apple waived or
`forfeited2 any claim construction arguments by not
`
`
`2 While MPH argues Apple “waived” its claim con-
`struction arguments, Appellee’s Br. 34, we interpret MPH
`to argue Apple forfeited its arguments. See In re Google
`
`
`

`

`Case: 21-1355 Document: 43 Page: 10 Filed: 09/08/2022
`
`10
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`presenting them to the Board. Appellee’s Br. 34. Neither
`Apple nor MPH proposed construing “encrypted,” and the
`Board did not suggest a construction in its initial determi-
`nation. J.A. 10, 66, 346–47, 3452–53. Instead, the Board
`appears to have created a dispute as to the meaning of “en-
`crypted” during its questioning at oral argument. J.A.
`742:18–20 (“[I]f the outer portion [of the packet] is not en-
`crypted, then why wouldn’t only a portion of the request
`message be encrypted?”); see also id. at 742:21–748:2. We
`decline to find forfeiture where neither party disputed the
`construction of a term and the Board nevertheless issued a
`sua sponte construction in its final written decision that di-
`verged from the parties’ understanding of the claim. See,
`e.g., Lifestyle Enter., Inc. v. United States, 751 F.3d 1371,
`1377 (Fed. Cir. 2014) (“[A] party may raise on appeal any
`issue that was . . . actually decided below.”); Hollmer v. Ha-
`rari, 681 F.3d 1351, 1356 n.3 (Fed. Cir. 2012) (declining to
`find party waived arguments regarding applicability of ear-
`lier decision where Board “sua sponte” applied that deci-
`sion in its ruling without briefing or comment); see also
`Qualcomm Inc. v. Intel Corp., 6 F.4th 1256, 1263 (Fed. Cir.
`2021) (“[U]nlike with disputed terms, it is unreasonable to
`expect parties to brief or argue agreed-upon matters of
`claim construction.”).
`“When construing claim terms, we first look to, and pri-
`marily rely on, the intrinsic evidence, including the claims
`themselves, the specification, and the prosecution history
`of the patent, which is usually dispositive.” Sunovion
`Pharms., Inc. v. Teva Pharms. USA, Inc., 731 F.3d 1271,
`
`
`Tech. Holdings LLC, 980 F.3d 858, 862 (Fed. Cir. 2020)
`(“[F]orfeiture is the failure to make the timely assertion of
`a right”). We recognize that our precedent has “not always
`been precise” in distinguishing waiver and forfeiture, and
`we do not fault a party that, understandably, has done just
`the same. Id. at 862–63.
`
`

`

`Case: 21-1355 Document: 43 Page: 11 Filed: 09/08/2022
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`11
`
`1276 (Fed. Cir. 2013). “The specification is always highly
`relevant to the claim construction analysis and is, in fact,
`the single best guide to the meaning of a disputed term.”
`Trs. of Columbia Univ. v. Symantec Corp., 811 F.3d 1359,
`1363 (Fed. Cir. 2016) (cleaned up); Phillips, 415 F.3d at
`1315 (“[T]he specification . . . is the single best guide to the
`meaning of a disputed term.”).
`Here, the claims require that a “request message
`and/or a reply message” is “encrypted.” ’810 Patent, col. 10
`l. 48–col. 11 l. 8; ’581 Patent, col. 11 ll. 9–10. The Board
`placed significant emphasis on the patents’ statement that
`“signal[ ] 10a . . .can be encrypted and/or authenticated.”
`Decision I at *8 (emphasis added); Decision II at *19 (em-
`phasis added). But this statement alone does not speak to
`whether the patents consider signals (or messages) trans-
`mitted using packets with certain unencrypted addressing
`information to be “encrypted.” ’810 Patent, col. 9, l. 66–col.
`10 l. 5; ’581 Patent, col. 9 l. 63–col. 10 l. 2. The very next
`sentence from the specifications states that “encryption . . .
`is preferably performed by using IPSec,” suggesting IPSec
`protocols inform when a message is or is not encrypted.
`’810 Patent, col. 10 ll. 5–8; ’581 Patent, col. 10 ll. 2–5. Con-
`sistent with this discussion, claim 1 of the ’810 patent re-
`quires that the message is encrypted “by using the same
`[Security Association] already established,” where that Se-
`curity Association is established “using IPSec protocols.”
`’810 Patent, col. 10 l. 48–col. 11 l. 8; see also Hockerson-
`Halberstadt, Inc. v. Converse Inc., 183 F.3d 1369, 1374
`(Fed. Cir. 1999) (“Proper claim construction, however, de-
`mands interpretation of the entire claim in context, not a
`single element in isolation.”). Thus, we turn to the specifi-
`cations’ discussion of IPSec to determine when messages
`are encrypted.
`Mirroring the claims’ requirement of “encrypted and/or
`authenticated,” the specifications discuss two protocols
`used within IPSec to provide security: “Authentication
`Header (AH)” and “Encapsulating Security Payload
`
`

`

`Case: 21-1355 Document: 43 Page: 12 Filed: 09/08/2022
`
`12
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`(ESP),” both of which “operat[e] by adding a protocol
`header.” ’810 Patent, col. 2 ll. 11–17; ’581 Patent, col. 2 ll.
`13–19. Both AH and ESP support “transport mode”—
`which “provides protection primarily for upper layer proto-
`cols and extends to the payload of an IP packet”—and “tun-
`nel mode”—which “provides protection to the entire IP
`packet.” ’810 Patent, col. 3 ll. 4–19; ’581 Patent, col. 3 ll.
`6–22. Tunnel mode is generally used to send messages
`“through more than two components,” such that packets
`are “tunnelled [sic] through external networks.” ’810 Pa-
`tent, col. 3 ll. 16–19, col. 3 ll. 24–27; ’581 Patent, col. 3 ll.
`19–22, col. 3 ll. 27–30. The specifications describe that in-
`itial ESP fields are added to an “original, or inner, packet,”
`and “the entire packet plus security fields” is “treated as
`the payload of a new outer IP packet with a new outer IP
`header.” ’810 Patent, col. 3 ll. 28–33; ’581 Patent, col. 3 ll.
`31–36. The resulting packet is described as “IP | ESP | IP
`| payload,” where the outermost “IP” applies to the “new
`larger packet” and “may have totally different source and
`destination addresses,” while the inner packet—“IP | pay-
`load”—is protected by the ESP fields. ’810 Patent, col. 3 ll.
`31–42; ’581 Patent, col. 3 ll. 34–45. With this arrangement,
`the “inner IP packet” can be tunneled so that “no routers
`along the way are able to examine the inner IP packet,”
`while “intermediate routers” examine “only the outer IP
`header.” ’810 Patent, col. 3 ll. 31–33, col. 3 ll. 55–57; ’581
`Patent, col. 3 ll. 34–36, col. 3 ll. 58–60.
`Accordingly, the specifications contemplate that “en-
`crypted” messages can be sent using outer packets with
`certain unencrypted addressing information, contrary to
`the Board’s construction. As discussed in both patents, the
`outer packet’s “IP” information is not protected by ESP
`fields, allowing intermediate routers to examine that infor-
`mation. Messages are still secure because the ESP fields
`protect the inner packet’s IP information and payload.
`Consistent with this analysis, MPH appears to agree
`that a message with certain unencrypted addressing
`
`

`

`Case: 21-1355 Document: 43 Page: 13 Filed: 09/08/2022
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`13
`
`information can meet the claims. First, MPH did not raise
`or dispute the construction of the term “encrypted” to the
`Board. Decision I at *4; Decision II at *4. Instead, MPH
`argued to the Board that the unencrypted “outer header it-
`self” cannot serve as the “request message.” Appellee’s Br.
`14–15 (emphasis added); see also id. at 31(arguing the
`same before us). The Board agreed with Apple and con-
`cluded that “Ishiyama’s entire transmitted packet (i.e., the
`encapsulated packet plus the outer packet, which has the
`changed source address) is the claimed request message.”
`Decision I at *7; Decision II at *8. Second, at oral argument
`on appeal, MPH’s counsel twice refused to concede that a
`message sent using a packet with unencrypted addressing
`information could not infringe the claims. Oral Arg. at
`22:01–23:00, 28:50–29:21, available at https://oralargu-
`ments.cafc.uscourts.gov/default.aspx?fl=21-1355_1207202
`1.mp3; see 01 Communique Lab’y, Inc. v. Citrix Sys., Inc.,
`889 F.3d 735, 743 (Fed. Cir. 2018) (“[C]laim terms must be
`‘construed the same way for both invalidity and infringe-
`ment.’”).
`We hold that the Board adopted an erroneous claim
`construction of “request message and/or a reply message
`being encrypted” within claim 1 of the ’810 patent and
`claim 4 of the ’581 patent that excludes “encrypted” mes-
`sages because those messages are sent using packets with
`certain unencrypted addressing information. The Chal-
`lenged Patents contemplate that a message can still be con-
`sidered “encrypted” if its packet has unencrypted “outer IP
`header” information. We vacate the portions of the Board’s
`final written decisions relying on that erroneous claim con-
`struction and remand for further proceedings.3
`
`
`3 Apple alternatively argues that the Board’s deci-
`sion should be remanded because the Board’s sua sponte
`claim construction violated the Administrative Procedure
`
`
`

`

`Case: 21-1355 Document: 43 Page: 14 Filed: 09/08/2022
`
`14
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`B. Apple’s Petition
`Next, we address Apple’s argument that the Board
`erred in declining to consider its unpatentability argu-
`ments for dependent claims 6–8 of the ’581 patent under
`Grounds 1 and 3, despite finding claim 5 of that patent un-
`patentable under Ground 2. Appellant’s Br. 41.
`Apple argues that where a challenger proves a claim
`unpatentable, courts can only sustain dependent claims
`based on “the language of the dependent claims them-
`selves.” Appellant’s Br. 38. Because the Board found
`claim 5 of the ’581 patent to be unpatentable, Apple urges
`that the Board only needed to consider prior art to the ex-
`tent necessary to address the remaining limitations added
`in dependent claims 6–8. Appellant’s Br. 39.
`MPH responds that Ground 1 of Apple’s petition relies
`solely on Ishiyama in view of Murakawa to address claims
`6–7 and omits the Ahonen reference that Apple relied upon
`to address claim 5. Appellee’s Br. 52. Similarly, Ground 3
`of Apple’s petition relies on Ishiyama, Murakawa, and For-
`slöw to address claim 8, but, again, omits the Ahonen ref-
`erence. Id. Because claims 6–8 depend from claim 5, MPH
`argues that the Board correctly found that Apple failed to
`carry its burden to address all of the relevant limitations
`by not discussing Ahonen.4 Appellee’s Br. 53–54; see
`
`
`Act. Appellant’s Br. 29–37. Because we vacate the portions
`of the Board’s decision relying on its erroneous claim con-
`struction and remand for additional proceedings, we do not
`reach this alternative argument.
`4 MPH argues that we can nevertheless affirm the
`Board’s determination as to claims 4–6 of the ’810 patent
`because Apple relied on Ahonen to meet the intervening
`limitations in claim 3 and did not include Ahonen in its
`grounds challenging those claims. Appellee’s Br. 57–58.
`
`
`

`

`Case: 21-1355 Document: 43 Page: 15 Filed: 09/08/2022
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`15
`
`Koninklijke Philips N.V. v. Google LLC, 948 F.3d 1330,
`1335– 37 (Fed. Cir. 2020).
`We agree with MPH that the Board did not err in deny-
`ing Apple’s petitions as to claims 6–8 of the ’581 patent. As
`the Supreme Court has held, “in an inter partes review the
`petitioner is master of its complaint and normally entitled
`to judgment on . . . the claims it raises, not just those the
`decisionmaker might wish to address.” SAS Inst., Inc. v.
`Iancu, 138 S. Ct. 1348, 1355 (2018) (emphasis added); see
`also Intuitive Surgical, Inc. v. Ethicon LLC, 25 F.4th 1035,
`1041 (Fed. Cir. 2022) (“[A]s the master of its own petition,
`Intuitive could have made its challenges more pointed and
`specific . . . .”). This holding is consistent with the statu-
`tory framework that requires a petition to identify “the
`grounds on which the challenge to each claim is based.” 35
`U.S.C. § 312(a)(3); see also 37 C.F.R. § 42.104(b) (requiring
`petitioner to identify “the patents or printed publications
`relied upon for each ground” and “where each element of
`the claim is found in the prior art patents or printed publi-
`cations relied upon”).
`The Board is not limited by the “exact language of the
`petition,” but it does not “enjoy[] a license to depart from
`the petition and institute a different inter partes review of
`his own design.” Koninklijke Philips, 948 F.3d at 1336
`(quoting SAS, 138 S. Ct. at 1356); see also Sirona Dental
`Sys. GmbH v. Institut Straumann AG, 892 F.3d 1349, 1358
`(Fed. Cir. 2018) (finding “no error” in Board’s decision “not
`to decide grounds of unpatentability not raised in the peti-
`tion”). In Koninklijke Philips, Google’s petition included
`
`The Board did not reach this issue because it found Apple
`did not demonstrate claim 1 to be unpatentable. Decision
`I at *9, 22. Because we vacate the portions of the Board’s
`decisions based on its construction of an “encrypted” re-
`quest or reply message in claim 1, the Board should decide
`whether to consider this issue on remand.
`
`

`

`Case: 21-1355 Document: 43 Page: 16 Filed: 09/08/2022
`
`16
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`two grounds: (1) anticipation based on Synchronized Mul-
`timedia Integration Language 1.0 Specification (“SMIL
`1.0”), and (2) obviousness based on “SMIL 1.0 in light of the
`general knowledge of the [skilled artisan] regarding distrib-
`uted multimedia presentation systems as of the priority
`date.” 948 F.3d at 1333–34. Google relied on a prior art
`reference referred to as “Hua” to demonstrate the state of
`the art. Id. at 1334. The Board instituted on three grounds:
`the two identified in Google’s petition and a third present-
`ing obviousness based on SMIL 1.0 and Hua. Id. at 1334.
`Although we found it proper for the Board to institute
`Ground 2 based on SMIL 1.0 and the “general knowledge”
`of a person of skill in the art, we held the Board erred in
`instituting a ground based on SMIL 1.0 and Hua “because
`Google did not advance such a combination of references in
`its petition.” Id. at 1337.
`Here, we agree the Board properly declined to consider
`Ahonen in Grounds 1 and 3 of the ’581 patent’s IPR. See
`Decision II at *20, 27. Apple only raised Ahonen in Ground
`2, which challenged claims 3 and 5 of the ’581 patent. Id.
`at *3. Even though claims 6–8 depend from claim 5, Apple
`did not include Ahonen in Grounds 1 and 3 challenging
`those claims, nor did it address or reference Ahonen in its
`substantive analysis. J.A. 3312–16, 3323–26. The Board
`did not err by declining to consider arguments that Apple
`did not make. See Koninklijke Philips, 948 F.3d at 1337.
`Apple contends the Board exalted “form over sub-
`stance” by requiring Apple to include Ahonen in Grounds 1
`and 3, Appellant’s Br. 46, but these requirements have a
`practical impact as well. For example, Apple’s Ground 3
`relies on Ishiyama, Murakawa, and Forslöw. J.A. 3323–26.
`Apple presented no argument as to why a skilled artisan
`would be inclined to combine the teachings of Ishiyama,
`Murakawa, Forslöw, and Ahonen. J.A. 3323, 3326. We
`have previously reversed Board decisions that found a mo-
`tivation to combine where the petitioner presented only
`threadbare arguments to support its combination, let alone
`
`

`

`Case: 21-1355 Document: 43 Page: 17 Filed: 09/08/2022
`
`APPLE INC. v. MPH TECHNOLOGIES OY
`
`17
`
`where a party entirely failed to address one of the refer-
`ences it sought to combine. See, e.g., TQ Delta, LLC v. Cisco
`Sys., Inc., 942 F.3d 1352, 1359 (Fed. Cir. 2019) (“[A] con-
`clusory assertion with no explanation is inadequate to sup-
`port a finding that there would have been a motivation to
`combine.”).
`Apple cites several cases for the general proposition
`that where a parent claim is invalid, its dependent claims
`may be similarly invalid. Appellant’s Br. 38–39. Those
`cases are distinguishable because they do not address the
`situation at hand, i.e., where a petitioner did not address
`all of a claim’s limitations in its petition. In Ormco Corp.
`v. Align Technology, Inc., we explained that invalidating
`one claim can inform the patentability of other claims that
`lack “patentably significant” differences. 498 F.3d 1307,
`1320 (Fed. Cir. 2007). In Soverain Software LLC v. Victo-
`ria’s Secret Direct Brand Management, LLC, we applied
`collateral estoppel regarding the invalidity of a dependent
`claim because “transmitting a hypertext statement over the
`internet, rather than over a generic network” did not mate-
`rially alter the invalidity analysis. 778 F.3d 1311, 1319–20
`(Fed. Cir. 2015) (emphases added). And in MaxLinear, Inc.
`v. CF CRESPE LLC, we explained that collateral estoppel
`often “requires the invalidation of related claims that pre-
`sent identical issues of patentability.” 880 F.3d 1373, 1374,
`1377 (Fed. Cir. 2018). But these cases do not involve a pe-
`titioner who did not address each of a dependent claim’s
`intervening limitations in a single ground.
`Apple’s citation to Soverain Software LLC v. Newegg
`Inc., 728 F.3d 1332, 1335 (Fed. Cir. 2013), is similarly in-
`apposite. See Appellant’s Br. 40–41. There, we explained
`that if the parties do not “separately argue” or distinguish
`a dependent claim and the independent claim it incorp

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