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

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`
`TABLE OF CONTENTS
`
`V.
`
`
`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 ’581 Patent ............................................................................................... 5
`A. Overview of the ’581 Patent .................................................................. 5
`1.
`’581 Patent Admitted Prior Art .................................................. 8
`2.
`The Examiner Did Not Conduct a Thorough Examination
`During Prosecution .................................................................... 9
`Level of Ordinary Skill in the Art ....................................................... 11
`B.
`Claim Construction ............................................................................. 11
`C.
`VI. Grounds of Unpatentability .......................................................................... 11
`A. Ground 1: Claims 1-2, 4, 6-7, and 9 are Obvious over Ishiyama
`and Murakawa ..................................................................................... 11
`1.
`Overview of U.S. Patent 6,904,466 (Ishiyama) ....................... 12
`2.
`Overview of the Combination of Ishiyama and U.S.
`Patent 7,028,337 (Murakawa) .................................................. 17
`The combination of Ishiyama and Murakawa renders
`claim 1 obvious. ....................................................................... 20
`The combination of Ishiyama and Murakawa renders
`claim 9 obvious. ....................................................................... 40
`The combination of Ishiyama and Murakawa renders
`claim 2 obvious. ....................................................................... 47
`The combination of Ishiyama and Murakawa renders
`claim 4 obvious. ....................................................................... 48
`The combination of Ishiyama and Murakawa renders
`claim 6 obvious. ....................................................................... 50
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`
`
`- i -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`The combination of Ishiyama and Murakawa renders
`claim 7 obvious. ....................................................................... 54
`Ground 2: Claims 3 and 5 are Obvious over Ishiyama,
`Murakawa, and Ahonen ...................................................................... 54
`1.
`Overview of the Combination of Ishiyama, Murakawa,
`and U.S. Patent 6,976,177 (Ahonen) ....................................... 54
`The combination of Ishiyama, Murakawa, and Ahonen
`renders claims 3 and 5 obvious. ............................................... 58
`Ground 3: Claim 8 is Obvious over Ishiyama, Murakawa, and
`Forslöw ................................................................................................ 61
`VII. Conclusion .................................................................................................... 65
`
`
`
`B.
`
`C.
`
`8.
`
`2.
`
`
`
`
`
`- ii -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`
`EXHIBIT LIST
`
`1002
`
`Apple (EX)
`Exhibit # Description
`U.S. Patent No. 7,937,581 to Vaarala et al. (“’581 patent”)
`1001
`Declaration of Dr. David Goldschlag in Support of Petition for
`Inter Partes Review of U.S. Patent No. 7,937,581 (“Goldschlag
`Decl.”)
`Prosecution History of U.S. Patent No. 7,937,581 (“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”)
`
`1003
`
`1004
`1005
`1006
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`1014
`1015
`1016
`
`1017
`
`1018
`
`1019
`
`S. Frankel, Demystifying the IPsec Puzzle, Artech House, Inc.,
`2001 (“Frankel”)
`W. Stallings, IP Security - The Internet Protocol Journal – Volume
`3, No. 1, March 2000 (“Stallings”)
`Mobility-aware IPsec ESP tunnels, Francis Dupont, IETF Draft
`Posted February 22, 2001 (“Dupont”)
`RFC2401 - S. Kent, and R. Atkinson, Security Architecture for the
`Internet Protocol, RFC2401, The Internet Society, November 1998
`(“RFC2401”)
`RFC793 - Transmission Control Protocol, Darpa Internet Program
`Protocol Specification, 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) (“Ginoza Decl.”)
`Declaration of Alexa Morris for IETF (Regarding “Mobility-aware
`IPsec ESP tunnels” by Dupont) (“Morris Decl.”)
`U.S. Patent No. 7,620, 810 to Vaarala, et al. (“Vaarala”)
`
`
`
`- iii -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`
`Apple (EX)
`Exhibit # Description
`Prosecution History of U.S. Patent No. 7,620, 810 (“’810
`1020
`Prosecution History”)
`
`
`
`
`
`- iv -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`
`I.
`
`Introduction
`Apple Inc. petitions for inter partes review of claims 1-9 of United States
`
`Patent No. 7,937,581 (“’581 patent”) to Vaarala et al., titled “Method and Network
`
`for Ensuring Secure Forwarding of Messages.” Ex. 1001, ’581 patent. The Petition
`
`demonstrates that all 9 claims of the ’581 patent are unpatentable.
`
`The ’581 patent is a continuation of U.S. Patent No. 7,620,810 (“’810
`
`patent,” Ex. 1019) and allegedly solved Internet Protocol Security (IPSec)
`
`operability problems for mobile devices. It did not. Rather, IPSec problems were
`
`well-known and solved long before the earliest priority date of the ’581 patent. See,
`
`e.g., Ex. 1008, Frankel, 3, 129-132; Ex. 1010, Dupont, 1; Ex. 1002, Goldschlag
`
`Decl., ¶¶40-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.
`
`(Id.) This presented a problem for IPSec because it relies on having 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 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`The ’581 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 ’581 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 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 a reasonable likelihood that at least one claim of the
`
`’581 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 ’581 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 ’581 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. 4:18-cv-05935-
`
`
`
`- 2 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`PJH (N.D. Cal.), filed September 27, 2018. A Petition for inter partes review has
`
`been filed against the ’810 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 ’581 patent is available for inter
`
`partes review. Pursuant to 37 C.F.R. § 42.104(a), Petitioner certifies that the ’581
`
`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 ’581
`
`patent on the grounds identified herein.
`
`
`
`- 3 -
`
`

`

`IV.
`
`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`Identification of Challenge (37 C.F.R. § 42.104(b))
`A.
`Petitioner requests review of claims 1-9 on the following grounds:
`
`Statutory Grounds for the Challenge
`
`Ground 1: Claims 1-2, 4, 6-7, and 9 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 3 and 5 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 8 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 ’581 patent is a continuation of the ’810 patent. The PCT application
`
`corresponding to the ’810 patent was filed on September 27, 2002 and entered the
`
`U.S. national phase on November 22, 2004 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 ’581 patent’s earliest
`
`priority date of September 28, 2001.
`
`Petitioner cites to the following prior art references:
`
`
`
`- 4 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`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 ’581 patent.
`
`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 as US 2001/0020273 A1, both dates
`
`being before the earliest priority date of the ’581 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 as US 2001/0009025, both dates being
`
`before the earliest priority date of the ’581 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 ’581 patent.
`
`V. The ’581 Patent
`A. Overview of the ’581 Patent
`The ’581 patent generally relates to using IPSec with mobile hosts. ’581
`
`patent, Abstract, 6:62-67. “The IP Security protocols (IPSec) provides the
`
`capability to secure communications between arbitrary hosts” using negotiated
`
`encryption keys. ’581 patent, 1:59-60. These encryption keys are typically
`
`
`
`- 5 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`negotiated in an automated fashion using a protocol known as “Internet Key
`
`Exchange” or IKE. Id., 4:6-7.
`
`One limitation of IPSec, according to the ’581 patent, is that it is intended to
`
`work in situations where hosts have fixed IP addresses. Id., 4:12-15. This is
`
`because 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:50-60. This creates a problem for mobile hosts,
`
`according to the ’581 patent, because the mobile host will change IP addresses
`
`when it moves between networks. Id., 4:15-20. 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:19-21. “This is problematic, because IKE key exchanges involve
`
`computationally expensive...calculations.” Id., 4:21-22. 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:29-35.
`
`The ’581 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 ’581 patent, a “first terminal” may have a secure
`
`connection with another terminal. Id., Abstract. “When the first terminal moves
`
`from the first address to a second address, the connection is changed to be between
`
`
`
`- 6 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`the second address and [] the other terminal by means of a request from the first
`
`terminal….” Id.
`
`The ’581 patent also describes an embodiment of this communication
`
`process using a “security gateway.” See id., 8:50-61. Figure 1 as annotated below
`
`depicts this embodiment. “Computer 1 may be a client computer and computer 2 a
`
`destination computer, to which the secure messages are sent…” Id., 8:51-55.
`
`“Computer 2 might be a security gateway for a third computer 3.” Id., 8:55-56.
`
`“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:57-60.
`
`’581 patent, FIG. 1 (annotated).
`
`
`
`The ’581 patent explains that “an IPSec tunnel [is] established between
`
`computer 1 and computer 2.” Id., 8:54-55. The IPSec tunnel represents a secure
`
`
`
`- 7 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`standard protocol connection more thoroughly discussed in the “Technical
`
`Background” section of the ’581 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:24-35, 8:57-63,
`
`9:5-8, 9:60-66. The ’581 patent alleges that using this update message to change
`
`the endpoint of the IPSec tunnel is its inventive concept. See id., 7:28-34.
`
`’581 Patent Admitted Prior Art
`
`1.
`The ’581 patent includes a lengthy Technical Background section that
`
`admits a number of aspects of the alleged invention of the ’581 patent were known.
`
`For example, the ’581 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)…” ’581 patent, 1:59-61. 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:63-66.
`
`Importantly, the ’581 patent also admits that the IPSec standard “support[s]
`
`two modes… transport and tunnel mode.” Id., 3:10-11. “Typically, transport mode
`
`is used for end-to-end communication between two hosts.” Id., 3:14-15. In
`
`
`
`- 8 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`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
`
`2.
`
`The Examiner Did Not Conduct a Thorough Examination
`During Prosecution
`
`The Examiner only applied two references during prosecution of the ’581
`
`patent. This sparse examination is similar to the final rejection applied during the
`
`examination of the parent ’810 patent, where the Examiner applied the same
`
`references as in the ’581 patent.2
`
`The single Office Action applied during examination of the ’581 patent
`
`included a double patenting rejection over the claims of the ’810 patent and an
`
`obviousness rejection over the same references applied during examination of the
`
`
`1 ’581 patent, 3:22-24, see also 2:9-12, 5:54-57 (citing Ex. 1011, 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.”).)
`
`2 See Office Action date August 17, 2010; see also Office Action from ’810
`
`patent dated May 12, 2009, Examiner citing to Ahonen and Inoue. Ex. 1003,
`
`Prosecution History, 0077-0081; Ex. 1020, ’810 Prosecution History, 0272-0276.
`
`
`
`- 9 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`’810 patent.3 The Applicant responded by filing a terminal disclaimer and
`
`amending the claims. Prosecution History, Reply dated November 23, 2010, 0052-
`
`0069.
`
`The Applicant also argued that the references did not teach “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 address of the security gateway” and
`
`“in response to the request message from the mobile terminal, the security gateway
`
`changing an address definition of the secure connection from the first address to
`
`the second address.” Id., Reply dated November 23, 2010, 0057. Ultimately,
`
`because of these arguments and in view of the terminal disclaimer, the Examiner
`
`allowed the claims.4
`
`
`3 See Office Action date August 17, 2010; see also Office Action from ’810
`
`patent dated May 12, 2009, Examiner citing to Ahonen and Inoue. Ex. 1003,
`
`Prosecution History, 0077-0081; Ex. 1020, ’810 Prosecution History, 0272-0276.
`
`4 The Examiner never stated his reasons for allowance, instead stating: “No
`
`reason for allowance is needed as the record is clear….” Prosecution History,
`
`0013.
`
`
`
`- 10 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`
`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
`
`’581 patent should receive their ordinary and customary meaning.
`
`VI. Grounds of Unpatentability
`A. Ground 1: Claims 1-2, 4, 6-7, and 9 are Obvious over Ishiyama
`and Murakawa
`
`Ishiyama discloses each and every limitation of claims 1-2, 4, 6-7, and 9.
`
`Ishiyama does not, however, expressly state that an “other terminal” receives a
`
`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
`
`
`
`- 11 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`Technical Background of the ’581 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 before the earliest priority date of the ’581 patent
`
`to combine Ishiyama and Murakawa.
`
`1. Overview of U.S. Patent 6,904,466 (Ishiyama)
`Similar to the ’581 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 ’581 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…” Ishiyama, 9:5-8. In
`
`this manner, Ishiyama describes the same alleged solution as the ’581 patent with
`
`the same effect as the ’581 patent—avoiding the re-establishment of IPSec SAs.
`
`See ’581 patent, 9:1-4, 9:29-33, 10:17-20.
`
`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
`
`using this acquired Care-of address (CoA1) as an address (gateway address)
`
`indicating one endpoint of the tunnel according to the tunnel mode IPSEC
`
`
`
`- 12 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`communications.” Ishiyama, 8:42-47. A person of ordinary skill in the art would
`
`understand that the “correspondent node” is a “security gateway” because IPSec
`
`tunnel mode is used. Goldschlag Decl., ¶48.
`
`Next, just like in the ’581 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 ’581 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
`
`termination address in a security related database.” Id., 6:54-58; emphasis
`
`added.
`
`
`
`- 13 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`Figures 2 and 4 of Ishiyama (below) 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
`
`mode of the IPSEC will be utilized for communications between the moving
`
`mobile computer 2 and the correspondent host 3.” Id., 7:45-48.
`
`
`
`- 14 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`
`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 “Care-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 FIG. 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 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
`
`
`
`- 15 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`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 FIG. 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.
`
`
`
`
`
`Ishiyama, FIGs. 9B and 9D (annotated).
`
`
`
`- 16 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`“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. Overview of the Combination of Ishiyama and U.S. Patent
`7,028,337 (Murakawa)
`
`A POSITA reading Ishiyama would have understood that Ishiyama renders
`
`obvious the claims of the ’581 patent. Goldschlag Decl., ¶56. It was well-known by
`
`the earliest priority date of the ’581 patent that when one node communicates with
`
`a security gateway using IPSec tunnel mode, it is often to contact a different node.
`
`Goldschlag Decl., ¶57. In fact, that is the entire point of using IPSec tunnel mode,
`
`and the primary function of a security gateway—to de-encapsulate IPSec packets
`
`and forward them to other nodes. Goldschlag Decl., ¶57. This understanding is
`
`further confirmed by the Technical Background of the ’581 patent. (See ’581
`
`patent, 3:19-30.) Based on this well-known understanding of IPSec tunnel mode
`
`that teaches a mobile terminal communicating with a security gateway and an
`
`“other terminal,” a POSITA reading Ishiyama would have understood that
`
`Ishiyama’s address changing technique is the same as the address changing
`
`
`
`- 17 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`technique described in the ’581 patent. Goldschlag Decl., ¶57. In this manner,
`
`Ishiyama renders the claims of the ’581 patent obvious. Id.
`
`Indeed Ishiyama explicitly discloses utilizing its teachings with IPSec tunnel
`
`mode: “In this embodiment, the tunnel mode of IPSEC will be utilized….”
`
`Ishiyama, 7:45-49. If a POSITA was not familiar with IPSec tunnel mode (and the
`
`fact that using IPSec tunnel mode suggests the tunneling of messages from a
`
`mobile terminal to an “other terminal”), the POSITA would have needed to seek
`
`out other references that describe the implementation of IPSec tunnel mode to
`
`implement the teachings of Ishiyama. Murakawa describes the implementation of
`
`IPSec tunnel. Goldschlag Decl., ¶58.
`
`Murakawa describes a “Virtual Private Network (VPN) communication
`
`employed for a security gateway… which allow[s] a personal computer outside a
`
`local area network (LAN) to access… a terminal on the LAN….” Murakawa,
`
`Abstract. Murakawa also illustrates a prior art security gateway configuration
`
`having a mobile terminal and other terminals in Figure 5 as annotated below. This
`
`configuration allows “VPN communication employing IPsec.” Murakawa, 1:50-51
`
`“[S]ecurity gateway 103 includes server terminal 105 and client PCs 106,
`
`107.” Id., 1:59-60 “[I]n order to perform the IPsec communication, VPN 108 is
`
`established between PC 101 and security gateway 103.” Id., 1:61-63. Murakawa
`
`further describes the establishment of a “Security Association (SA) that is a two-
`
`
`
`- 18 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`way logical connection between the both sides.” Id., 2:33-35. Additionally,
`
`Murakawa explains that “security gateway 103 is [] active in the tunnel mode…
`
`[and] the IPsec operating mode is assumed to be the tunnel mode.” Id., 2:62-65. In
`
`view of this background configuration, Murakawa describes an invention that
`
`“allows an outside terminal to communicate with a terminal on the LAN, by
`
`virtually regarding the outside terminal as another terminal on the LAN.” Id., 4:13-
`
`16.
`
`Murakawa, FIG. 5 (annotated).
`
`
`
`
`
`- 19 -
`
`

`

`Petition for Inter Partes Review of
`U.S. Pat. No. 7,937,581
`A POSITA would have understood that Murakawa’s description of a well-
`
`known security gateway configuration provides the relevant context for Ishiyama’s
`
`address changing functionality. Implementing Ishiyama’s address changing
`
`functionality using Murakawa’s security gateway would be merely combining
`
`known elements to yield predictable results. Goldschlag Decl., ¶61. Ishiyama
`
`describes a mobile terminal as well as a correspondent node that may act as a
`
`security gateway. Goldschlag Decl., ¶61; Ishiyama, 11:59-63. Ishiyama also
`
`describes address updating for a mobile terminal operating in the IPSec tunneling
`
`mode. Ishiyama, 7:46-49. As previously described and acknowledged by the
`
`admitted prior art of the ’581 patent, a POSITA would have understood that the use
`
`of tunneling mode suggests the use of a security gateway as an intermediary
`
`between two terminals. (’581 patent, 3:22-24.) Murakawa illustrates this well-
`
`known tunneling of communications through a security gateway so that two
`
`terminals are able to communicate. Murakawa, 4:13-16. Thus, it would have been
`
`predictable to implement Ishiyama’s address changing functionality using the well-
`
`known