Paper 37
`Trials@uspto.gov
`Entered: September 24, 2020
`Tel: 571-272-7822
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`APPLE INC.,
`Petitioner,
`v.
`MPH TECHNOLOGIES OY,
`Patent Owner.
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`__________________________
`
`
`
`
`
`
`
`Before KAMRAN JIVANI, JOHN D. HAMANN, and
`STACY B. MARGOLIES, Administrative Patent Judges.
`HAMANN, Administrative Patent Judge.
`
`
`
`
`JUDGMENT
`Final Written Decision
`Determining Some Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`Trials@uspto.gov
`Entered: September 24, 2020
`Tel: 571-272-7822
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`APPLE INC.,
`Petitioner,
`v.
`MPH TECHNOLOGIES OY,
`Patent Owner.
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`__________________________
`
`
`
`
`
`
`
`Before KAMRAN JIVANI, JOHN D. HAMANN, and
`STACY B. MARGOLIES, Administrative Patent Judges.
`HAMANN, Administrative Patent Judge.
`
`
`
`
`JUDGMENT
`Final Written Decision
`Determining Some Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`INTRODUCTION
`I.
`In this inter partes review, instituted pursuant to 35 U.S.C. § 314,
`Apple Inc. (“Petitioner”) challenges the patentability of claims 1–9 (“the
`challenged claims”) of U.S. Patent No. 7,937,581 B2 (Ex. 1001, “the ’581
`patent”), owned by MPH Technologies Oy (“Patent Owner”). We have
`jurisdiction under 35 U.S.C § 6. This Final Written Decision is entered
`pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
`For the reasons discussed herein, we determine that Petitioner has
`shown by a preponderance of the evidence that claims 1–3, 5, and 9 are
`unpatentable, but Petitioner has not shown by a preponderance of the
`evidence that claims 4 and 6–8 are unpatentable.
`BACKGROUND
`II.
`
`A. Procedural History
`Petitioner filed a Petition requesting inter partes review of the
`challenged claims of the ’581 patent. Paper 2 (“Pet.”). The Petition is
`supported by the Declaration of David Goldschlag, Ph.D. (Ex. 1002). Patent
`Owner filed a Preliminary Response. Paper 8.
`We instituted inter partes review of all of the challenged claims of the
`’581 patent on all of the grounds raised in the Petition. Paper 10 (“Dec. on
`Inst.”), 7, 42. As to this Decision on Institution, Patent Owner filed a
`Request for Rehearing, and requested review by the Precedential Opinion
`Panel (“POP”). Paper 12; Ex. 3001. Patent Owner’s request for POP review
`was denied, and we subsequently denied Patent Owner’s Request for
`Rehearing. Papers 16, 24.
`Patent Owner filed a replacement Response to the Petition. Paper 23
`(“PO Resp.”). The Response is supported by the Declaration of Professor
`
`2
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`George N. Rouskas, Ph.D. (Ex. 2009). Petitioner filed a Reply to Patent
`Owner’s Response. Paper 26 (“Pet. Reply”). The Reply is supported by an
`additional Declaration of David Goldschlag, Ph.D. (Ex. 1022). Patent
`Owner filed a Sur-Reply to Petitioner’s Reply. Paper 29 (“PO Sur-Reply”).
`An oral hearing was held on June 25, 2020. A transcript of the oral
`hearing is included in the record. Paper 36 (“Tr.”).
`
`B. Related Matter
`The parties identify MPH Techs. Oy v. Apple Inc., No. 5:18-cv-05935-
`PJH (N.D. Cal.), as a matter that may affect or would be affected by a
`decision in this proceeding. Pet. 2–3; Paper 7, 1. The parties also identify,
`as a related matter, Apple Inc. v. MPH Techs. Oy, IPR2019-00819 (PTAB),
`involving U.S. Patent No. 7,620,810, which is the parent of the ’581 patent.
`Pet. 2–3; Paper 7, 1.
`
`C. The Challenged Patent (Ex. 1001)
`The ’581 patent relates to “secur[ing] mobile connections in
`telecommunication networks.” Ex. 1001, 1:15–16. In particular, the ’581
`patent describes reducing the handover latency and computational overhead
`for secure connections, such as those employing Internet Protocol (“IP”)
`Security (“IPSec”) with mobile terminals1 (i.e., terminals that can move
`from one network to another). Id. at 1:15–16, 1:59–66, 4:12–35, 6:42–44,
`7:23–37, 10:31–39.
`
`
`1 The ’581 patent discloses that “the term[s] mobility and mobile terminal
`do[] not only mean physical mobility, . . . [but also] mean[] moving from
`one network to another, which can be performed by a physically fixed
`terminal as well.” Ex. 1001, 4:31–35.
`
`3
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`IPSec comprises a set of rules defined by the Internet Engineering
`Task Force (“IETF”) to “provide[] the capability to secure communications
`between arbitrary hosts,” according to the ’581 patent. Id. at 1:59–66, 2:5,
`2:8–12. The ’581 patent states that these rules describe, inter alia, providing
`“access control based on the distribution of cryptographic keys.” Id. at
`2:13–22. The ’581 patent also describes the concept of a Security
`Association (“SA”), which according to the ’581 patent is “a one-way
`relationship between a sender and a receiver that offers [negotiated] security
`services to the traffic carried on it.” Id. at 2:24–26.
`The ’581 patent discloses that IPSec supports two modes of operation
`(i.e., transport mode and tunnel mode). Id. at 3:6–7. “Typically, transport
`mode is used for end-to-end communication between two hosts.” Id. at
`3:14–15. “Tunnel mode . . . is generally used for sending messages through
`more than two components,” such as “when one or both ends of a SA is a
`security gateway, such as a firewall or a router that implements IPSec.” Id.
`at 3:19–24.
`“IPSec is intended to work with static network topolog[ies],”
`according to the ’581 patent. Id. at 4:14–15. For example, IPSec can secure
`communications between hosts across a local area network (“LAN”), as well
`as across a private or public wide area network (“WAN”). Id. at 1:59–61.
`Figure 1, shown below, “illustrates an example of a telecommunication
`network to be used in the invention” of the ’581 patent. Id. at 8:37–38.
`
`4
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`
`
`
`
`Figure 1 depicts an example telecommunication network comprising
`
`“computer 1 . . . and computer 2[,] a destination computer, to which the
`secure messages are sent . . . by means of an IPSec tunnel established
`between computer 1 and computer 2.” Id. at 8:50–55. The ’581 patent adds:
`“Computer 2 [can] be a security gateway for a third computer 3. Then, the
`messages sent from computer 2 to computer 3 are sent in plaintext.” Id. at
`8:55–57.
`
`The ’581 patent discloses that in forming an IPSec tunnel under
`IPSec’s default automated key management protocol (i.e., the Internet Key
`Exchange (“IKE”) protocol), “the tunnel endpoints are fixed and remain
`constant.” Id. at 4:2–7, 4:15–20. The ’581 patent adds: “If IPSec is used
`with a mobile host, the IKE key exchange will have to be redone from every
`new[ly] visited network. This is problematic, because IKE key exchanges
`involve computationally expensive” calculations and require exchanging
`numerous messages between the endpoints, leading to higher latency. Id. at
`4:18–29.
`
`To address these problems, the ’581 patent discloses avoiding a full
`re-negotiation between the tunnel endpoints, when computer 1 moves
`
`5
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`networks. E.g., id. at 9:22–33 (describing prior art requires a full re-
`negotiation), 9:60–63. More specifically, the ’581 patent discloses initially
`establishing an IPSec tunnel between computer 1 (address A) and computer
`2 (address X) using IKE, as in the prior art. Id. at 9:44–59, Fig. 5
`(illustrating steps 1a–9a for setting up the tunnel); compare id. at Fig. 5, with
`id. at Fig. 4 (showing the same nine steps as the prior art solution); see also
`id. at 9:1–28 (describing the prior art IKE establishment of the tunnel).
`
`The ’581 patent discloses that, when computer 1 moves from address
`A to address B, computer 1 sends from its new address (address B) to
`computer 2 (address X) at the other end of the established IPSec tunnel, a
`request for computer 2 to register its new address. Id. at 9:60–66.
`According to the ’581 patent, this request can be “encrypted and/or
`authenticated . . . us[ing] the same IPSec SA [that is used] for protecting
`both data and registration traffic.” Id. at 10:1–5.
`
`The ’581 patent thus discloses that the tunnel’s IPSec SA is carried
`over to the new connection point, and computer 1 can send IPSec-protected
`messages to computer 2 after sending the request, which “essentially makes
`the handover latency zero.” Id. at 10:8–16, 10:31–34. “[T]he exact method
`of signalling is not important[;] the essence is to carry over the IPSec SA to
`the new connection point.” Id. at 10:8–10.
`
`D. The Challenged Claims
`Petitioner challenges claims 1–9 of the ’581 patent, of which claims 1
`and 9 are independent. Claim 1 is illustrative of the challenged claims and is
`reproduced below:
`1. A method for ensuring secure forwarding of a message in a
`telecommunication network, having at least one mobile terminal
`
`6
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`and another terminal and a security gateway therebetween, the
`method comprising:
`
`a) establishing a secure connection having a first address
` of the mobile terminal as a first end-point and a gateway
` address of the security gateway as a second end-point,
`
`b) the mobile terminal changing from the first address to a
`second address,
`
`c) while at the second address, the mobile terminal sending
`a request message to the gateway address of the security gateway
`to request the security gateway to change the secure connection
`to be defined between the second address and the gateway
`address of the security gateway,
`
`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, and
`
`the mobile terminal sending a secure message in the secure
`connection from the second address of the mobile terminal to the
`other terminal via the security gateway.
`Ex. 1001, 10:50–11:3.
`
`E. Instituted Grounds of Unpatentability
`We instituted trial based on the following grounds of unpatentability,
`
`which are all the grounds of unpatentability raised in the Petition:
`
`References
`Basis2 Challenged Claim(s)
`1.
`Ishiyama,3 Murakawa4
`§ 103(a) 1, 2, 4, 6, 7, 9
`2.
`Ishiyama, Murakawa,
`§ 103(a) 3, 5
`Ahonen5
`
`
`2 The Leahy-Smith America Invents Act (“AIA”) included revisions to
`35 U.S.C. § 103 that became effective on March 16, 2013. Because the ’581
`patent issued from an application filed before March 16, 2013, we apply the
`pre-AIA version of the statutory basis for unpatentability.
`3 U.S. Patent No. 6,904,466 B1 (issued June 7, 2005) (Ex. 1004).
`4 U.S. Patent No. 7,028,337 B2 (issued Apr. 11, 2006) (Ex. 1005).
`5 U.S. Patent No. 6,976,177 B2 (issued Dec. 13, 2005) (Ex. 1006).
`
`7
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`
`3.
`
`Ishiyama, Murakawa,
`Forslöw6
`
`§ 103(a) 8
`
`Pet. 4, 11–64.
`
`III. LEVEL OF ORDINARY SKILL IN THE ART
`To determine whether an invention would have been obvious at the
`time it was made, we consider the level of ordinary skill in the pertinent art
`at the time of the invention. Graham v. John Deere Co., 383 U.S. 1,
`17 (1966). In assessing the level of ordinary skill in the art, various factors
`may be considered, including the “type of problems encountered in the art;
`prior art solutions to those problems; rapidity with which innovations are
`made; sophistication of the technology; and educational level of active
`workers in the field.” In re GPAC, Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995)
`(citing Custom Accessories, Inc. v. Jeffrey-Allan Indus., Inc., 807 F.2d 955,
`962 (Fed. Cir. 1986)). “[O]ne or more factors may predominate.” Id.
`In our Decision on Institution, we adopted Petitioner’s proposed
`definition for one having ordinary skill in the art at the time of the invention
`of the ’581 patent as one who “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.” Pet. 11 (citing Ex. 1002 ¶¶ 20–21). Patent Owner does not
`dispute our adoption of Petitioner’s definition, nor otherwise address the
`level of ordinary skill at the time of the invention of the ’581 patent. See
`generally PO. Resp.
`Because Petitioner’s definition of the level of skill in the art is
`consistent with the ’581 patent and the asserted prior art, we maintain
`
`6 U.S. Patent No. 6,954,790 B2 (issued Oct. 11, 2005) (Ex. 1007).
`
`8
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`Petitioner’s definition for purposes of this Final Written Decision. See
`Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001); GPAC, 57 F.3d
`at 1579; In re Oelrich, 579 F.2d 86, 91 (CCPA 1978). We apply Petitioner’s
`definition in our analysis below.
`
`IV. CLAIM CONSTRUCTION
`Because the Petition was filed after November 13, 2018, we construe
`the challenged claims by applying “the standard used in federal courts, in
`other words, the claim construction standard that would be used to construe
`the claim in a civil action under 35 U.S.C. [§] 282(b), which is articulated in
`Phillips [v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc)].” See
`Changes to the Claim Construction Standard for Interpreting Claims in Trial
`Proceedings Before the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340,
`51,340, 51,358, 51,343–44 (Oct. 11, 2018) (amending 37 C.F.R. § 42.100(b)
`effective November 13, 2018) (now codified at 37 C.F.R. § 42.100(b)
`(2019)). Under Phillips, the words of a claim are generally given their
`“ordinary and customary meaning,” which is the meaning they would have
`to a person of ordinary skill in the art at the time of the invention, in light of
`the specification and prosecution history. See Phillips, 415 F.3d at 1312–13.
`Petitioner does not submit any terms for construction. Pet. 11
`(arguing that “[a]ll claim terms of the ’581 patent should receive their
`ordinary and customary meaning”). Patent Owner submits the term
`“security gateway” for construction, and argues that its meaning is in
`dispute. PO Resp. 10–24. To show a dispute, Patent Owner quotes from our
`Decision on Institution where we preliminarily found that (i) “Petitioner
`argues that one of ordinary skill in the art would have understood that
`Ishiyama’s ‘correspondent [host]’ would be a security gateway,” and
`
`9
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`(ii) “there [wa]s sufficient support in the [preliminary] record that
`Ishiyama’s correspondent host is a security gateway.” PO Resp. 10–11
`(citing Dec. on Inst. 26, 34). Patent Owner argues “[t]hus, the claim
`construction dispute in this proceeding is whether a correspondent host is a
`‘security gateway.’” Id. at 11.
`For our analysis below, however, we do not rely on Petitioner’s
`arguments that Ishiyama’s correspondent host is a security gateway. Rather,
`we consider Petitioner’s alternative argument7 that Murakawa teaches a
`security gateway. Thus, we conclude that no express claim construction is
`necessary to determine whether Petitioner has shown by a preponderance of
`evidence that the challenged claims are unpatentable. See, e.g., Nidec Motor
`Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed.
`Cir. 2017) (quoting Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d
`795, 803 (Fed. Cir. 1999)) (“[W]e need only construe terms ‘that are in
`controversy, and only to the extent necessary to resolve the controversy.’”).
`
`V.
`
`PRINCIPLES OF LAW
`A 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 of the invention to a
`person having ordinary skill in the art. 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
`
`
`7 “Petitioner alternatively relies on Ishiyama’s teachings combined with
`Murakawa’s teachings of a ‘security gateway configuration’ (e.g., ‘a security
`gateway’ and ‘another terminal’/‘other terminal’”) for disclosing claim 1.”
`Dec. on Inst. 25; see also Pet. 11–53.
`
`10
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`the prior art; (2) any differences between the claimed subject matter and the
`prior art; (3) the level of ordinary skill in the art; and (4) objective evidence
`of non-obviousness, if present.8 See Graham, 383 U.S. at 17–18. When
`evaluating a claim for obviousness, we also must “determine whether there
`was an apparent reason to combine the known elements in the fashion
`claimed by the patent at issue.” KSR, 550 U.S. at 418 (citing In re Kahn,
`441 F.3d 977, 988 (Fed. Cir. 2006)).
`
`VI. ALLEGED OBVIOUSNESS OVER ISHIYAMA AND
`MURAKAWA
`Petitioner argues that the combination of Ishiyama and Murakawa
`renders claims 1, 2, 4, 6, 7, and 9 of the ’581 patent obvious under 35 U.S.C.
`§ 103(a). Pet. 11–53. We have reviewed the parties’ arguments and the
`evidence of record. For the reasons that follow, we determine that Petitioner
`(1) shows by a preponderance of the evidence that claims 1, 2, and 9 would
`have been obvious to one of ordinary skill in the art in view of Ishiyama and
`Murakawa; and (2) fails to show by a preponderance of the evidence that
`claims 4, 6, and 7 would have been obvious to one of ordinary skill in the art
`in view of Ishiyama and Murakawa.
`
`A. Summary of Ishiyama
`Ishiyama relates to improving a mobile computer’s “capab[ility] of
`
`carrying out communications while moving among a plurality of inter-
`connected networks.” Ex. 1004, 1:9–11. In furtherance of this mobility,
`Ishiyama discloses having the mobile computer notify its correspondent host
`(i.e., the host at the other end of a communication) of its new address when
`
`
`8 Patent Owner does not present arguments or evidence of such objective
`evidence of non-obviousness in its Response. See generally PO Resp.
`
`11
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`the mobile computer moves networks. E.g., id. at 3:43–67, 6:13–18, 15:37–
`16:10. The mobile computer makes this notification by changing the source
`address of an outer packet of an encapsulated packet to the mobile
`computer’s new address before sending the packet to the correspondent host.
`Id. When the correspondent host receives the packet from the mobile
`computer, the correspondent host detects the address change and updates its
`stored information to reflect the new address for the mobile computer. E.g.,
`id. at 3:9–14.
`Figure 4, shown below, is a schematic diagram illustrating a mobile
`computer changing locations in an exemplary configuration of a mobile
`communication system, in accordance with an embodiment of Ishiyama’s
`invention. Id. at 5:5–7, 5:11–13.
`
`
`Figure 4 “shows an exemplary situation in which a packet is
`
`transferred from mobile computer 2 to . . . correspondent host 3 using [an]
`IPSEC tunnel.” Id. at 8:33–35. Initially, mobile computer 2 communicates
`with correspondent host 3 via an IPSec tunnel, with mobile computer 2’s
`
`12
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`address (CoA1) indicating its endpoint of the tunnel. Id. at 8:43–49. In
`other words, “mobile computer 2 transmits an encapsulated packet in which
`the outer packet has the source address=‘CoA1’ and the destination
`address=‘CN.’” Id. at 8:50–54. As shown, when mobile computer 2 moves,
`its address changes from CoA1 to CoA2. Id. at 8:55–58, Fig. 4 (showing
`that mobile computer 2 moves networks). To convey this change, mobile
`computer 2 changes the source address of the outer packet to CoA2 and
`transmits the packet to correspondent host 3 via the IPSec tunnel. Id. at
`8:59–63, Fig. 4. Correspondent host 3 detects this change in mobile
`computer 2’s address, and replaces the CoA1 address with CoA2 in its
`database for the IPSec tunnel. Id. at 8:66–9:4; see also id. at Figs. 9B, 9D
`(showing the update of the address in correspondent host 3’s SA database),
`12:51–59. Ishiyama discloses that the other SA information “remain[s]
`unchanged, so that there is no need to re-negotiate keys for IPS[ec]
`encryption and authentication.” Id. at 9:5–10.
`
`B. Summary of Murakawa
`Murakawa relates to allowing a PC outside a LAN to be virtually
`
`regarded as a PC on the LAN and communicate with a terminal on the LAN.
`Ex. 1005, 1:16–24, 3:62–65. Specifically, Murakawa discloses allowing an
`outside terminal to communicate (via a WAN, a security gateway, and a
`LAN) with a terminal on the LAN. Id. at 1:11–24, 3:61–4:16.
`
`Petitioner’s annotated version of Murakawa’s Figure 5, which
`illustrates a “prior art typical network system,” id. at 4:32–33, is shown
`below.
`
`13
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`
`
`Murakawa’s Figure 5 above shows a “prior art typical network
`
`system” and is further annotated by Petitioner to add labels for a mobile
`terminal, security gateway, and other terminals. Pet. 28. According to
`Murakawa, Figure 5 “is a block diagram of a typical network system
`including a WAN.” Ex. 1005, 1:51–53. As shown in Figure 5, the network
`system includes “PC 101 [(labeled by Petitioner as ‘Mobile Terminal’)],
`which is located outside . . . LAN [104 and] establish[es] a dialup
`connection to the provider, WAN 102, and security gateway 103 [(labeled
`by Petitioner as ‘Security Gateway’)] that connects WAN 102 and LAN
`104.” Id. at 1:54–58. In addition, “LAN 104[,] being subjected to security
`gateway 103[,] includes . . . client PCs 106, 107” (labeled by Petitioner as
`“Other Terminals”). Id. at 1:59–60. Also shown is virtual private network
`(“VPN”) 108, which is established between PC 101 and security gateway
`103 to perform IPSec communication. Id. at 1:61–63. Murakawa discloses
`
`14
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`that this network system ensures safe communications between PC 101 and
`the terminals on LAN 104. Id. at 2:1–4.
`
`C. Challenged Claim 1
`Claim 1 is an independent claim. Petitioner combines Ishiyama and
`Murakawa in two alternative ways in arguing that claim 1 would have been
`obvious to one of ordinary skill in the art. See Pet. 11–47; Dec. on Inst. 25,
`38–39 (noting the two alternative ways). Below we address Petitioner’s
`second way of combining Ishiyama and Murakawa (i.e., combining
`Ishiyama’s address changing functionality with Murakawa’s security
`gateway and another terminal)). In other words, Petitioner combines
`Ishiyama’s “address updating for a mobile terminal operating in the IPSec
`tunneling mode” with “Murakawa’s . . . security gateway configuration” for
`“tunneling of communications through a security gateway so that two
`terminals are able to communicate.” E.g., Pet. 20 (citing Ex. 1004, 7:46–49;
`Ex. 1005, 4:13–16; Ex. 1002 ¶ 61). For that combination, we find that
`Petitioner demonstrates by a preponderance of the evidence that claim 1
`would have been obvious to one of ordinary skill in the art. Because of this
`finding, we do not reach the parties’ arguments concerning the first way
`Petitioner combines Ishiyama and Murakawa. For example, we do not reach
`whether Ishiyama teaches that its correspondent host is a security gateway.
`
`1. Preamble
`Claim 1’s preamble recites “[a] method for ensuring secure
`forwarding of a message in a telecommunication network, having at least
`one mobile terminal and another terminal and a security gateway
`therebetween.” Ex. 1001, 10:50–53. We agree with Petitioner and find that
`the combination of Ishiyama and Murakawa teaches claim 1’s preamble.
`
`15
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`Pet. 20–26. As we find that Ishiyama and Murakawa teach the preamble, we
`need not determine whether the preamble is limiting.
`As to Ishiyama, we agree with Petitioner that Ishiyama teaches “a
`mobile communication scheme capable of easily changing a connected
`location of a mobile computer on [an] IP network.” Ex. 1004, 2:42–45;
`Pet. 21. More specifically, we find that Ishiyama teaches using care-of
`addresses (“CoA”) for a “mobile computer 2 [that] always uses the IPSEC in
`the tunnel mode at a time of making a connection to the correspondent host
`3.” Ex. 1004, 7:66–67, 11:9–16; Pet. 21.
`As to Murakawa, we agree with Petitioner and find that Murakawa
`teaches forwarding messages received from a terminal at a security gateway
`located between the terminal and another terminal. E.g., Ex. 1005, Fig. 5;
`Pet. 24 (annotating Ex. 1005, Fig. 5). As illustrated in Figure 5, Murakawa
`discloses that PC 101 establishes an IPSec tunnel (VPN 108), with security
`gateway 103. Ex. 1005, 1:61–63, 2:62–65, Fig. 5; Pet. 24–25. Murakawa’s
`security gateway 103 connects to PC 106 and PC 107. Ex. 1005, 1:59–60.
`We agree with Petitioner and find that either PC 106 or PC 107 is the
`claimed another terminal. Id. at 1:61–2:4, Fig. 5; see also Pet. 24–25
`(annotating Ex. 1005, Fig. 5 (labeling PC 106 and PC 107 “Other
`Terminals”)). We find that Murakawa’s network system allows for PC 101
`and another terminal (e.g., PC 106 or PC 107) to communicate securely via
`security gateway 103. Ex. 1005, 1:64–2:4, Fig. 5; Pet. 24–25.
`
`Lastly, we are not persuaded by Patent Owner’s arguments that
`“[i]ncorporating Murakawa’s security gateway 103 into Ishiyama does not
`fill in the missing limitation of the ‘[an]other terminal’ because no host
`computer has been incorporated from Murakawa.” PO Resp. 49; see also id.
`
`16
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`at 45 (explaining that the claim recites “another terminal” and “other
`terminal”). Put differently, Patent Owner argues that “Petitioner’s
`modification of Ishiyama by Murakawa does not explain how the
`combination provides the recited ‘other terminal.’” Id. (citing Ex.
`2009 ¶¶ 143–144). To the contrary, Petitioner argues that “Murakawa
`describes the forwarding of messages at a security gateway located between
`a mobile terminal and other terminals.” Pet. 24. Petitioner then proceeds to
`describe Murakawa’s Figure 5, and to identify Murakawa’s PC 106 and PC
`107 as other terminals. See id. at 24–25 (citing Ex. 1005, 1:59–63;
`annotating Ex. 1005, Fig. 5 (labeling PC 106 and PC 107 “Other
`Terminals”)). Thus, we disagree with Patent Owner that “no host computer
`has been incorporated from Murakawa.” PO Resp. 49.
`In summary, we find combining Ishiyama’s mobile address changing
`functionality with Murakawa’s security gateway and another terminal
`teaches “[a] method for ensuring secure forwarding of a message in a
`telecommunication network, having at least one mobile terminal and another
`terminal and a security gateway therebetween.”
`
`2. Establishing a Secure Connection
`Claim 1 further recites “establishing a secure connection having a first
`address of the mobile terminal as a first end-point and a gateway address of
`the security gateway as a second end-point.” Ex. 1001, 10:54–56. We agree
`with Petitioner that the combination of Ishiyama and Murakawa teaches this
`limitation. Pet. 26–30. We find that Ishiyama teaches that mobile
`computer 2 first establishes an IPSec tunnel between its first address (CoA1)
`and correspondent host 3’s address (CN). Ex. 1004, 8:25–26, 8:36–38,
`8:43–47, 8:50–53, 11:9–17, 12:3–5, Fig. 4; Pet. 26–27. Furthermore,
`
`17
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`Ishiyama teaches that the IPSec tunnel is defined by, inter alia, the addresses
`of mobile computer 2 and correspondent host 3. Ex. 1004, 12:9–12, 12:51–
`59; Figs. 9A, 9B; Pet. 28–29.
`In addition, we agree with Petitioner and find that Murakawa teaches
`a security gateway. Ex. 1005, 1:59–2:4, 2:62–65, 4:13–16, Fig. 5; Pet. 18–
`19, 24–25 (citing Ex. 1005, Fig. 5) (annotating the figure with “Security
`Gateway”). Moreover, Murakawa teaches establishing a secure connection
`between a terminal (PC 101) and the security gateway. Ex. 1005, 1:61–63
`(“[I]n order to perform the IPsec communication, VPN 108 is established
`between PC 101 and security gateway 103.”), Fig. 5.
`In summary, we find combining Ishiyama’s mobile address changing
`functionality with Murakawa’s security gateway and another terminal
`teaches “establishing a secure connection having a first address of the
`mobile terminal as a first end-point and a gateway address of the security
`gateway as a second end-point.”
`
`3. Mobile Terminal Changing Addresses
`Claim 1 further recites “the mobile terminal changing from the first
`address to a second address.” Ex. 1001, 10:57–58. We agree with Petitioner
`and find that Ishiyama teaches that after the IPSec tunnel has been
`established, Ishiyama’s mobile computer 2 moves networks, moving from a
`first address (CoA1) to a second address (CoA2). See, e.g., Ex. 1004, 8:55–
`57, Fig. 4; Pet. 30. This is depicted in Ishiyama’s Figure 4, as annotated by
`Petitioner, where mobile terminal 2 moves from its first location (dashed red
`box corresponding to CoA1) to its second location (solid red box
`corresponding to CoA2). See Pet. 30 (annotating Ex. 1004, Fig. 4).
`
`18
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`Based on Ishiyama’s teachings, we find that the combination of
`Ishiyama and Murakawa teaches “the mobile terminal changing from the
`first address to a second address.”
`
`4. While at the Second Address
`Claim 1 further recites “while at the second address, the mobile
`terminal sending a request message to the gateway address of the security
`gateway to request the security gateway to change the secure connection to
`be defined between the second address and the gateway address of the
`security gateway.” Ex. 1001, 10:59–63. We agree with Petitioner that the
`combination of Ishiyama and Murakawa teaches this limitation. Pet. 31–33.
`First, we agree with Petitioner and find that Ishiyama teaches that
`after a mobile terminal moves from a first address (CoA1) to a second
`address (CoA2), the mobile terminal sends a request message to the address
`of the correspondent host to change the security association definition from
`CoA1 to CoA2. Ex. 1004, 8:59–65; Pet. 31. Specifically, Ishiyama teaches
`that “the 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.’” Ex. 1004, 8:59–62; Pet. 31. We agree
`with Petitioner that Ishiyama teaches that “the encapsulated packet in which
`the outer packet has the source address =‘CoA2’ will be transferred.”
`Ex. 1004, 8:63–65; Pet. 31. This is shown in Ishiyama’s Figure 4, shown
`below as annotated in the Petition. See Pet. 31 (providing annotated
`Figure 4).
`
`19
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`
`
`Annotated Figure 4 “is a schematic diagram for explaining operations
`in the case where the mobile computer changes a connected location in the
`mobile communication system” with (i) a dotted-line red box around mobile
`computer 2 at its first location, (ii) a solid-line red box around mobile
`computer 2 at its second location, (iii) a solid-line green box around
`correspondent host 3, (iv) a “Mobile Terminal” label for each mobile
`computer 2 location, and (v) a “Security Gateway” label for correspondent
`host 3. Ex. 1004, 5:11–13; Pet. 31 (annotating Ex. 1004, Fig. 4). Ishiyama’s
`Figure 4 illustrates that after the mobile computer 2 moves to a second
`address, a request message is sent from mobile computer 2 to correspondent
`host 3, with the request message illustrated as a rectangle (with “src: Haddr”
`and “dst: CN” labels) depicting the encapsulated packet, surrounded by a
`larger rectangle, depicting the outer packet (with “src: CoA2” and “dst: CN”
`labels). Ex. 1004, Fig. 4, 8:59–65; Pet. 35–36. Thus, Ishiyama teaches the
`entire transmitted packet comprises the request message. Id. at 8:59–65,
`Fig. 4. This finding is consistent with Petitioner’s arguments made during
`the oral hearing that Ishiyama’s entire transmitted packet (i.e., the
`
`20
`
`
`
`IPR2019-00820
`Patent 7,937,581 B2
`encapsulated packet plus the outer packet, which has the changed source
`address) is the claimed request message. See, e.g., Tr. 27:23–28:4, 29:10–
`17, 30:3–11, 34:14–35:1, 40:12–14, 65:8–67:7.
`Second, we agree with Petitioner and find that Ishiyama teaches that
`the “[r]equest [is] for changing the security association to the correspondent
`[host]” as part of mobile computer 2 performing a SA Gateway Update.
`Pet. 32 (quoting Ex. 1004, 11:39–40); Ex. 1004, 11:39–46. More
`specifically, Ishiyama teaches that mobile computer 2’s “request [is] to
`change the previous CoA used as the destination in the security association
`into the current CoA.” Ex. 1004, 11:43–45; see also Pet. at 32 (annotating
`Ex. 1004, Fig. 7; citing Ex. 1004, 12:54–57 (arguing that “[t]he SA Gateway
`Update operation is
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
