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
`____________________
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`UNDER 37 C.F.R. § 42.23
`
`
`
`
`
`
`
`
`
`
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`

`

`
`Introduction ..................................................................................................... 1
`I.
`The Board Should Reject MPH’s Improper Claim Construction .................. 1
`II.
`III. The Combination of Ishiyama and Murakawa Discloses the Claimed
`“Security Gateway” ........................................................................................ 5
`A.
`It would have been obvious to a POSA from Ishiyama’s use of
`IPSec for its correspondent host to be a security gateway because
`IPSec only has a finite number of endpoint configurations. ................. 5
`A POSA would have understood that Ishiyama’s use of tunnel
`mode suggests that its correspondent host would be a security
`gateway. ................................................................................................. 7
`A POSA would have sought out references such as Murakawa
`for its teaching of tunnel mode implementation ................................... 9
`IV. Nothing in the Prior Art Precludes Ishiyama’s “Correspondent Host”
`from Operating as a “Security Gateway” ..................................................... 10
`The Combination of Ishiyama and Murakawa Teaches the “Other
`Terminal” ...................................................................................................... 14
`Ishiyama Teaches the Mobile Terminal Transmitting a Message While
`at a Second Address to Change the Definition of a Security Association
` ...................................................................................................................... 17
`VII. The Combination of
`Ishiyama and Murakawa Teaches
`the
`“Request”/“Reply” Messages Being Encrypted as Recited in Claim 4. ...... 18
`VIII. The Combination of Ishiyama, Murakawa, and Ahonen Renders Claims
`3 and 5 Obvious ............................................................................................ 19
`IX. Dependent Claims 6-8 are Unpatentable as Stated in Ground 2 of the
`Petition .......................................................................................................... 22
`Conclusion .................................................................................................... 27
`
`B.
`
`C.
`
`V.
`
`VI.
`
`X.
`
`
`TABLE OF CONTENTS
`
`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`
`
`
`
`
`
`
`- i -
`
`

`

`PETITIONER’S EXHIBIT LIST
`
`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`
`1002
`
`1003
`1004
`1005
`1006
`1007
`1008
`
`1009
`
`1010
`
`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”)
`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
`(“RFC 2401”)
`RFC793 - Transmission Control Protocol, Darpa Internet Program
`Protocol Specification, September 1981 (“RFC 793”)
`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”)
`
`1011
`
`1012
`1013
`1014
`1015
`1016
`1017
`
`1018
`1019
`
`
`
`- ii -
`
`

`

`Case IPR2019-00820
`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”)
`Transcript of the Deposition of Dr. George N. Rouskas, March 20,
`2020 (“Rouskas Depo.”)
`Declaration of Dr. David Goldschlag in Support of Petitioner’s
`Reply to Patent Owner’s Response (“Second Goldschlag Decl.”)
`
`1021
`
`1022
`
`
`
`- iii -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`
`I.
`
`Introduction
`The Board should find unpatentable all claims of the ’581 patent because
`
`Apple has shown that the prior art renders all claims invalid. MPH raises no new
`
`arguments in its Patent Owner Response (POR), but rather repeats the unavailing
`
`arguments made in its Patent Owner Preliminary Response (POPR). The Board
`
`should again reject those arguments as it did in the Institution Decision.
`
`Essentially, MPH makes one argument as to why the combination of Ishiyama and
`
`Murakawa does not render obvious the claims of the ’581 patent—that Ishiyama’s
`
`“correspondent host” is not a “security gateway.” See POR, 27-45. But the Board
`
`should reject this argument because it is based on an improper and unnecessary
`
`claim construction, mischaracterizes Apple’s contentions, and ignores the
`
`teachings of Ishiyama and Murakawa.
`
`II. The Board Should Reject MPH’s Improper Claim Construction
`
`Disputed Constructions
`Security gateway: Plain and ordinary meaning.
`Apple
`
`MPH
`
`
`
`Security gateway: “gateway that provides additional security
`functionality, such as firewall functionality.” POR, 11.
`
`Gateway: “an intermediary system with two or more communication
`interfaces that interconnects different networks and can forward
`packets it receives from one network on to another network.” POR,
`11.
`
`
`
`- 1 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`The Board should reject MPH’s construction for “security gateway” because
`
`it impermissibly imports limitations from the specification, and there is simply no
`
`need to construe this term. MPH’s construction inappropriately asks the Board to
`
`find that a “security gateway” is not a “host”—presumably, to undermine Apple’s
`
`obviousness position with respect to the term “security gateway.” See POR, 10-24.
`
`But this highlights MPH’s fundamental misunderstanding of Apple’s contentions.
`
`Apple does not contend that all embodiments of Ishiyama’s “correspondent host”
`
`are “security gateways.” Rather, a POSA would have understood that Ishiyama
`
`suggests that its “correspondent host” would instead be a “security gateway.”1
`
`Thus, it is unnecessary to construe “security gateway,” as proposed by MPH. See
`
`EX1022, Second Goldschlag Decl., ¶¶5-6.
`
`There is also no need to construe “security gateway” because there is no
`
`dispute between the parties that “security gateway” functionality was well-known,
`
`especially in the context of IPSec. See EX1022, ¶7. Further, there is no evidence to
`
`support MPH’s arguments that the ’581 patent uses the term in a special way. Id.
`
`Indeed, Dr. Rouskas admitted during his deposition that the ’810 patent (the parent
`
`
`1 There is also no dispute between the parties that the “same system” can act
`
`as a host and a security gateway at the same time. See POR, 16, n.1 (citing
`
`EX2009, ¶70).
`
`
`
`- 2 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`of the ’581 patent having the same specification) uses the term “security gateway”
`
`in its common form as well-understood in the art and as described in the IPSec
`
`specification, RFC 2401. EX1021, Rouskas Depo., 165:17-166:5; 168:9-20.
`
`MPH’s intrinsic evidence also fails. See EX1022, ¶8. MPH contends that the
`
`term “gateway” should be construed as “an intermediary system with two or more
`
`communication interfaces that interconnects different networks and can forward
`
`packets it receives from one network on to another network” and that a “security
`
`gateway” is a “gateway that provides additional security functionality, such as
`
`firewall functionality.” POR, 11. MPH’s primary intrinsic support for these
`
`definitions appears to be the following quote:
`
`Tunnel 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 . . . . The
`IPSec tunnel mode operates e.g. in such a way that if a host on a
`network generates an IP packet with a destination address of another
`host on another network, the packet is routed from the originating host
`to a security gateway (SGW), firewall or other secure router at the
`boundary of the first network.
`See EX1001, ’581 patent, 3:15-62 (emphasis added).
`
`But this passage simply describes how IPSec tunnel mode operates, not what
`
`a security gateway is. See EX1022, ¶¶9-10. If anything, this passage undercuts
`
`MPH’s construction. MPH suggests that a “security gateway” must have “security
`
`functionality, such as firewall functionality.” POR, 11. But this passage explains
`
`
`
`- 3 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`security gateways simply “implement[] IPSec,” and need not have firewall
`
`functionality because the security gateway can be “a router.” EX1001, 3:15-62.
`
`MPH also cites column 8, lines 55-63, and FIGs. 1-2 for its construction.
`
`But MPH’s reliance on these passages fairs no better because the words “interface”
`
`or “intermediate system” do not appear here either. FIGs. 1-2 are explicitly labeled
`
`as non-limiting “example[s].” Id., 8:36-40. And importantly, these passages use
`
`non-limiting phraseology like “Computer 2 might be a security gateway” and “the
`
`security gateway can be a common security gateway . . . whereby there are several
`
`computers in the LAN protected by computer 2.” Id., 8:51-63. The ’581 patent
`
`does not present any special definition for “security gateway,” instead simply
`
`stating that the “security gateway can be a common security gateway for e.g. a
`
`company LAN.” See id. None of these passages even begin to suggest or require
`
`that a “security gateway” must have at least two interfaces and be an “intermediate
`
`system.” See EX1022, ¶¶11-12.
`
`Next, MPH turns to the prosecution history and various extrinsic references.
`
`See POR, 14-24. But neither the prosecution history nor the extrinsic references
`
`provide a definition of a “security gateway” that requires numerous interfaces, and
`
`MPH does not assert that they do. See EX1022, ¶13. Instead, MPH primarily relies
`
`on the prosecution history and extrinsic references to support its theory that a
`
`
`
`- 4 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`“security gateway” is allegedly not a “host.” Thus, the Board should decline to
`
`construe “security gateway” as proposed by MPH.
`
`III. The Combination of Ishiyama and Murakawa Discloses the Claimed
`“Security Gateway”
`MPH argues that the combination of Ishiyama and Murakawa does not
`
`disclose the claimed “security gateway” based on the assumption that Ishiyama’s
`
`“correspondent host” allegedly is not and cannot be the claimed “security
`
`gateway.” See POR, 27-45. MPH mischaracterizes Apple’s position. Apple
`
`contends that: (1) Ishiyama’s use of IPSec and disclosure of a “correspondent host”
`
`would have made it obvious to a POSA to use a “security gateway;” (2) Ishiyama’s
`
`disclosure of IPSec tunnel mode—most often used with “security gateways”—
`
`would have made it all the more obvious to a POSA to modify Ishiyama’s
`
`“correspondent host” to be a “security gateway;” and (3) if a POSA had not
`
`already known how to implement IPSec tunnel mode, he would have sought out
`
`how to do so, and Murakawa teaches implementing tunnel mode in a “security
`
`gateway.” EX1022, ¶¶14-15.
`
`A.
`
`It would have been obvious to a POSA from Ishiyama’s use of
`IPSec for its correspondent host to be a security gateway because
`IPSec only has a finite number of endpoint configurations.
`MPH cites multiple publications to argue that “hosts” are different from
`
`“security gateways.” See POR, 31-34. But MPH overlooks the fact that these
`
`publications demonstrate that there are only three combinations of network devices
`
`
`
`- 5 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`in the IPSec context. See POR, 31-34; see also EX1022, ¶¶16-18. Specifically, as
`
`Dr. Goldschlag, Frankel, and RFC 2401 all confirm, the endpoint of an IPSec
`
`connection can only ever be a host or a security gateway. See EX1022, ¶¶16-18;
`
`EX1008, Frankel, FIGs. 1.1(a)-1.1(c); EX1011, RFC 2401, 6 (“IPsec can be used
`
`to protect one or more ‘paths’ between a pair of hosts, between a pair of security
`
`gateways, or between a security gateway and a host.”). MPH does not dispute this.
`
`See POR, 37-41; EX2009, Rouskas Decl., ¶¶126-31.
`
`A POSA would have found it obvious for Ishiyama’s “correspondent host”
`
`to be a “security gateway” because Ishiyama’s secure connections are explicitly
`
`directed to IPSec, and there are only two endpoint choices: hosts or security
`
`gateways. See EX1022, ¶19; EX1004, Ishiyama, 7:46-49; EX1011, 6. Using a
`
`security gateway would have merely been an obvious design choice. EX1022, ¶19.
`
`But as explained by Dr. Goldschlag, a POSA would have indeed been motivated to
`
`use a “security gateway” in Ishiyama because, as acknowledged by the ’581 patent,
`
`a very common use case for IPSec is “virtual private networks.” EX1001, 1:62-66;
`
`see also EX1022, ¶¶20-25. And a POSA looking to use Ishiyama’s teachings in the
`
`context of a VPN would have understood that a “security gateway” would almost
`
`certainly be needed. EX1022, ¶¶20-25. In fact, both experts agree that using IPSec
`
`with VPNs was “ubiquitous” at the time of the ’581 patent. EX1021, 33:13-15; see
`
`also EX1022, ¶22. And Dr. Rouskas even concedes that “typically…one end of [a]
`
`
`
`- 6 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`VPN is a security gateway,” although Dr. Goldschlag explains that VPNs almost
`
`always use a “security gateway.” EX1021, 101:1-4 (emphasis added); see also
`
`EX1022, ¶¶20-25.
`
`The fact there are only two choices of endpoints in IPSec demonstrates the
`
`“finite number of identified, predictable solutions” that would lead to a
`
`determination of obviousness under KSR. See KSR Int’l Co. v. Teleflex Inc., 550
`
`U.S. 398, 421 (2007). And under well-settled Federal Circuit precedent, having a
`
`“discrete number of possible design options” illustrates that using one of the
`
`possible design options would have been obvious. See Geo. M. Martin Co. v.
`
`Alliance Mach. Sys. Int’l LLC, 618 F.3d 1294, 1302 (Fed. Cir. 2010).
`
`Thus, because only two endpoint options were available to a POSA for
`
`implementing IPSec connections, a POSA would have found it obvious to
`
`configure Ishiyama’s secure connection to be between a host and a security
`
`gateway. See EX1022, ¶¶16-19.
`
`B. A POSA would have understood that Ishiyama’s use of tunnel
`mode suggests that its correspondent host would be a security
`gateway.
`Ishiyama’s disclosure of IPSec “tunnel mode” would have further suggested
`
`to a POSA that Ishiyama’s “correspondent host” would be a “security gateway.”
`
`MPH, Dr. Rouskas, and the ’581 patent all concede that “although tunnel mode
`
`may also be used for end-to-end communication between two hosts[,] [t]unnel
`
`
`
`- 7 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`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.” EX1001, 3:19-30 (emphasis added);
`
`EX2009, ¶¶66, 128-29. Indeed, Dr. Rouskas concedes he has never once used
`
`IPSec tunnel mode between two hosts in his entire career despite extensive IPSec
`
`use:
`
`Q: So in all the instances where you personally have used IPSec,
`you have only ever used IPSec tunnel mode with security gateway
`being one of the endpoints. Right?
`A: So I have been using IPSec for, you know, more than 20 years.
`But to the best of my recollection that is right, I have only used it when
`one of endpoints is security gateway.
`EX1021, 111:21-112:9.
`
`Dr. Rouskas further admits that “IPSec tunnel mode [is] more often [used]
`
`when one endpoint is a security gateway.” Id., 113:7-9. And as explained by the
`
`IPSec standard, “[w]henever either end of a security association is a security
`
`gateway, the SA MUST be tunnel mode.” EX1011, 9. Thus, the most common
`
`scenario of tunnel mode is with a security gateway. See EX1022, ¶¶26-28.
`
`Nevertheless, MPH argues that Ishiyama is only a host-to-host scenario. See
`
`POR, 37-43; EX2009, ¶¶128-33. But MPH misses the point. Ishiyama’s disclosure
`
`of tunnel mode would have suggested to a POSA that Ishiyama’s correspondent
`
`host would be a “security gateway” for the reasons noted above. See EX1022,
`
`¶¶26-30. And MPH is wrong that Ishiyama’s tunnel mode is limited to host-host
`
`
`
`- 8 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`communications because of an alleged desire in Ishiyama to not “reveal” the
`
`“original home address” of the mobile terminal. POR, 41-42. Notably, MPH does
`
`not provide any citation to Ishiyama for this proposition, instead relying solely on
`
`expert testimony. See id. But Dr. Rouskas just repeats the same conclusory
`
`statements. See id. (citing EX2009, ¶133).
`
`Moreover, MPH overlooks an important teaching of Ishiyama. Regarding
`
`tunnel mode, Ishiyama acknowledges that one if its endpoints is a gateway: “the IP
`
`address (CoA) assigned to the communication interface 21 will be used as an
`
`address (gateway address) indicating one endpoint (termination endpoint) of the
`
`tunnel.” EX1004, 8:1-6 (emphasis added); see also EX1004, 8:43-49, 11:39-47,
`
`12:50-59, 14:11-16; see also EX1022, ¶¶31-32.
`
`Thus, Ishiyama not only suggests using a “security gateway” because it
`
`discloses using IPSec tunnel mode, but also explicitly states that its host is a
`
`gateway.
`
`C. A POSA would have sought out references such as Murakawa for
`its teaching of tunnel mode implementation
`MPH argues that a POSA would not have been motivated to combine
`
`Ishiyama and Murakawa. But MPH’s argument mischaracterizes Ishiyama and
`
`attempts to categorize the Petition’s position as an “inherency theory.” See POR,
`
`37-42. As the Board acknowledged, the Petition’s ground is based on
`
`obviousness—not anticipation. See Pet., 17-26, 35-40; see also Decision on
`
`
`
`- 9 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`Institution (DI), 34-35; see also EX1002, Goldschlag Decl., ¶¶56-61, 64-68, 84-90.
`
`Specifically, the Petition explains that Ishiyama’s tunnel mode would suggest that
`
`the correspondent host would be a security gateway based on obviousness
`
`principles. See Pet., 17-18, 20, 22-23, 25-26, 36-37; DI, 34-35. But Ishiyama’s
`
`description of tunnel mode is terse, and thus if a POSA had not understood how to
`
`implement tunnel mode with Ishiyama’s teachings, he would have sought out
`
`references such as Murakawa that explain how tunnel mode is implemented. See
`
`Pet., 17-26, 35-40; EX1022, ¶¶33-38.
`
`The Board correctly noted that the Petition relies on Murakawa for the
`
`explicit teaching of the “security gateway” and “other terminal.” DI, 38-39. And as
`
`the Petition explains, a POSA would have been motivated to combine Ishiyama
`
`with Murakawa to facilitate network communications with a mobile terminal. See
`
`Pet., 17-20, 37-40 (citing EX1004, 6:56-57).
`
`Thus, the Petition explains how Ishiyama and Murakawa would be
`
`combined in a predictable manner such that a secure connection would be created
`
`between a mobile terminal and a security gateway.
`
`IV. Nothing in the Prior Art Precludes Ishiyama’s “Correspondent Host”
`from Operating as a “Security Gateway”
`MPH argues that Ishiyama’s “correspondent host” cannot be a “security
`
`gateway” because Ishiyama’s correspondent host allegedly only has a single
`
`interface. POR, 30-34. MPH also contends that Ishiyama’s description of Security
`
`
`
`- 10 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`Databases and Correspondent Node (CN) addresses precludes its correspondent
`
`host from being a gateway. See id., 34-37. Both of these theories are wrong
`
`because they overlook that: (1) Ishiyama explicitly refers to its correspondent host
`
`as a “gateway”; and (2) the proposed combination addresses any alleged
`
`deficiencies of Ishiyama’s correspondent host. See EX1022, ¶¶39-47.
`
`First, Ishiyama repeatedly refers to its correspondent host as a “gateway.”
`
`And because there is no dispute that Ishiyama’s correspondent host implements
`
`IPSec—security functionality—it is thus a “security gateway.” For example,
`
`Ishiyama refers to its tunnel mode IPSec communication addresses as “gateway
`
`addresses.” EX1004, 8:1-6. These gateway addresses indicate “one endpoint
`
`(termination endpoint) of the tunnel.” Id., 8:1-6. Ishiyama also describes “CoA
`
`updating,” where the “correspondent host 3” updates a “gateway address” when a
`
`mobile terminal moves to another network. Id., 8:66-9:10. Further, Ishiyama
`
`explicitly refers to this process as a “SA Gateway Update,” where the mobile
`
`device transmits a “[r]equest for changing the security association to the
`
`correspondent.” Id., 11:39-47. Ishiyama also describes an embodiment where the
`
`“SA Gateway Update” includes updating the contents “at the correspondent host
`
`‘CN’” to update the SA. Id., 12:50-59. Thus, Ishiyama repeatedly refers to
`
`updating the correspondent host as updating the “SA Gateway,” further
`
`
`
`- 11 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`demonstrating that it would have been obvious to a POSA for the correspondent
`
`host to be a security gateway.
`
`Second, MPH’s argument that Ishiyama’s correspondent host only has a
`
`single interface is wrong. As an initial matter, this argument relies on MPH’s
`
`improper construction for “security gateway,” explained above. More importantly,
`
`MPH’s argument overlooks Apple’s proposed combination.
`
`Apple contends an obvious implementation of Ishiyama’s correspondent
`
`host would have been a “security gateway” because “security gateways” are
`
`commonly used with IPSec, and in fact usually used with IPSec tunnel mode. See
`
`EX1001, 3:19-30; EX1011, 9; EX1022, ¶¶26-28, 41. MPH does not suggest that its
`
`construction for “security gateway” is some special meaning dictated by the ’581
`
`patent. In fact, MPH suggests that its construction of “security gateway” is
`
`allegedly consistent with its common use in the art, including the IPSec standard.
`
`See POR, 15-33; EX2009, ¶¶71-90; see also EX2009, ¶¶84-89 (citing EX1011 (the
`
`IPSec standard)). This same IPSec standard, including its descriptions of “security
`
`gateways,” would have caused a POSA to understand that Ishiyama suggests the
`
`use of “security gateways.” Thus, the “security gateway” suggested by Ishiyama
`
`would have the same features and functionality of “security gateway” proposed by
`
`Dr. Rouskas and MPH—because they are both based on the same description of
`
`“security gateways” in the IPSec standard.
`
`
`
`- 12 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`Finally, MPH’s arguments regarding Ishiyama’s “Security Databases” again
`
`focuses on an incorrect understanding of Apple’s combination. MPH argues that
`
`Ishiyama’s description of security policy databases allegedly proves that the
`
`correspondent host is not a security gateway. POR, 35-37. MPH similarly argues
`
`that Ishiyama’s description of a destination address potentially being “CN”
`
`precludes Ishiyama from operating as a security gateway. See id., 34-37. These
`
`arguments, however, incorrectly focus on narrow embodiments and fail to
`
`recognize how a POSA would have understood Ishiyama’s teachings as used in a
`
`security gateway. See EX1022, ¶¶42-47.
`
`Specifically, while Ishiyama describes a “security policy database (SPD)”
`
`and a “security association database (SAD),” nothing precludes these elements
`
`from being used in a common security gateway configuration, such as described by
`
`Murakawa. See Section III.C. In fact, the IPSec standard, as acknowledged by Dr.
`
`Rouskas, requires the use of these components to implement IPSec. See EX1011,
`
`13; see also EX1021, 89:8-15 (“A: An SAD database is required under RFC 2401.
`
`Q: Are there any other databases that RFC 2401 requires . . . ? A: Yes; it’s the
`
`security policy database [SPD].”). Security gateways are also required to have at
`
`least “one pair of SADs and one pair of SPDs.” EX1011, 13.
`
`Further, Ishiyama’s description of a destination address potentially being
`
`“CN” is just one possible implementation and does not preclude Ishiyama’s
`
`
`
`- 13 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`correspondent host from operating as a security gateway or being combined with
`
`Murakawa. See EX1022, ¶¶44-47. Indeed, this was acknowledged by the Board.
`
`DI, 36. And as admitted by Dr. Rouskas and MPH, it was well-known that devices
`
`could operate as both hosts and security gateways. See POR, 16, n.1 (citing
`
`EX2009, ¶70.).
`
`Regardless, the Board has already considered this argument and indicated
`
`that “Patent Owner does not identify any portion of Ishiyama that sufficiently
`
`criticizes, discredits, or otherwise discourages having Ishiyama’s correspondent
`
`host be a security gateway.” DI, 37. MPH still has not done so. Thus, nothing in
`
`Ishiyama or the prior art precludes the functionality described in Ishiyama from
`
`being implemented in a “security gateway.”
`
`V. The Combination of Ishiyama and Murakawa Teaches the “Other
`Terminal”
`MPH argues that the Petition does not explain how the combination of
`
`Ishiyama and Murakawa would operate with the “other terminal,” and thus does
`
`not teach the “other terminal.” See POR, 45-54. But this is simply incorrect. The
`
`Petition explicitly presents how Ishiyama and Murakawa would be combined and
`
`teach the “other terminal.” See Pet., 26-40.
`
`The Petition explains that Ishiyama teaches a mobile terminal moving from a
`
`first address to a second address. See id., 26-30. Ishiyama further teaches that the
`
`mobile terminal transmits a message to change the security association definition
`
`
`
`- 14 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`from CoA1 to CoA2. See id., 31-34. These operations would have been performed
`
`at a security gateway, such as the security gateway described by Murakawa. See
`
`id., 24-26. Both systems apply the IPSec tunnel mode protocol, and a POSA would
`
`have easily implemented Ishiyama’s address changing functionality with
`
`Murakawa’s security gateway. See, e.g., Pet., 39-40; see also EX1002, ¶87-90.
`
`Messages would then be communicated between the mobile terminal and
`
`“other terminals” via the security gateway, as depicted in FIG. 5 of Murakawa,
`
`consistent with IPsec tunnel mode operation with security gateways. See, e.g., Pet.,
`
`39-40; see also EX1002, ¶86-90. Indeed, as Dr. Rouskas explained, when IPSec
`
`tunnel mode is used with security gateways, it is for the explicit purpose of
`
`tunneling packets to “other terminals.” See EX1021, 122:7-18 (“Yes, typically that
`
`is what happens. Packets [are] IPSec process[ed] at the gateway, and then
`
`forwarded to another host.”). Murakawa confirms this by describing the presence
`
`of “other terminals” and that a security gateway would forward messages from the
`
`mobile terminal to these other terminals. See Pet., 37-40. Thus, the combination of
`
`Ishiyama and Murakawa teaches the “other terminals.”
`
`Mischaracterizing this combination, MPH alleges that “[i]ncorporating
`
`Murakawa’s security gateway 103 into Ishiyama does not fill in the missing
`
`limitation of the ‘other terminal’ because no host computer has been incorporated
`
`from Murakawa.” POR, 49. But MPH ignores Murakawa’s clear disclosure of
`
`
`
`- 15 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`communication between a security gateway and an “other terminal.” See EX1005,
`
`FIG. 5.
`
`EX1005, FIG. 5 (annotated).
`
`
`
`MPH also argues that “the security gateway 103 and computer 106
`
`illustrated in Murakawa’s FIG. 5 could not be combined into [Ishiyama’s] address
`
`changing system . . . .” POR, 53. But the Petition does not present this
`
`combination. Rather, the Petition and Dr. Goldschlag explain that Ishiyama’s
`
`address changing functionality would have been incorporated into security
`
`
`
`- 16 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`gateways (which provide communications between different terminals) such as the
`
`one depicted in Murakawa. See Pet., 39-40; see EX1022, ¶¶48-56.
`
`MPH never addresses this combination. MPH instead invents a different
`
`combination and argues that “Ishiyama’s security policy databases (Figures 8A-
`
`8B) and the security association databases (Figures 9A-9D) would not operate if
`
`the components of Murakawa were inserted in place of Ishiyama’s correspondent
`
`host.” POR, 53. This statement mischaracterizes the combination and ignores the
`
`combinability of security gateways with other devices, e.g., databases. See
`
`EX1022, ¶56. Ishiyama’s description of SPDs and SADs does not preclude the
`
`operation of a security gateway also implementing these components. See id.
`
`Indeed, the IPSec standard requires SPDs and SADs for any device implementing
`
`IPSec. See EX1011, 13; see EX1022, ¶56. Thus, nothing in Ishiyama or Murakawa
`
`precludes this combination, and this combination teaches the “other terminal.”
`
`VI.
`
`Ishiyama Teaches the Mobile Terminal Transmitting a Message While
`at a Second Address to Change the Definition of a Security Association
`As the Petition explains, Ishiyama describes a mobile computer changing
`
`from address CoA1 to CoA2. See Pet., 30. The mobile computer then performs a
`
`“SA Gateway Update” operation, including a request to change the security
`
`association and the endpoint of the IPSEC tunnel. See id., 31-33. As seen from
`
`FIGs. 9B and 9D of Ishiyama, database entries for the security association are then
`
`updated to reflect the address change. See Pet., 33-34; EX1022, ¶¶57-59.
`
`
`
`- 17 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`MPH argues that this change would occur at a “host,” not a “security
`
`gateway.” POR, 54-55. But as correctly acknowledged by the Board, the update
`
`being performed by a host is merely one embodiment of Ishiyama. See DI, 36. This
`
`description shows that Ishiyama teaches the movement of a mobile terminal, the
`
`transmission of a request to update the endpoint of an IPSEC tunnel, and that
`
`updating occurring at the other endpoint of the IPSEC tunnel. See Pet., 31-34.
`
`Murakawa provides the explicit recitation of a security gateway being this other
`
`endpoint, thus rendering these claim elements obvious. See id., 18-20.
`
`VII. The Combination of Ishiyama and Murakawa Teaches the
`“Request”/“Reply” Messages Being Encrypted as Recited in Claim 4.
`Regarding claim 4, MPH argues that the request message transmitted by
`
`Ishiyama’s mobile terminal is not encrypted because “Ishiyama does not specify a
`
`format for the SA gateway update signal in step (5)” and alleges that this signal
`
`would not be encrypted. See POR, 62. But MPH mischaracterizes the teachings of
`
`Ishiyama, and is contradicted by their own expert.
`
`Ishiyama explains that “[i]n the tunnel mode IPSEC communications, the
`
`packet encapsulation and the encryption/decryption of the inner packet are carried
`
`out and the IPSEC module 22 [of mobile unit 2] has functions for realizing such
`
`encapsulation and encryption/decryption processing.” EX1004, 7:56-60. The
`
`mobile unit then uses this IPSEC module to transmit an “encapsulated packet” via
`
`the IPSEC tunnel to update the address at the other endpoint. Id., 8:55-9:10. By
`
`
`
`- 18 -
`
`

`

`Case IPR2019-00820
`U.S. Pat. No. 7,937,581
`using IPSec to perform the update, the packet and the request message are
`
`encrypted. See EX1022, ¶¶60-62; see also EX1011, 4 at § 2.1, 6-7 at §§ 3.1-3.2.
`
`Dr. Rouskas even confirmed this during his deposition. EX1021, 175:19-176:2
`
`(“So, yes, the payload of that packet is encrypted.”).
`
`VIII. The Combination of Ishiyama, Murakawa, and Ahonen Renders Claims
`3 and 5 Obvious
`The Petition recites tw