UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner
`____________________
`
`Case IPR2019-00819
`U.S. Patent No. 7,620,810
`____________________
`
`
`
`
`
`PETITION FOR INTER PARTES REVIEW OF
`U.S. PATENT NO. 7,620,810
`
`
`
`
`
`
`
`
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 1
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`
`TABLE OF CONTENTS
`
`V. 
`
`3. 
`
`4. 
`
`5. 
`
`6. 
`
`
`Introduction ..................................................................................................... 1 
`I. 
`II.  Mandatory Notices (37 C.F.R. § 42.8) ........................................................... 2 
`III.  Grounds for Standing (37 C.F.R. § 42.104(a)) ............................................... 3 
`IV. 
`Identification of Challenge (37 C.F.R. § 42.104(b)) ...................................... 4 
`A. 
`Statutory Grounds for the Challenge ..................................................... 4 
`B. 
`Citation of Prior Art .............................................................................. 4 
`The ’810 Patent ............................................................................................... 5 
`A.  Overview of the ’810 Patent .................................................................. 5 
`1. 
`The ’810 Patent Admitted Prior Art. ......................................... 8 
`2. 
`The
`Examiner Misapplied References During
`Prosecution in View of the Admitted Prior Art. ........................ 9 
`Level of Ordinary Skill in the Art ....................................................... 12 
`B. 
`Claim Construction ............................................................................. 12 
`C. 
`VI.  Grounds of Unpatentability .......................................................................... 12 
`A.  Ground 1: Claims 1, 4-5, and 7 are Obvious over Ishiyama and
`Murakawa. ........................................................................................... 12 
`1. 
`Overview of U.S. Patent 6,904,466 (Ishiyama) ....................... 13 
`2. 
`The Examiner Incorrectly Applied Ishiyama During
`Prosecution. .............................................................................. 18 
`Overview of the Combination of Ishiyama and U.S.
`Patent 7,028,337 (Murakawa) .................................................. 21 
`The Combination of Ishiyama and Murakawa Renders
`Claim 1 Obvious. ..................................................................... 24 
`The Combination of Ishiyama and Murakawa Renders
`Claim 7 Obvious. ..................................................................... 47 
`The Combination of Ishiyama and Murakawa Renders
`Claim 4 Obvious. ..................................................................... 54 
`The Combination of Ishiyama and Murakawa Renders
`Claim 5 Obvious. ..................................................................... 59 
`
`7. 
`
`
`
`- i -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 2
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`B. 
`
`C. 
`
`2. 
`
`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`Ground 2: Claims 2 and 3 are Obvious over Ishiyama,
`Murakawa, and Ahonen. ..................................................................... 59 
`1. 
`Overview of the Combination of Ishiyama, Murakawa,
`and U.S. Patent No. 6,976,177 (Ahonen) ................................ 59 
`The Combination of Ishiyama, Murakawa, and Ahonen
`Renders Claims 2 and 3 Obvious. ............................................ 63 
`Ground 3: Claim 6 is Obvious over Ishiyama, Murakawa, and
`Forslöw. ............................................................................................... 66 
`VII.  Conclusion .................................................................................................... 70 
`
`
`
`
`
`
`
`
`- ii -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 3
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`
`EXHIBIT LIST
`
`Apple (EX)
`Exhibit # Description
`U.S. Patent No. 7,620,810 (“’810 patent”).
`1001
`Declaration of Dr. David Goldschlag in Support of Petition for
`Inter Partes Review of U.S. Patent No. 7,620,810 (“Goldschlag
`Decl.”).
`Prosecution History of U.S. Patent No. 7,620,810 (“Prosecution
`History”).
`U.S. Patent No. 6,904,466 to Ishiyama et al. (“Ishiyama”).
`U.S. Patent No. 7,028,337 to Murakawa (“Murakawa”).
`U.S. Patent No. 6,976,177 to Ahonen (“Ahonen”).
`U.S. Patent No. 6,954,790 to Forslöw (“Forslöw”).
`
`1002
`
`1003
`
`1004
`1005
`1006
`1007
`1008
`
`Demystifying the IPsec Puzzle, Sheila Franklel, Published 2001.
`IP Security - The Internet Protocol Journal – Volume 3, No. 1,
`William Stallings, Published March 2000.
`Mobility-aware IPsec ESP tunnels, Francis Dupont, IETF Draft
`Posted February 22, 2001. https://tools.ietf.org/html/draft-dupont-
`movesptun-00 (“Dupont”).
`RFC2401 - S. Kent, and R. Atkinson, Security Architecture for the
`Internet Protocol, RFC2401, November 1998.
`https://tools.ietf.org/html/rfc2401.html (“RFC2401”).
`RFC793 – Information Science Institute, Transmission Control
`Protocol, September 1981 (“RFC793”).
`U.S. Patent No. 7,079,499 to Akhtar et al. (“Akhtar”).
`U.S. Patent No. 7,174,018 to Patil et al. (“Patil”).
`U.S. Patent No. 6,418,130 to Cheng et al. (“Cheng”).
`Curriculum Vitae of Dr. David Goldschlag.
`Declaration of Sandy Ginoza for IETF (Regarding RFC2401 and
`RFC793).
`Declaration of Alexa Morris for IETF (Regarding “Mobility-aware
`IPsec ESP tunnels” by Dupont)
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`1014
`1015
`1016
`
`1017
`
`1018
`
`
`
`- iii -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 4
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`
`I.
`
`Introduction
`Apple Inc. petitions for inter partes review of claims 1-7 of United States
`
`Patent No. 7,620,810 (“’810 patent”) to Vaarala et al., titled “Method and Network
`
`for Ensuring Secure Forwarding of Messages.” Ex. 1001, ’810 patent. The Petition
`
`demonstrates that all 7 claims of the ’810 patent are unpatentable.
`
`The ’810 patent allegedly solved Internet Protocol Security (“IPSec”)
`
`operability problems for mobile devices. As will be further clarified below, it does
`
`not. Rather, IPSec problems were well-known and solved long before the earliest
`
`priority date of the ’810 patent. See, e.g., Ex. 1008, Frankel, 3, 129-132; Ex. 1010,
`
`Dupont, 1; Ex. 1002, Goldschlag Decl., ¶¶29-46. IPSec refers to a set of protocols
`
`developed in the early 1990s that provides for the establishment and maintenance
`
`of secure communication channels between devices. IPSec was not developed for
`
`mobile devices and operability problems arose when attempts were made to apply
`
`IPSec to mobile devices. Specifically, as mobile devices roam between networks,
`
`their IP addresses change. See Goldschlag Decl., ¶¶29-46. This presented a
`
`problem for IPSec because it relies on fixed IP addresses for the endpoints of a
`
`connection. Id. Because of this IPSec limitation, a mobile device needed to
`
`renegotiate its connection as it traveled between networks and obtained new IP
`
`addresses, which was inefficient and resulted in connection issues. Id.
`
`
`
`- 1 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 5
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`The ’810 patent allegedly solves this problem by having a mobile device
`
`send a message to the other end of a secure connection to update the mobile
`
`device’s address when the address changes. Not only is this solution trivial, but it
`
`was also explicitly disclosed by U.S. Patent No. 6,904,466 (“Ishiyama”) prior to
`
`the earliest priority date of the ’810 patent. Additionally, U.S. Patent Nos.
`
`7,028,337 (“Murakawa”), 6,976,177 (“Ahonen”), and 6,954,790 (“Forslöw”)
`
`explain other well-known and simple elements of the claims that would have been
`
`known to a person of ordinary skill in the art (“POSITA”), such as connecting the
`
`mobile device to another device via a security gateway, sending a reply message,
`
`and connecting two mobile devices.
`
`Accordingly, there is at least a reasonable likelihood that at least one claim
`
`of the ’810 patent is unpatentable, as shown herein. As such, Petitioner respectfully
`
`requests that the Board Institute trial on the grounds set forth herein and ultimately
`
`determine that all claims of the ’810 patent are invalid.
`
`II. Mandatory Notices (37 C.F.R. § 42.8)
`Real Party In Interest: The real party-in-interest of the Petition is Apple
`
`Inc. (“Apple”).
`
`Related Matters: Pursuant to 37 C.F.R. § 42.8(b)(2), the ’810 patent is
`
`involved in the following proceeding that may affect or be affected by a decision in
`
`this proceeding: MPH Technologies Oy v. Apple Inc., Case No. 5:18-cv-05935-
`
`
`
`- 2 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 6
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`PJH (N.D. Cal.), filed September 27, 2018. U.S. Patent No. 7,937,581 (“’581
`
`patent”), issued May 3, 2011, claims the benefit of the ’810 patent. A Petition for
`
`inter partes review has been filed against the ’581 patent and the corresponding
`
`proceeding may be affected by the decision in this proceeding.
`
`Lead and Backup Counsel: Pursuant to 37 C.F.R. § 42.8(b)(3) and
`
`42,10(a), Petitioner appoints Michael D. Specht (Reg. No. 54,463) as its lead
`
`counsel and Daniel S. Block (Reg. No. 68,395) and Timothy L. Tang (Reg. No.
`
`75,187) as its back-up counsel, all at the address: STERNE, KESSLER,
`
`GOLDSTEIN & FOX, 1100 New York Avenue, N.W., Washington, D.C., 20005,
`
`phone number (202) 371-2600 and facsimile (202) 371-2540.
`
`Service Information: Petitioner consents to electronic service by email at
`
`the
`
`email
`
`addresses: MSPECHT-ptab@sternekessler.com, DBLOCK-
`
`ptab@sternekessler.com,
`
`TTang-ptab@sternekessler.com,
`
`and
`
`PTAB@sternekessler.com.
`
`III. Grounds for Standing (37 C.F.R. § 42.104(a))
`The undersigned and Apple certify that the ’810 patent is available for inter
`
`partes review. Pursuant to 37 C.F.R. § 42.104(a), Petitioner certifies that the ’810
`
`patent is available for inter partes review and that Petitioner is not barred or
`
`estopped from requesting an inter partes review challenging the claims of the ’810
`
`patent on the grounds identified herein.
`
`
`
`- 3 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 7
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`IV.
`
`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`Identification of Challenge (37 C.F.R. § 42.104(b))
`A.
`Petitioner requests review of claims 1-7 on the following grounds:
`
`Statutory Grounds for the Challenge
`
`Ground 1: Claims 1, 4-5, and 7 are unpatentable under 35 U.S.C. § 103 as
`
`obvious over U.S. Patent No. 6,904,466 to Ishiyama, et al. and U.S. Patent No.
`
`7,028,337 to Murakawa.
`
`Ground 2: Claims 2 and 3 are unpatentable under 35 U.S.C. § 103 as
`
`obvious over Ishiyama, Murakawa, and U.S. Patent No. 6,976,177 to Ahonen.
`
` Ground 3: Claim 6 is unpatentable under 35 U.S.C. § 103 as obvious over
`
`Ishiyama, Murakawa, and U.S. Patent No. 6,954,790 to Forslöw.
`
`B. Citation of Prior Art
`The PCT application corresponding to the ’810 patent entered the U.S.
`
`national phase on September 27, 2002 as U.S. Application No. 10/490,932. The
`
`PCT application claims priority to a foreign application having a priority date of
`
`September 28, 2001. The following prior art documents applied on the grounds of
`
`unpatentability were published and/or filed prior to the ’810 patent’s earliest
`
`priority date of September 28, 2001.
`
`Petitioner cites to the following prior art references:
`
`U.S. Patent No. 6,904,466 to Ishiyama, et al. (Ex. 1004) is prior art under at
`
`least pre-AIA 35 U.S.C. § 102(e) because it was filed on May 19, 2000, more than
`
`one year before the earliest possible priority date of the ’810 patent.
`
`
`
`- 4 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 8
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`U.S. Patent No. 7,028,337 to Murakawa (Ex. 1005) is prior art under at least
`
`pre-AIA 35 U.S.C. §§ 102(a), 102(b), and 102(e) because it was filed on December
`
`1, 2000 and published September 6, 2001, both dates being before the earliest
`
`priority date of the ’810 patent.
`
`U.S. Patent No. 6,976,177 to Ahonen (Ex. 1006) is prior art under at least
`
`pre-AIA 35 U.S.C. §§ 102(a), 102(b), and 102(e) because it was filed on January
`
`18, 2001 and published on July 19, 2001, both dates being before the earliest
`
`priority date of the ’810 patent.
`
`U.S. Patent No. 6,954,790 to Forslöw (Ex. 1007) is prior art under at least
`
`pre-AIA 35 U.S.C. §102(e) because it was filed on December 5, 2000, more than
`
`one year before the PCT priority date of the ’810 patent.
`
`V. The ’810 Patent
`A. Overview of the ’810 Patent
`The ’810 patent generally relates to using IPSec with mobile hosts. ’810
`
`patent, Abstract, 7:1-6. “The IP Security protocols (IPSec) provides the capability
`
`to secure communications between arbitrary hosts” using negotiated encryption
`
`keys. Id., 1:57-58. These encryption keys are typically negotiated in an automated
`
`fashion using a protocol known as “Internet Key Exchange” or IKE. Id., 4:3-5.
`
`One limitation of IPSec, according to the ’810 patent, is that it is intended to
`
`work in situations where hosts have fixed IP addresses. Id., 4:9-13. This is because
`
`
`
`- 5 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 9
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`the negotiated encryption keys for the IPSec connection are stored in a structure
`
`referred to as a “security association (SA)” and the “SAs are bound to static
`
`addresses.” See id., 4:47-58. This creates a problem for mobile hosts, according to
`
`the ’810 patent, because the mobile host will change IP addresses when it moves
`
`between networks. Id., 4:12-15. And as a result of this change in address “the IKE
`
`key exchange will have to be redone [for] every new visited network” Id., 4:15-18.
`
`“This is problematic, because IKE key exchanges involve computationally
`
`expensive…calculations.” Id., 4:17-20. Further, re-establishing an IPSec SA may
`
`result in an interruption of service due to the many messages required for a full re-
`
`negotiation of the SA. See id., 9:40-46.
`
`The ’810 patent aims to solve these alleged problems by simply updating the
`
`SA with the new address when the mobile terminal changes addresses.
`
`Specifically, according to the ’810 patent, a “first terminal” may have a secure
`
`connection with another terminal. Id., Abstract. “When the first terminal moves
`
`from the first address to the second address, the connection is changed to be
`
`between the second address and [] the other terminal by means of a request from
`
`the first terminal….” Id.
`
`The ’810 patent also describes an embodiment of this communication
`
`process using a “security gateway.” See id., 8:53-64. Figure 1 as annotated below
`
`depicts this embodiment. “Computer 1 may be a client computer and computer 2 a
`
`
`
`- 6 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 10
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`destination computer, to which the secure messages are sent….” Id., 8:54-58.
`
`“Computer 2 might be a security gateway for a third computer 3.” Id., 8:58-59.
`
`“The security gateway can be a common security gateway for e.g., a company
`
`LAN, whereby there are several computers in the LAN protected by computer 2.”
`
`Id., 8:60-63.
`
`’810 patent, FIG. 1 (annotated).
`
`
`
`The ’810 patent explains that “an IPSec tunnel [is] established between
`
`computer 1 and computer 2.” Id., 8:57-58. The IPSec tunnel represents a secure
`
`standard protocol connection more thoroughly discussed in the “Technical
`
`Background” section of the ’810 patent. When computer 1 changes to a new
`
`address, computer 1 sends a message with the new address to computer 2, and
`
`computer 2 updates the definition of the IPSec tunnel. See id., 7:29-37, 8:60-9:7,
`
`
`
`- 7 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 11
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`9:14-19, 9:63-10:2. It is this update message that the ’810 patent alleges is its
`
`inventive concept. See id., 7:33-40.
`
`The ’810 Patent Admitted Prior Art.
`
`1.
`The ’810 patent includes a lengthy Technical Background section that
`
`admits a number of aspects of the alleged invention of the ’810 patent were known.
`
`For example, the ’810 patent explains the Internet Protocol Security (“IPsec”) was
`
`a well-known standard framework that “provides the capability to secure
`
`communications between arbitrary hosts, e.g., across a LAN, across private and
`
`public wide area networks (WANs)….” ’810 patent, 1:57-59. IPSec could be used
`
`in a number of ways, “such as for building secure virtual private networks, to gain
`
`a secure access to a company network, or to secure communication with other
`
`organisations, ensuring authentication and confidentiality and providing a key
`
`exchange mechanism.” Id., 1:61-64.
`
`Importantly, the ’810 patent also admits that the IPsec standard “support[s]
`
`two modes…transport and tunnel mode.” Id., 3:8-9. “Typically, transport mode is
`
`used for end-to-end communication between two hosts.” Id., 3:12-13 (emphasis
`
`added). In contrast, “[t]unnel mode is often used when one or both ends of a SA is
`
`a security gateway, such as a firewall or a router that implements IPSec.”1
`
`1 ’810 patent, 3:19-21 (emphasis added); see also id., 2:6-10, 5:59-62 (citing
`
`Ex. 1011, RFC2401, 9 (“A tunnel mode SA is essentially an SA applied to an IP
`
`
`
`- 8 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 12
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`The Examiner Misapplied References During Prosecution
`in View of the Admitted Prior Art.
`
`2.
`
`The Examiner considered several references during prosecution, but
`
`appeared to misunderstand the fundamentals of the underlying IPSec technology,
`
`as well as the admitted prior art underlying the subject matter of the ’810 patent.
`
`Initially, the Examiner rejected the claims over U.S. 6,587,680 to Ala-
`
`Laurila et al. Ex. 1003, Prosecution History, 0119-0124. This forced the Applicant
`
`to amend the claims, adding the limitation of a mobile terminal moving from a first
`
`address to a second address and sending a request to an “other terminal” to change
`
`the address definition of the secure connection. Id., 0129-0138. The Applicant then
`
`argued that Ala-Laurila failed to teach the added limitations because Ala-Laurila’s
`
`mobile device would never send a request to the host the Examiner alleged was the
`
`“other terminal.” Id., 0134-0136. Ultimately, the Examiner agreed and issued
`
`several rejections before issuing a rejection including the combination of Ala-
`
`Laurila and Ishiyama. Id., 0214-0220.
`
`In response to this rejection, the Applicant amended the claims to add a
`
`“security gateway” between the mobile terminal and other terminal and to require
`
`
`tunnel. Whenever either end of a security association is a security gateway, the SA
`
`MUST be tunnel mode. Thus an SA between two security gateways is always a
`
`tunnel mode SA, as is an SA between a host and a security gateway.”)).
`
`
`
`- 9 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 13
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`that the mobile device send a “request” to change the address to a security
`
`gateway, instead of the “other terminal.” Id., 0227-0239. The Applicant further
`
`argued that “Ishiyama merely teaches an updating of the mobile computer address
`
`and there is no teaching or suggestion of the correspondent being a security
`
`gateway for another computer.” Id., 0232-0233. Subsequently, the Examiner issued
`
`two new rejections with entirely different references.2 And the Applicant continued
`
`to argue that these new references failed to disclose a security gateway updating
`
`the mobile computer’s address definition of a secure connection, similarly to its
`
`arguments for Ishiyama. Ultimately, because of these arguments the Examiner
`
`allowed the claims.3
`
`But had the Examiner properly understood the underlying IPSec technology,
`
`the Examiner would never have had needed any new references after applying
`
`Ishiyama, as the Examiner should have determined that it was well understood to
`
`POSITAs that the “correspondent node” described in Ishiyama represents an
`
`
`2 See Prosecution History, 0243-0250 (Examiner citing to Ahonen and Luo),
`
`0270-276 (Examiner citing to Ahonen and Inoue).
`
`3 The Examiner never stated his reasons for allowance, instead stating: “No
`
`reason for allowance is needed as the record is clear….” Prosecution History,
`
`0319.
`
`
`
`- 10 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 14
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`endpoint of an IPSec tunnel. See Goldschlag Decl., ¶¶33-36; see also Ex. 1004,
`
`Ishiyama, FIG. 4, 12:15-25. Further, Ishiyama explicitly states that “the tunnel
`
`mode of the IPSEC [standard] will be utilized for communications between the
`
`moving mobile computer 2 and the correspondent host 3.” Ishiyama, 7:45-49.
`
`Indeed, as was well known to POSITAs at the time, and admitted in the Technical
`
`Background of the ’810 patent, “[t]unnel mode is often used when one or both ends
`
`of a SA is a security gateway.”4 In view of this understanding, a POSITA would
`
`have understood that the “correspondent node” in Ishiyama would be a security
`
`gateway communicating with “mobile computer 2” via the established IPSec
`
`tunnel. The Examiner, however, did not consider this when applying Ishiyama in
`
`the Office Action. Instead, the Examiner allowed the claims in view of two other
`
`references and the Applicant’s arguments that the two other references did not
`
`recite “the security gateway changing an address definition of the secure
`
`connection from the first address to the second address” where “the address
`
`
`4 ’810 patent, 3:19-21 (emphasis added); see also id., 2:6-10, 5:59-62 (citing
`
`RFC2401, 9 (“A tunnel mode SA is essentially an SA applied to an IP tunnel.
`
`Whenever either end of a security association is a security gateway, the SA MUST
`
`be tunnel mode. Thus an SA between two security gateways is always a tunnel
`
`mode SA, as is an SA between a host and a security gateway.”)).
`
`
`
`- 11 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 15
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`definition of the same secure connection is changed from the first address to the
`
`second address.” Prosecution History, 0290 (emphasis in the original).
`
`Level of Ordinary Skill in the Art
`
`B.
`A person having ordinary skill in the art (“POSITA”) would have had a B.S.
`
`degree in Computer Engineering, Electrical Engineering, or an equivalent field, as
`
`well as at least 3-5 years of academic or industry experience in the Internet security
`
`industry. Goldschlag Decl., ¶¶20-21.
`
`C. Claim Construction
`In an inter partes review, claims are “construed using the same claim
`
`construction standard that would be used to construe the claim in a civil action
`
`under 35 U.S.C. 282(b).” 37 C.F.R. §42.100(b). Claims must be given their
`
`ordinary and customary meaning as understood by one of ordinary skill in the art at
`
`the time of the invention in light of the specification and the prosecution history
`
`pertaining to the patent. Id.; Phillips v. AWH Corp., 415 F.3d 1303, 1312-1313
`
`(Fed. Cir. 2015) (en banc); see also 83 Fed. Reg. 51,340. All claim terms of the
`
`’810 patent should receive their ordinary and customary meaning.
`
`VI. Grounds of Unpatentability
`A. Ground 1: Claims 1, 4-5, and 7 are Obvious over Ishiyama and
`Murakawa.
`
`Ishiyama discloses each and every limitation of claims 1, 4-5, and 7.
`
`Ishiyama does not, however, expressly state that an “other terminal” receives a
`
`
`
`- 12 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 16
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`message beyond a security gateway. While this limitation would be obvious in
`
`view of the disclosed system in Ishiyama as well as the admitted prior art in the
`
`Technical Background of the ’810 patent, Murakawa expressly discloses the “other
`
`terminal” and the routing of message from the mobile terminal to the other
`
`terminal via the security gateway. As explained in further detail below, it would
`
`have been obvious to a POSITA at the time of filing the ’810 patent to combine
`
`Ishiyama and Murakawa.
`
`1. Overview of U.S. Patent 6,904,466 (Ishiyama)
`Similar to the ’810 patent, Ishiyama describes a “mobile communication
`
`scheme capable of easily changing a connected location of a mobile computer….”
`
`Ishiyama, 2:43-44. Just like the ’810 patent, Ishiyama accomplishes this goal by
`
`updating an address corresponding to the mobile computer while “the [other]
`
`security association information…remain[s] unchanged, so that there is no need to
`
`re-negotiate keys for IPSEC encryption and authentication….” Id., 9:5-8. In this
`
`manner, Ishiyama describes the same alleged solution as the ’810 patent with the
`
`same effect as the ’810 patent—avoiding the re-establishment of IPSec SAs. See
`
`’810 patent, 9:12-15, 9:40-43, 10:20-23.
`
`Specifically, Ishiyama explains that a secure connection is established
`
`between a mobile computer (i.e., a mobile terminal) and a correspondent node (i.e.,
`
`a security gateway): “the mobile computer 2 carries out communications here by
`
`
`
`- 13 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 17
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`using this acquired Care-of address (CoA1) as an address (gateway address)
`
`indicating one endpoint of the tunnel according to the tunnel mode IPSEC
`
`communications.” Ishiyama, 8:42-47. A POSITA would have understood that the
`
`“correspondent node” is a “security gateway” because IPSec tunnel mode is used.
`
`See Goldschlag Decl., ¶¶33-36.
`
`Next, just like in the ’810 patent, the mobile computer moves across
`
`networks, and its address changes. See Ishiyama, 8:55-57. And when the address of
`
`the mobile computer changes, just like the ’810 patent, Ishiyama discloses that the
`
`mobile computer sends an update message: “[the mobile computer] notif[ies] a
`
`change of the current location address of the mobile computer from the mobile
`
`computer to [a] correspondent computer by setting a new current location address
`
`as the source address….” Id., 2:63-66. The correspondent computer then
`
`“updat[es] the current location address used as a termination endpoint address of
`
`the tunnel…at the correspondent computer into the new current location address,
`
`when the change of the current location address to the new current location address
`
`is notified from the mobile computer.” Id., 3:9-3:14. Thus, “[w]hen the mobile
`
`computer moves, the Care-of address is changed so that the termination endpoint
`
`of the IPSEC tunnel also changes, but it is possible to guarantee the mobility
`
`without interrupting the session by notifying the changed IPSEC tunnel terminal
`
`endpoint to the IPSEC module of the correspondent and changing the tunnel
`
`
`
`- 14 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 18
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`termination address in a security related database.” Id., 6:54-58 (emphasis
`
`added).
`
`Figure 2 and Figure 4 further depict this operation.
`
`Ishiyama, FIG. 2 (annotated).
`
`
`
`As seen in Figure 2, “a mobile computer 2 that belongs to the home network
`
`1a has moved to another network 1b…and carries out communications with a
`
`correspondent host 3…that is located in the network 1c.” Id., 7:33-39. In the
`
`annotated Figure 2 above, the dashed red box represents the mobile terminal at a
`
`first address corresponding to network 1a while the solid red box represents the
`
`mobile terminal at a second address corresponding to network 1b. Figure 2
`
`illustrates the movement of the mobile terminal. “In this embodiment, the tunnel
`
`
`
`- 15 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 19
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`mode of the IPSEC will be utilized for communications between the moving
`
`mobile computer 2 and the correspondent host 3.” Id., 7:45-48.
`
`Ishiyama, FIG. 4 (annotated).
`
`
`
`“FIG. 4 shows an exemplary situation in which a packet is transferred from
`
`the mobile computer 2 to the correspondent host 3 using the IPSEC tunnel.” Id.,
`
`8:33-35. The mobile computer may first be communicating with the correspondent
`
`host using “[c]are-of address (CoA1) as an address (gateway address) indicating
`
`one endpoint of
`
`the
`
`tunnel according
`
`to
`
`the
`
`tunnel mode
`
`IPSEC
`
`communications….” Id., 8:42-46. The mobile computer may then move to another
`
`network as annotated in Figure 4 above by the movement of the mobile terminal
`
`from the dashed red box to the solid red box.“[W]hen the mobile computer 2
`
`
`
`- 16 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 20
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`moves further[,] the Care-of address is changed from ‘CoA1’ to ‘CoA2’….” Id.,
`
`8:55-57. “[T]he mobile computer 2 changes the source address of the outer packet
`
`of the encapsulated packet to be transmitted to the IPSEC tunnel by the mobile
`
`computer 2 into ‘CoA2’ at a timing when the Care-of address is changed to
`
`‘CoA2.’ As a result, as shown in Figure 4, the encapsulated packet in which the
`
`outer packet has the source address =‘CoA2’ will be transferred.” Id., 8:59-65.
`
`“The correspondent host 3…then replace[s] the destination gateway address
`
`‘CoA1’ used so far in this session by a new one ‘CoA2’ by referring to the IPSEC
`
`security association (security related information) database (see FIG. 9B and FIG.
`
`9D).” Id., 8:66-9:4. “[M]obile computer 2 carries out the SA Gateway Update with
`
`respect to this correspondent host ‘CN’…. As a result, the contents of the
`
`corresponding security association SAC1 of FIG. 9B at the correspondent host
`
`‘CN’ is updated as shown in FIG. 9D.” Id., 12:51-59.
`
`
`
`- 17 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 21
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`
`
`
`
`
`Ishiyama, FIGs. 9B and 9D (annotated).
`
`“As a result of these operations, at the correspondent [node] currently
`
`communicating with the mobile computer 2, the endpoint of the IPSEC tunnel is
`
`changed from ‘CoA1’ to ‘CoA2’ as the destination of all the security associations
`
`is changed to the current CoA ‘CoA2’. Id., 12:66-13:3. In view of the CoA
`
`updating, “the security association information other than the gateway address will
`
`remain unchanged, so that there is no need to re-negotiate keys for IPSEC
`
`encryption and authentication….” Id., 9:5-8.
`
`2.
`
`The Examiner Incorrectly Applied Ishiyama During
`Prosecution.
`
`Ishiyama was considered during prosecution by the Examiner, but only as a
`
`secondary reference. Moreover, the Examiner did not properly apply Ishiyama’s
`
`
`
`- 18 -
`
`MPH Technologies Oy, Exhibit 2003
`Page 2003 - 22
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,620,810
`t