UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`____________
`
`Case IPR2019-00822
`Patent 8,346,949 B2
`____________
`
`Before SALLY C. MEDLEY, KAMRAN JIVANI, and
`JOHN D. HAMANN, Administrative Patent Judges.
`
`MEDLEY, Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314
`
`Exhibit 2007
`Page 2007-1
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`I. INTRODUCTION
`Apple Inc. (“Petitioner”) filed a Petition for inter partes review of
`claims 1–7, 9, 11–14, 20, 21, and 27–29 of U.S. Patent No. 8,346,949 B2
`(Ex. 1001, “the ’949 patent”). Paper 2 (“Pet.”). MPH Technologies Oy,
`(“Patent Owner”) filed a Preliminary Response. Paper 6 (“Prelim. Resp.”).
`Institution of an inter partes review is authorized by statute when “the
`information presented in the petition . . . and any response . . . shows that
`there is a reasonable likelihood that the petitioner would prevail with respect
`to at least 1 of the claims challenged in the petition.” 35 U.S.C. § 314(a).
`Upon consideration of the Petition and Preliminary Response, we decline to
`institute review of the challenged claims of the ’949 patent.
`
`A. Related Matters
`Petitioner and Patent Owner indicate that the ’949 patent is the subject
`of the following currently pending court proceeding: MPH Techs. Oy v.
`Apple Inc., Case No. 4:18-cv-05935-PJH (N.D. Cal.). Pet. 2; Paper 5, 1.
`The parties also identify the following proceedings involving different, but
`related patents: IPR2019-00823, IPR2019-00824, IPR2019-00825, and
`IPR2019-00826. Id.
`
`B. The ’949 Patent
`The Specification of the ’949 patent describes a method and system
`for enabling secure forwarding of a message from a first computer to a
`second computer via an intermediate computer. Ex. 1001 [57]. The first
`computer forms a secure message by giving the message a unique identity
`and a destination address. Id. The message is sent from the first computer
`to the intermediate computer. Id. The intermediate computer uses the
`destination address and the unique identity to find an address to the second
`
`Exhibit 2007
`Page 2007-2
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`computer. Id. The destination address is substituted with the found address
`to the second computer and the unique identity is substituted with another
`unique identity. Id. The message is then forwarded to the second computer.
`Id.
`
`“An example of a telecommunication network of the invention is
`illustrated” per Figure 1, reproduced below. Id. at 9:57–58.
`
`
`
`
`Figure 1 is an illustration of a telecommunication network. Id. at 9:57–58.
`Client computer 1 is served by intermediate computer (sever 2) and host
`computer 4 is served by a second computer (security gateway 3). Id. at
`9:55–61. Security gateway 3 supports the standard IP security protocol
`(IPsec) and optionally the Internet Key Exchange (IKE) protocol. Id. at
`9:61–63. Client computer 1 and server 2 support a modified IPsec and IKE
`protocol. Id. at 9:63–65. In particular, an IPsec connection is formed
`
`Exhibit 2007
`Page 2007-3
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`between client computer 1 and security gateway 3 by forming a security
`association (SA) between the computers with a preceding key exchange. Id.
`at 10:32–36. A security association is uniquely identified by three
`parameters. Id. at 2:28–30. The first parameter is a Security Parameters
`Index (SPI) which is carried in AH (Authentication Header) and ESP
`(Encapsulating Security Payload) headers. Id. at 2:29–31. The second
`parameter is an IP destination address, which is the address of the
`destination end point of the SA, and the third parameter is a security
`protocol identifier, which identifies whether the association is an AH or ESP
`security association. Id. at 2:32–38.
`The key exchange between first and second computer takes place
`manually or with an automatic key exchange protocol such as the IKE
`protocol. Id. at 10:36–39. The key exchange is performed using a standard
`IKE protocol between server 2 and security gateway 3, and a modified IKE
`protocol is used between client computer 1 and server 2. Id. at 10:39–43.
`Messages to be sent to host terminal 4 from client computer 1 are first sent
`to server 2, wherein an IPsec translation and an IKE translation takes place.
`Id. at 10:45–47. The message is then sent to security gateway 3, which
`sends the message in plain text to host terminal 4. Id. at 10:47–49.
`Figure 3, reproduced below, illustrates an example of an IPsec
`translation table used by the intermediate computer to change the outer IP
`address and SPI value. Id. at 9:45–47.
`
`
`Figure 3 shows a partitioned table, where the left side, identified by
`the prefix c-, refers to the network connection between the first computer
`and an intermediate computer, and the right side, identified by the prefix s-,
`
`Exhibit 2007
`Page 2007-4
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`refers to the network connection between the intermediate computer and a
`second computer. Id. at 11:25–31. The postfix number (-1, -2, or -3)
`identifies the host in question. Id. at 11:31–32. When the intermediate
`computer receives the packet sent, it performs an address and SPI
`translation, ensuring that the security gateway (host 3 of Figure 1) can accept
`the packet. Id. at 11:51–54. The intermediate computer does not have
`cryptographic keys to undo the IPsec processing done by the mobile
`terminal, and cannot decrypt the packet, but is able to use the outer IP
`addresses and the incoming SPI value to determine how to modify the outer
`address and the SPI to suite the second computer. Id. at 11:55–60. Thus, in
`this example, SPI is changed to 0x56785678 in the intermediate computer
`and the address is changed to the address of the second computer. Id. at
`11:61–64. “The new outer source address s-addr-2 (212.90.65.1) is
`substituted for the outer source address c-addr-1 (195.1.2.3), and the new
`outer destination address s-addr-3 (103-6-5-4) is substituted for the outer
`destination address c-addr-2 (212.90.65.1).” Id. at 12:1–5. Moreover, “[t]he
`new SPI value, s-SPI-3 (0x56785678), is substituted for the SPI value c-SPI-
`2 (0x12341234).” Id. at 12:5–6. The invention accomplishes the effect of
`“double tunneling,” while maintaining confidentiality of packets with no
`extra overhead compared to standard IPsec. Id. at 10:15–20.
`
`C. Disclaimer
`Patent Owner filed a statutory disclaimer under 35 U.S.C. § 253(a) of
`claim 27 of the ’949 patent. Prelim. Resp. 4 (citing Ex. 2001). We treat
`disclaimed claim 27 as if it never existed. See Vectra Fitness, Inc. v. TNWK
`Corp., 162 F.3d 1379, 1383 (Fed. Cir. 1998) (“This court has interpreted the
`term ‘considered as part of the original patent’ in section 253 to mean that
`
`Exhibit 2007
`Page 2007-5
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`the patent is treated as though the disclaimed claims never existed.”); Guinn
`v. Kopf, 96 F.3d 1419, 1422 (Fed. Cir. 1996) (“A statutory disclaimer under
`35 U.S.C. § 253 has the effect of canceling the claims from the patent and
`the patent is viewed as though the disclaimed claims had never existed in the
`patent”). Accordingly, because we treat claim 27 as if it never existed,
`Petitioner’s challenge to claim 27 is moot and we do not consider it.
`
`D. Illustrative Claim
`Petitioner challenges claims 1–7, 9, 11–14, 20, 21, 28, and 29 of the
`’949 patent. Claim 1 is the sole independent claim and the remaining claims
`depend either directly or indirectly from claim 1. Claim 1 is reproduced
`below, which includes changes made per a Certificate of Correction.
`1. A method for secure forwarding of a message from a
`first computer to a second computer using a secure connection
`via an intermediate computer in a telecommunication network,
`comprising:
`negotiating and exchanging keys with one another, by the
`first and second computer, according to a key exchange protocol
`to establish the secure connection between the first computer and
`the second computer via the intermediate computer,
`the secure connection having a source address of the first
`computer as a first end point and a destination address of the
`second computer as a second end point of the secure connection,
`forming a secure message, in the first computer, by giving
`the secure message a first unique identity and a first destination
`address to the intermediate computer,
`sending the secure message, using the secure connection,
`containing the first unique identity and the first destination
`address from the first computer to the intermediate computer, the
`intermediate computer receiving the secure message and
`performing a translation by using the first unique identity to find
`a second destination address to the second computer, the
`
`Exhibit 2007
`Page 2007-6
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`intermediate computer substituting the first destination address
`with the second destination address to the second computer,
`substituting, at the intermediate computer, the first unique
`identity with a second unique identity of the secure connection,
`and
`
`forwarding, at the intermediate computer, the secure
`message with the second destination address and the second
`unique identity to the second computer in the secure connection.
`Ex. 1001, 22:6–39, 20.
`
`E. Asserted Grounds of Unpatentability
`Petitioner asserts that claims 1–7, 9, 11–14, 20, 21, 28, and 29 are
`unpatentable based on the following grounds. Pet. 7–8:
`Statutory Basis1 Challenged Claim(s)
`References
`1, 2, 4–7, 9, 11–14,
`RFC31042 and Grabelsky3
`§ 103
`20, 21, 28, and 29
`RFC3104, Grabelsky, and
`3
`Wagner4
`
`§ 103
`
`II. DISCUSSION
`
`A. Claim Construction
`In this inter partes review, claims are construed using the same claim
`construction standard that would be used to construe the claims in a civil
`
`1 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. §§ 102 and 103. Because the ’949
`patent has an effective filing date before the effective date of the applicable
`AIA amendments, we refer to the pre-AIA versions of 35 U.S.C. §§ 102 and
`103.
`2 RFC3104, “RSIP Support for End-to-end IPsec,” Oct. 2001 (Ex. 1004,
`“RFC3104”).
`3 U.S. Patent No. 7,032,242 B1, issued Apr. 18, 2006 (Ex. 1005,
`“Grabelsky”).
`4 David Wagner et al., “Analysis of the SSL 3.0 Protocol,” May 2000
`(Ex. 1006, “Wagner”).
`
`Exhibit 2007
`Page 2007-7
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`action under 35 U.S.C. § 282(b). 37 C.F.R. § 42.100(b) (2019). The claim
`construction standard includes construing claims in accordance with the
`ordinary and customary meaning of such claims as understood by one of
`ordinary skill in the art and the prosecution history pertaining to the patent.
`See id.; Phillips v. AWH Corp., 415 F.3d 1303, 1312–14 (Fed. Cir. 2005).
`“substituting”
`Claim 1 recites “substituting the first destination address with the
`second destination address” and “substituting, at the intermediate computer,
`the first unique identity with a second unique identity.” Patent Owner
`argues that “substituting” should be construed to mean “changing, replacing,
`or modifying,” and not “adding to.” Prelim. Resp. 20–24. Patent Owner
`argues that in addition to the plain language of the claim, the Specification
`of the ’949 patent supports the proposed construction. Id. Patent Owner
`directs attention to the Specification of the ’949 patent that describes some
`modification or replacement of the first address with a new address. Id. at
`21 (citing Ex. 1001, 7:38–41, 11:57–61, 11:63–65, 12:3–5). We agree that
`such passages describe modification or replacement and not “adding to.”
`We further agree with Patent Owner that the Specification of the ’949 patent
`distinguishes between adding and substituting. Id. at 21– 22 (citing
`Ex. 1001, 5:22–25, 10:14–20, 16:14–24). Patent Owner further argues that
`the proposed construction is consistent with dictionary definitions. Id. at 23
`(citing Ex. 2002 (defining “substitute” as “to put or use in place of
`another”); Ex. 2003 (defining “substitute” as e.g., “n. 1. One that takes the
`place of another; a replacement”)).
`Although Petitioner does not propose a construction for
`“substituting,” we agree with Patent Owner that Petitioner recognizes a
`distinction between “adding” and “replacing.” Id. at 22 (citing Pet. 41
`
`Exhibit 2007
`Page 2007-8
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`(where Petitioner argues that although RFC3104 describes “tunneling” a
`packet, which would have been understood to mean “adding or replacing” an
`outer IP header with an IP header that includes destination address of host X,
`Petitioner avers that it would have been obvious to replace the outermost IP
`header of the packet with a new IP header in order to minimize packet size
`and reduce overhead)). For purposes of this Decision, we construe
`“substituting” to mean “changing, replacing, or modifying,” and not “adding
`to.”
`
`We need not expressly construe any other claim terms. See Vivid
`Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999)
`(holding that “only those terms need be construed that are in controversy,
`and only to the extent necessary to resolve the controversy”); see also Nidec
`Motor Corp. v. Zhongshan Broad Ocean Motor Co. Matal, 868 F.3d 1013,
`1017 (Fed. Cir. 2017) (citing Vivid Techs. in the context of an inter partes
`review).
`
`B. 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
`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;
`
`Exhibit 2007
`Page 2007-9
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`(3) the level of ordinary skill in the art;5 and (4) when in evidence, objective
`indicia of nonobviousness. Graham v. John Deere Co., 383 U.S. 1, 17–18
`(1966).
`
`C. Asserted Obviousness of Claims 1, 2, 4–7, 9, 11–14, 20, 21, 28, and 29
`over RFC3104 and Grabelsky
`Petitioner contends claims 1, 2, 4–7, 9, 11–14, 20, 21, 28, and 29 are
`unpatentable under 35 U.S.C. § 103(a) as obvious over RFC3104 and
`Grabelsky. Pet. 20–64. In support of its showing, Petitioner relies upon the
`declaration of Dr. Goldschlag. Id. (citing Ex. 1002).
`
`1. RFC3104
`RFC3104 is a technical document that “proposes mechanisms that
`enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security).”
`Ex. 1004, 1. Petitioner annotated RFC3104 diagram (pet. 21) is reproduced
`below:
`
`
`
`5 Relying on the testimony of Dr. David Goldschlag, Petitioner offers an
`assessment as to the level of skill in the art at the time of the ’949 patent.
`Pet. 17 (citing Ex. 1002 ¶¶ 31–32). Patent Owner does not propose an
`alternative assessment. See generally Prelim. Resp. To the extent
`necessary, and for purposes of this Decision, we accept the assessment
`offered by Petitioner as it is consistent with the ’949 patent and the asserted
`prior art.
`
`Exhibit 2007
`Page 2007-10
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`Petitioner annotated RFC3104 diagram (pet. 21) illustrates Hosts X
`
`and Y belong to different address spaces A and B. Ex. 1004, 2–3. N is an
`RSIP server that has two addresses; Na on address space A and Nb on
`address space B. Id. at 3. RFC3104 “proposes RSIP extensions and
`mechanisms to enable an RSIP client X to initiate IKE and IPsec sessions to
`a legacy IKE and IPsec node Y.” Id. RFC3104 “assumes that RSIP server
`N is examining a packet sent by Y, destined for X.” Id. RSIP client and
`server N arrive at a SPI value to denote the incoming IPsec security
`association from Y to X. Id. at 5. When “N and X make sure that the SPI is
`unique within both of their SPI spaces, X communicates its value to Y as
`part of the IPsec security association establishment process, namely, Quick
`Mode in IKE [IKE] or manual assignment.” Id. Y sends IPsec packets to X
`via address Nb using the negotiated SPI. Id. IPsec packets from Y to X
`arrive at RSIP server N for demultiplexing. Id. Packets are demultiplexed
`based on a minimum tuple of demultiplexing fields: protocol (50 or 51), SPI,
`and destination IP address. Id. If N finds a matching map, it tunnels the
`packet to X according to the tunneling mode in effect. Id.
`
`2. Grabelsky
`Grabelsky is directed to a method and system for distributed network
`address translation with security features that allows IPsec to be used with
`distributed network address translation. Ex. 1005, (57). Grabelsky Figure 1
`is reproduced below.
`
`Exhibit 2007
`Page 2007-11
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`Figure 1 is an illustration of a network system for distributed address
`translation. Id. at 5:35–36. Network 10 includes first computer network 12
`with multiple network devices (14, 16, 18, 20, 22, 24) and router 26 to route
`data packets to another external computer network. Id. at 6:30–35.
`Grabelsky describes security measures that can be used in its packet routing
`techniques, including IPsec. Id. at 20:42–45. Grabelsky describes receiving
`packets using IPsec at router 26, which maintains a mapping between local
`IP addresses of network devices (e.g., 14, 16, 18, 20, 22, 24) and SPI values.
`Id. at 32:33–36. When an AH or ESP IPsec packet arrives at router 26,
`router 26 examines a SPI value in the IPsec packet’s outermost header and
`determines a local IP 54 address of a destination network device. Id. at
`32:36–42.
`
`3. Discussion
`Claim 1 recites “the intermediate computer substituting the first
`destination address with the second destination address to the second
`computer” and “substituting, at the intermediate computer, the first unique
`
`Exhibit 2007
`Page 2007-12
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`identity with a second unique identity of the secure connection.” For the
`first disputed phrase, Petitioner relies on RFC3104’s description that “[i]f N
`is able to find a matching mapping, it tunnels the packet to X according to
`the tunneling mode in effect” to meet the claim phrase. Id. at 41 (citing
`Ex. 1004, 5). Petitioner argues that although RFC3104 does not explicitly
`provide tunneling details, a “POSITA would have understood that tunneling
`the packet involves adding or replacing an outer IP header of the packet with
`an IP Header that includes the destination address of host X.” Id. (citing
`Ex. 1002 ¶ 108). Petitioner further contends that a “POSITA would have
`been specifically motivated to replace the outermost IP header of the packet
`with a new IP header in order to minimize packet size and reduce overhead.”
`Id. (citing Ex. 1002 ¶ 109). For similar reasons, and for the second disputed
`phrase, Petitioner contends that it would have been obvious to substitute the
`outer IP header with a new IP header, including the destination address of
`host X, to create a “second unique identity of the secure connection.” Id. at
`43 (citing Ex. 1002 ¶ 112). Petitioner contends that the parameter values
`that make up the “second unique identity” (i.e., the new IP header and IPsec
`protocol header) are different from the parameter values that make up the
`“first unique identity” (i.e., the replaced IP header and IPsec protocol
`header). Id. Petitioner argues that “even if the RSIP server N in RFC3104
`were to add a new IP header to the existing outer IP header, the parameter
`values included in the combination of the new outer IP header and the IPSec
`protocol header would still be different than those that make up the ‘first
`unique identity’” or that a “POSITA would have been motivated and
`expected RSIP server N to replace the existing outer IP header with a new
`IP header.” Id. at 43–44 (citing Ex. 1002 ¶ 113).
`
`Exhibit 2007
`Page 2007-13
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`Patent Owner argues that record evidence indicates that RFC3104’s
`“tunneling” involves “adding” an outer IP header, not replacing an outer IP
`header, and that a person having ordinary skill in the art would not have
`been motivated to modify RFC3104 to replace (e.g., substitute) the outer IP
`header with a new IP header. Prelim. Resp. 41–59.
`As explained above, we adopt Patent Owner’s construction that
`“substituting” means “changing, replacing, or modifying,” and not “adding
`to.” Accordingly, we reject Petitioner’s assertions that “adding” a new IP
`header to an existing outer IP header, results in “substituting” as claimed.6
`For the claim phrase “substituting the first destination address with the
`second destination address,” Petitioner contends RFC3104 describes
`“tunnel[ing] the packet to X according to the tunneling mode in effect.”
`Pet. 41 (citing Ex. 1005, 5). Petitioner further argues that although
`RFC3104 does not explicitly provide tunneling details, a “POSITA would
`have understood that tunneling the packet involves adding or replacing an
`outer IP header of the packet with an IP Header that includes the destination
`address of host X.” Id. at 41 (citing Ex. 1002 ¶ 108). Petitioner, however,
`fails to show that “tunneling the [RFC3104] packet involves . . . replacing
`
`6 For example, Dr. Goldschlag testifies that “[w]hile a POSITA would be
`motivated to replace the outer header . . . even if the RSIP server N in
`RFC3104 were to add a new IP header to the existing outer IP header, a
`POSITA would recognize that a “second unique identity” would still be
`substituted for the “first unique identity.” Ex. 1002 ¶ 113 (emphasis in
`original); see also Pet. 43–44 (contending the same). Petitioner provides no
`reasons why we should construe “substituting” to mean “adding” in the
`context of the claim phrase of “substituting, at the intermediate computer,
`the first unique identity with a second unique identity of the secure
`connection.” Moreover, Petitioner’s position in this regard appears
`inconsistent with other Petitioner statements made indicating that
`“substituting” does not include “adding.” See, e.g., Pet. 41.
`
`Exhibit 2007
`Page 2007-14
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`an outer IP header of the packet with an IP Header that includes the
`destination address of host X.” Petitioner directs attention to Dr.
`Goldschlag’s testimony in support of its assertion. Id. Dr. Goldschlag’s
`testimony, however, tells us nothing more than what is in the Petition. There
`is no factual basis in support of the assertion that a person having ordinary
`skill in the art would have understood that tunneling as described in
`RFC3104 involves replacing one thing for another. Such ipse dixit is
`insufficient to show a reasonable likelihood of success. See Securus Techs.
`Inc. v. Glob. Tel*Link Corp., 701 F. App’x 971, 974–976 (Fed. Cir. 2017)
`(affirming the Board’s determination that conclusory testimony by an expert
`witness was insufficient to satisfy Petitioner’s burden of showing that the
`skilled artisan would have modified the references as asserted); see also 37
`C.F.R. § 42.65(a) (“Expert testimony that does not disclose the underlying
`facts or data on which the opinion is based is entitled to little or no
`weight.”). Thus, we give little weight to such unsupported conclusions,
`which alone is fatal to the Petition.
`Moreover, and independently, record evidence describes tunneling as
`adding something to an existing packet, not replacing one thing for another
`within a packet. For instance, the ’949 patent describes tunneling in the
`context of adding a header to an existing packet, not replacing a header.
`Ex. 1001, 3:9–35. Grabelsky also describes tunneling in the context of
`adding a header, not replacing a header. Ex. 1005, 21:52–55, 32:42–47.
`Thus, we agree with Patent Owner that record evidence does not indicate
`that RFC3104’s “tunneling” involves anything but “adding.” Prelim. Resp.
`45–46.
`Petitioner also argues “[a] POSITA would have been specifically
`motivated to replace the outermost IP header of the packet with a new IP
`
`Exhibit 2007
`Page 2007-15
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`header in order to minimize packet size and reduce overhead.” Pet. 41
`(citing Ex. 1002 ¶ 109). Dr. Goldschlag states the same, without directing
`attention to any supporting evidence for his conclusion. Ex. 1002 ¶ 109.
`Petitioner’s position, however, is based on the premise that “tunneling”
`includes replacing, which as we state above, has not been shown. In other
`words, Petitioner fails to direct us to evidence, beyond Dr. Goldschlag’s
`conclusory testimony, showing a person having ordinary skill in the art at
`the time of the invention even knew that replacing the outermost IP of the
`packet with a new IP header was an option. See Securus Techs. Inc., 701 F.
`App’x at 974–976; see also 37 C.F.R. § 42.65(a). In addition, Petitioner
`directs us to no evidence, beyond Dr. Goldschlag’s conclusory testimony, to
`support its assertion that a person having ordinary skill in the art at the time
`of the invention would have been motivated to replace “the outermost IP of
`the packet with a new IP header” in order to “minimize packet size and
`reduce overhead.” Id. Although the ’949 patent describes reducing
`overhead (Ex. 1001, 10:14–20), we agree with Patent Owner that using this
`description as a reason to make the proposed modification amounts to
`impermissible hindsight. Prelim. Resp. 53.
`For all of these reasons, we are not persuaded that Petitioner has
`established a reasonable likelihood that Petitioner would prevail in its
`challenge to claims 1, 2, 4–7, 9, 11–14, 20, 21, 28, and 29 as unpatentable
`under 35 U.S.C. § 103 based on RFC3104 and Grabelsky.7
`
`7 Because we find Petitioner has not shown a reasonable likelihood of
`prevailing on the challenge for the reasons discussed above, we do not reach
`Patent Owner’s remaining arguments for this challenge.
`
`Exhibit 2007
`Page 2007-16
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`D. Asserted Obviousness of Claim 3 over RFC3104, Grabelsky, and
`Wagner
`
`Petitioner contends claim 3 is unpatentable under 35 U.S.C. § 103(a)
`as obvious over RFC3104, Grabelsky, and Wagner. Pet. 65–70. Petitioner
`relies on Wagner in combination with RFC3104 and Grabelsky to address
`the elements of claim 3. Claim 3 depends directly from claim 1. As
`explained above, we are not persuaded that Petitioner has established a
`reasonable likelihood that Petitioner would prevail in its challenge to claims
`1, 2, 4–7, 9, 11–14, 20, 21, 28, and 29 as unpatentable under 35 U.S.C.
`§ 103 based on RFC3104 and Grabelsky. Accordingly, we are not
`persuaded that Petitioner has established a reasonable likelihood that
`Petitioner would prevail in its challenge to claim 3, which depends from
`claim 1.
`
`III. CONCLUSION
`For the foregoing reasons, we determine that Petitioner has not shown
`a reasonable likelihood that it would prevail in showing that any of claims
`1–7, 9, 11–14, 20, 21, 28, and 29 of the ’949 patent are unpatentable.
`
`IV. ORDER
`For the foregoing reasons, it is
`ORDERED that the Petition is denied as to all challenged claims, and
`no trial is instituted.
`
`Exhibit 2007
`Page 2007-17
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`

`

`PETITIONER:
`
`Michael D. Specht
`Daniel S. Block
`Steven M. Pappas
`STERNE, KESSLER, GOLDSTEIN & FOX, P.L.L.C.
`mspecht-ptab@sternekessler.com
`dblock-ptab@sternekessler.com
`spappas-ptab@sternekessler.com
`
`PATENT OWNER:
`James T. Carmichael
`CARMICHAEL IP LAW, PLLC
`jim@carmichaelip.com
`
`Christopher J. Lee
`Richard B. Megley
`Brian E. Haan
`Ashley E. LaValley
`LEE SHEIKH MEGLEY & HAAN LLC
`clee@leesheikh.com
`rmegley@leesheikh.com
`bhaan@leesheikh.com
`alavalley@leesheikh.com
`
`Kenneth J. Weatherwax
`Patrick Maloney
`Jason C. Linger
`LOWENSTEIN & WEATHERWAX LLP
`weatherwax@lowensteinweatherwax.com
`maloney@lowensteinweatherwax.com
`linger@lowensteinweatherwax.com
`
`Exhibit 2007
`Page 2007-18
`IPR2019-00824, Apple Inc. v. MPH Techs. Oy
`
`